[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
It's a big restriction for many device and browser levels. There are as many security weaknesses in code flow as implicit, see RFC 6819. What is also unclear from these threads is the question on whether or not the XACML policy is also represented also in the token returned and not just limited to scope. -----Original Message----- From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Hal Lockhart Sent: Thursday, June 27, 2013 7:47 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 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 > --------------------------------------------------------------------- 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]