RE: [xacml-users] Policy with subject specific resources

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:  [mailto:]

Sent: Friday, March 02, 2012 6:06 AM

To: 

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, 
 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:
 For additional commands, e-mail: