OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]