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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Using XACML Policies to Express Scope in OAuth

Hi Hal,

On 5/06/2013 12:04 PM, Hal Lockhart wrote:
I have posted a short paper to the repository which outlines how I believe XACML can be used to fill a gap in the current OAuth specifications.

I believe it also sheds light on the relationship between different approaches to Authorization and Access Control.

I will also create a wiki page where we can capture comments and ideas.

I welcome your comments and suggestions on the list or the wiki,

On page three you say:

  "The good news is we can use an XACML PDP to select the policies for us. Normally we call the PDP,
   providing Attribute values and it tells us if the access is permitted or not. In XACML 3.0 a feature was
   added which allows the PEP to optionally request the Identifiers of the policies that were applicable to
   the decision. We can then obtain these policies from the policy repository and use them as the Issued

I don't believe this will work as you expect. At this point we have an incomplete
request context. Some attributes of the eventual resource access aren't necessarily
known, such as the action or the time of day. If we leave out the unknown attributes
we may get from the PDP a different result with a different list of applicable policies
and policy sets than what we would get from the PDP using the full request context
with the actual values of the unknown attributes applying at the time the resource
access actually occurs.

The XACMLPolicyQuery from the SAML profile is closer to what's needed, since it takes
a request context and returns policies and policy sets, but it will only work if the
implementation operates on the assumption that the request context may not be complete.

I think it would be appropriate to define a new PDP operation that takes an incomplete
request context and returns a set of "decapitated" policies and policy sets, perhaps
best wrapped up in a single policy set.

Policies can contain sensitive information in the form of user and resource identifiers,
among other things, that shouldn't be made public though a decapitated policy. We would
probably need to be explicit about how the request context is incomplete so that
sensitive expressions that are irrelevant to the requested scope get removed. Maybe we
would need to encrypt the decapitated policies for the intended authorization server
just to be safe.

On page five you say:

  "Currently XACML PDPs do not support the input of policies with decision requests except in the
   context of the Admin/Delegation Profile. This will need to be relaxed."

Of course that should be "in the context of the SAML Profile".



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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