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


Ok, after looking at everything again, the only restriction I see comes from the length limit of a URI. I guess since its use is mandated by the implicit flow, you could call it architectural, but since the URI is just another way to carry the Token, I would call it a binding limit.

In any event as you point out, the other flows don't have this constraint. I don't see likely users of my scheme as wanting to use implicit anyway because of its security weaknesses.

Hal

> -----Original Message-----
> From: Anthony Nadalin [mailto:tonynad@microsoft.com]
> Sent: Monday, June 24, 2013 12:43 PM
> To: Hal Lockhart; Huang, Peter (HP-IT Palo Alto)
> Cc: xacml@lists.oasis-open.org; Steven Legg
> Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> 
> Look at 1.3.2, as implicit returns tokens directly and thus is subject
> to size restrictions, 4.2 implicit grant also has restrictions since it
> does not support refresh tokens and has redirection restrictions
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
> Sent: Monday, June 24, 2013 9:30 AM
> To: Anthony Nadalin; Huang, Peter (HP-IT Palo Alto)
> Cc: xacml@lists.oasis-open.org; Steven Legg
> Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> 
> Sorry I am not sure what you are referring to. Section 4.2 of RFC 6749
> covers Implicit Grants, but that does not seem to be what you mean.
> 
> Hal
> 
> > -----Original Message-----
> > From: Anthony Nadalin [mailto:tonynad@microsoft.com]
> > Sent: Monday, June 24, 2013 12:23 PM
> > To: Huang, Peter (HP-IT Palo Alto); Hal Lockhart
> > Cc: xacml@lists.oasis-open.org; Steven Legg
> > Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> >
> > Look at implicit flows, not code flows as these should work fine.
> >
> > -----Original Message-----
> > From: Huang, Peter (HP-IT Palo Alto) [mailto:peter.huang@hp.com]
> > Sent: Monday, June 24, 2013 9:14 AM
> > To: Anthony Nadalin; Hal Lockhart
> > Cc: xacml@lists.oasis-open.org; Steven Legg
> > Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> >
> > can you elaborate on the protocol limits?   I could see potential
> > limitations on refresh case but why would there be limitation on
> token
> > request?
> >
> >
> > -----Original Message-----
> > From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
> > On Behalf Of Anthony Nadalin
> > Sent: Monday, June 24, 2013 9:04 AM
> > To: Hal Lockhart
> > Cc: xacml@lists.oasis-open.org; Steven Legg
> > Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> >
> > No Hal, look at the implicit flows, these are not bindings there are
> > protocol limits on how the tokens requested and returned (both tokens
> > and refresh)
> >
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
> > Sent: Monday, June 24, 2013 8:59 AM
> > To: Anthony Nadalin
> > Cc: xacml@lists.oasis-open.org; Steven Legg
> > Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> >
> > The size limits are on specific bindings (passing arguments via URL,
> > cookie, etc.) not on the underlying protocols. Anyway, give a JSON
> > representation of policy, there is no reason simple policies can't be
> > as compact as the UMA resource set proposal, for example.
> >
> > In my experience, when you start with something intended "only for
> > simple cases" it becomes very difficult to transition to a different
> > scheme for the more complicated cases. Instead people add various
> > kludges to try to stretch it a little further and a little further.
> >
> > I am trying to get out ahead of that problem with an architecture I
> > think can scale in complexity as required without having to start
> over.
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: Anthony Nadalin [mailto:tonynad@microsoft.com]
> > > Sent: Friday, June 21, 2013 12:01 PM
> > > To: Hal Lockhart
> > > Cc: xacml@lists.oasis-open.org; Steven Legg
> > > Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
> > >
> > > 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.
> > >
> > > Hal
> > >
> > > > -----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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> -
> > > - 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
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]