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


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.

> 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.
Something like this:

client                                         
idref=3454469

server
idrefMap={{3454469,Alice},{5644648, Bob}, ....}

The communication would be something like this:

0. client ---- authenticate ----> server
1. server stores identity in idrefMap
2. server ---- cookie with idref ----> client
3. client ---- read personal page ----> server
4. (inside server) PEP --- access request ---> PDP
5. (inside server) PDP --- response ---> PEP
6. server --- access/denied ---> client

so in step 2. the PEP would build the XACML request including the
subject-id.

The general idea would be to generate the resource information from the
URL, the subject info from the session and the action e.g. from the http
method (put/get/update/delete).

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

Phone +46(0)70-349 92 51
http://www.sics.se

Attachment: signature.asc
Description: This is a digitally signed message part



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