[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]