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

Not saying it changes the model, you are just making the model complex in having to understand XACML and how the scope would be checked, since the scope passed in has to match the scope passed back and the scope on the refresh can’t be more inclusive than what was originally asked for. I don’t understand the value of this at all.


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Allan Foster
Sent: Friday, June 21, 2013 9:16 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Using XACML Policies to Express Scope in OAuth


I dont see how adding an additional use case for oAuth makes it more complex.  The discussion was not around changing the oAuth2 spec at all.  It was simply an observation that scopes, already perfectly well defined in oauth2, can be used to pass xacml policy information.

Why is this changing oauth2 at all?

There are many many different ways that oauth2 will be used, and no one use case should rule out others. Noone says you HAVE to pass xacml, just that is conforms to the oauth spec.


Simplify Email: Email Charter

Allan Foster - ForgeRock
VP Community - ForgeRock.org
Office of the CTO
Location: Vancouver, WA, US
e: allan.foster@forgerock.com
w: www.forgerock.org
b: blogs.forgerock.com/GuruAllan

On 6/21/13 9:00 AM, Anthony Nadalin wrote:

I think you are making the OAuth model very complex here by trying to add in XACML, there are size restrictions for the implicit flows that would prohibit XACML type policies, there are size restriction on refresh tokens (that would contain the original asked for scope), etc.
-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@oracle.com] 
Sent: Thursday, June 20, 2013 12:52 PM
To: Anthony Nadalin
Cc: xacml@lists.oasis-open.org; Steven Legg
Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
Well simplicity depends on what you know and what tools you have access to. Most OAuth types would describe writing a _javascript_ program as "simple" because they know _javascript_ and know a _javascript_ interpreter/compiler can be provided in the development environment they intend to use. However objectively, an XACML PDP is WAY simpler than a _javascript_ interpreter/compiler and the policy language is certainly simpler than a Turing complete language. Further, as I say in the paper, I am assuming it is easy to provide PDPs which are cheap or free. I think using a standard policy language is easier than inventing a new one, as has been done in Amazon's AWS, for example.
Its not entirely clear that the Client is supposed to understand the scope _expression_. For example, RFC 6749 says: 
"An access token is a string representing an authorization issued to the client.  The string is usually opaque to the client."
However, if the requirement is for the Client to check the Scope before the Resource Server checks it, there is no reason the Client can't also have a PDP.
The point is, there are many organizations in fields such as Healthcare and GeoSpatial who have requirements for complex policies. There is no reason why they shouldn't be able to use OAuth in appropriate situations, just as those who have simpler requirements do.
-----Original Message-----
From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 19, 2013 11:06 AM
To: Steven Legg; Hal Lockhart
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
This seems a little much as scopes are to be simple, not complex, 
scopes will also have to be understood/recognized by the client/user 
agent in addition to the authorization server that mints the tokens 
and refresh tokens, which makes this more complex
-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] 
On Behalf Of Steven Legg
Sent: Tuesday, June 18, 2013 10:54 PM
To: Hal Lockhart
Cc: xacml@lists.oasis-open.org
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
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 cannot.
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 
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
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 
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 
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.
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:
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]