I agree that the PEP should not be responsible for too much pre-processing of attribute data to suit a data relationship that exists only in the policy.
Though the XACML spec is not explicit on this point, I would expect the standard XACML 3.0 function “anyURI-from-string” to perform any character escaping necessary
to transform arbitrary string data into a conformant / “safe” URI. So, you should be able to have the PEP pass the data to the PDP as a string attribute, and in the policy use anyURI-from-string to transform the supplied attribute into a URI which should
perform any required escaping.
If URI escaping is the only transform between the PEP supplied data and the URI you need to test in the policy, the 3.0 standard anyURI-from-string should suffice.
If you’re using Xacml 2.0 or earlier, your options are limited as I don’t think Xacml 2.0 makes a strong distinction between string data and URI data. As I
recall, making URI a first class data type separate from string is one of the improvements that the Xacml 3.0 spec provides over earlier versions.
If you need to perform other URI transforms or component decomposition, things can get ugly fast as XACML doesn’t define any URI decomposition functions (extract
or test scheme, hostname, port, path, query, fragment, etc). You can use regex to perform pattern matching on URIs or URI components in the policy but to decompose and recompose URIs you’d best be served by defining custom extension functions to perform the
work. (Which we have done in the Quest PDP)
-Danny
Danny Thorpe
Product Architect |
|
Quest Software -
Now including the people and products of BiTKOO |
www.quest.com
From: Richard.Wilkinson@tessella.com [mailto:Richard.Wilkinson@tessella.com]
Sent: Friday, March 02, 2012 6:06 AM
To: xacml-users@lists.oasis-open.org
Subject: Re: [xacml-users] Policy with subject specific resources
Thank you for your response. I have expanded on the question below.
> On tis, 2012-02-28 at 12:49 +0000,
Richard.Wilkinson@tessella.com wrote:
>> I have been asked to investigate how we should implement a XACML
>> policy to authorise a user to access a personal section of a web
>> application, and would be grateful for comments. I am aware of the
>> method described in
>> http://lists.oasis-open.org/archives/xacml/200404/msg00076.html, which
>> addresses the type of problem I am concerned with. It is preferred to
>> not use the subject-id as part of the URL, so that the URLs cannot be
>> guessed. ....
>
> Does that mean that if you guess the right URL you can circumvent access
> control? That doesn't seem very secure to me.
No - the PEP, PDP and policy would control access. This requirement came to me
second hand and I may be overstating it. The simplest policy would be one that
grants access for some action to user authenticated with subject-id Alice to,
say, resource-id:
http://host.org/app/Alice/private
However, the subject-id may be such that a URL constructed as above is not
appropriate (it could contain '/'s or characters that are illegal in URIs). In
this case, some form of translation is needed (which could simply be URL
encoding the subject-id). The question is then where and how this translation
is performed. If it occurs in the PEP, the PEP has to know about the specifics
of the application, i.e., that a user has a private resource with URL
contructed from the subject-id in a particular way. Our PEP is a filter that
normally has no knowledge of the application. Another possibility is to use a
translation function in the policy, but again, this would have to be
non-standard. If the function performed, URL encoding, it isn't specific to the
application, but would be a custom function. If it had to look up something in
a database shared with the application, it is more specific. My question was
really about how to minimise the customisation of the PDP and/or PEP; ideally,
it would be possible to avoid customising either.
>
>> Is there a better method (where "better" includes requiring less/no
>> custom modification to the PDP or PEP, scaling well with number of
>> users and being manageable)?
>>
> Don't you have an authenticated session or something similar with the
> web app? You could save a reference to the subject-id in a cookie and
> retrieve it from a Map at the server side using the session context.
> ...
We already have an authentication system that makes the subject-id available.
Existing policies use subject attributes obtained from a PIP.
> Hope it helps,
>
> Ludwig
>
> --
> Ludwig Seitz, PhD
> Swedish Institute of Computer Science
> Ideon Science Park
> Building Beta 2 3v
> Scheelevägen 17
> SE-223 70 Lund
This message is commercial in confidence and may be privileged. It is intended for the
addressee(s) only. Access to this message by anyone else is unauthorized and strictly prohibited.
If you have received this message in error, please inform the sender immediately. Please note that
messages sent or received by the Tessella e-mail system may be monitored and stored in an
information retrieval system.
--------------------------------------------------------------------- To unsubscribe, e-mail:
xacml-users-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xacml-users-help@lists.oasis-open.org