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

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.
> >
> > Hal:
> >>     "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."
> >>
> > Steven:
> >> 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.
> >
> > Hal:
> > 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.
> >
> > Steven:
> >> 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.
> >>
> >
> > Hal:
> > 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.
> >
> > Steven:
> >> 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.
> >
> > Hal:
> > 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.
> >
> > Steven:
> >> 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.
> >
> > Hal:
> > 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.
> Regards,
> Steven
> >
> >> 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".
> >
> > Hal:
> > 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.
> >
> > Hal
> >
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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