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

Thanks for taking a look at what I wrote.

>    "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
>     Scope."
> 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.

In my scheme, the Authorization Server will provide a complete Request Context in the (Requested) Scope parameter. The Authorization Server will use the actual Subject Attributes of the authenticated party (typically the Resource Owner) and fill in values for Resource, Action and Environment which would be typical for an access using the Authorization Token. In most cases, environmental values will not matter, so the default of "right now" will be fine. In rare cases, the might have to be some tweaking between the Policies and the Request Context to get the policies desired, but usually if the intent is to allow all access to Joe's files it will be sufficient to ask to write one file in Joe's folder.

I did realize there is one additional step I omitted. If any of the Policy Sets among those which are Applicable contain Policy References to Policies which are not Applicable, it will be necessary to eliminate these references.

> 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.

The policy query is a source of some embarrassment to me. Originally it contained stipulations which cannot be met, such as comparing two targets to see if they are equal. Now it can work but is intended for a usecase I now believe is non-existent, namely a PDP which does not have enough volatile or non-volatile storage to hold all the policies currently in effect (Active Cohort) and has to obtain them over the network for each decision. The original intent was that the repository would check only Targets, thus returning a set of possibly applicable policies. As written the Profile lets you do that or even have the repository fully evaluate the policies. This would result in a double evaluation and a message exchange for every decision.

Given that regardless of the format used to represent policies, it is hard to see how even a large set of policies could be large than a MB or two, which these days is a trivial amount of space even for a cell phone. In any event, the query would need a complete Request Context just as the normal decision does.

> 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.

This may make sense when we understand the details better. I suspect that not only the Request Context contents, but also the specific Attribute Categories which get made constant may vary a bit, depending on  the precise OAuth flow being used and perhaps other factors as well. For starters I think it will be better for the required additional functionality to exist in the Authorization Server which calls an off-the-shelf PDP.

> 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.

This is a valuable point. However the situation is much the same as when some sort of Attribute Assertion is used as a Scope. The Attribute values may sensitive for privacy or other reasons. I think this is better dealt with by protecting i.e. encrypting, sensitive data rather than trying to architect it out of existence. The OAuth specs will permit encryption using JOSE (JWE). I think this should simply be a deployment option.

> Steven:
> 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".

Our assumption (in specifying 3.0) was that just in time policies would be supported by imbedded PDPs. We just did not see the need to standardize how they were presented to the PDP. In particular, it was not clear what format the policies should be in. (XML, JSON, internal binary) I believe all the processing to prepare the scope will need to happen locally, so this needs to be added to the OpenAz interface.

I am trying to strike a  balance between using existing pieces as is and defining a solution which has reasonable performance. I may get it wrong, so I welcome comments.


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