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 19/06/2013 4:52 AM, Hal Lockhart wrote:
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

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 think it is dangerous to base all access within the requested scope on the
result of one specific case. Suppose there is some other file in Joe's folder
that Joe is not permitted to write and that there is an XACML policy that denies
write access to this file by Joe. This policy won't be applicable for the request
context that was used and so will be left out of the issued scope. This means
that the bearer of the access token will be able to write the file that Joe

The intent has also gone missing here. If the intent were to allow only write
access to Joe's files, or if the intent were to allow any access to any of
Joe's resources (i.e., not just his files), then the same request context is
a valid specific case and the issued scope would still be the same. Clearly it
shouldn't be. The requested scope has to get factored into the issued scope in
some form.

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

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.

More serious I think. Attribute assertions will be about the specific entities
involved in particular access attempts. If we're not careful, the information that
leaks out in the issued scope of an access token could be about entities that are not,
and never will be, involved in accesses using that token.

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

It depends on how much the Authorization Server trusts the Resource Server.
Encryption prevents the bearer seeing stuff they shouldn't, but not the
Resource Server. Stripping out irrelevant stuff limits how much the Resource
Server sees.


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

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]