[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
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]