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: Policy with subject specific resources

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. The following would be possibilities:
1) Add specific functionality to the PEP to include a subject attribute that is the user specific part of the URL (as suggested in the mailing list contribution referenced above). The application and PEP would use a shared mechanism for mapping subject-id to attribute value as with (3) below.
   This method has the disadvantage that it requires adding application specific functionality to an otherwise general PEP.
2) Create a rule for each subject.
   This has the disadvantages that the policy must be updated and reloaded when a user is added, and that performance is likely to be poor for large numbers of users.
3) Write a custom XACML function to perform the mapping from subject-id to user specific URL component. If the function encrypts the subject-id using a fixed key, it would be general but would allow the possibility of users breaking the encryption - this may be an acceptable risk in our context. The function could also use a table of mappings from subject-id to random URL components; this table would have to be shared with the application.

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)?

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]