Monday, February 28, 2011
Friday, February 25, 2011
Thursday, February 24, 2011
Wednesday, February 23, 2011
Saturday, February 19, 2011
Thursday, February 17, 2011
Way more than 140. And loving it
Ian, Nishant, Bob, Eve, and I discussed differences between the UMA authorization model, and that of XACML yesterday. At least, I think that's what we were discussing - as it was a tweet thread, significant portion of content was taken up by 'do you mean X?', 'pls clarify' and 'ignore my last', etc
Bob & Eve are attending RSA this week (with associated time & drinking responsibilities), and Ian & Nishant are better than I am at avoiding work - and so the burden of trying to collect the jewels of wisdom spread thinly through the various 140-constrained messages falls one me.
Conseqently, I've dusted off my blogging keyboard and temporarily freed myself from my practice of mentally counting characters (you do that too right?) up to 140.
The original tweets are listed in rough chronological order below, with my interpretation interspersed .
--------------------------------
Paul - Just learned something about UMA. Host->AM query different than XACML PEP->PDP - its a 'return privileges' model
User Managed Access (UMA) proposes a separation between where a User stores their identity attributes (or other data) and where they store their authorization (or consents in this context) policies governing those identity attributes. UMA makes possible the theoretical separation that OAuth 2.0 introduces between the Resource Server and the Authorization Server - a User could store their email with Google, but specify/manage, and store the authorizations governing 3rd party access to that email somewhere other than Google (yes there are business issues to resolve).
What surprised me is that I assumed UMA would be using the XACML model, in which a Policy Enforcement Point (PEP), when faced with a authorization decision for some access request, calls out to a Policy Decision Point (PDP) for that decision. In the XACML model, the PEP is not itself expected to have to compare requests to stored policy to determine what to do with the request (ie to make an authz decision ) - that's the PDP's job. In the XACML model, the PEP is insulated from the complexity of policy - and simply given a yes/no answer from the PDP to the 'Should I let this happen?' query it sent to the PDP.
In the UMA authorization model however, the Host (the entity that is hosting the OAuth protected APIs behind which sit some User's identity stores) and which I had expected to act like a XACML PEP plays a more active role. Rather than simply passing the buck to the 'Authorization Manager' (the UMA term for the entity at which a User manages their policies for their various, distributed resources), the UMA Host is expected to be able to actually compare the existing policy (previously created by the User and stored with the AM) against the request being made.
Rather than the Host asking the AM 'Should I let this happen?', the UMA Host asks the AM 'What are the stored policies (for the User in question, for this set of resources)?' And so, rather than the AM returning a yes/no to the query, it returns the existing policy it has (essentially a list of allowed OAuth scopes) for the resource in question. It is the Host's responsibility to then compare the list of allowed scopes against the current request, before making the decision to grant or deny the given access.
Paul - So, ultimately, the UMA Host is is the PDP & PEP
Because the UMA Host is both the entity that interprets the User's authorization policy, and the entity that enforces that policy, it takes on both the PDP and PEP roles of the XACML model.
The UMA AM, in that it stores and supplies policy to the Host on request, but does not itself interpret policy, acts as a policy store in the XACML model.
Ian - @paulmadsen say more on 'return privileges' versus XACML alternative model
Ian asking me to clarify
Paul - You either 1) pass token & req scope to AM, and ask for y/n, or 2)pass token to AM and ask for stored scope back, in order to decide y/n
Me doing so
Paul - @iglazer we'll see if @xmlgrrl agrees with the distinction, and maybe why UMA chose the latter (as I understand it)
Eve - @paulmadsen @iglazer You're right re "return privs" vs PDP, tho we only made this decision last week! Rationale at http://is.gd/0HYN8O
The UMA minutes that Eve refers to nicely set out the different models, and explain why the group choose how they did. The different models are labelled as PDP Option, Hybrid Option, and Meaningful Token Option.
Paul - @xmlgrrl @iglazer thanks Eve, do you imagine a suitably profiled JWT as enabling 'meaningful token' model
The Meaningful token' option that the UMA minutes refer to implies that the OAuth access token that the Requestor includes on its API request to the Host has everyhing the Host needs to determine what to do with the access request. So, rather than requiring the Host to call back to the AM to get a list of allowed scopes, the access token on the API call carries within itself the list of scopes.
And, because packing lists of things into a token implies some sort of structure, I asked Eve if UMA were thinking of using JSON Web Token (JWT) for the use case - as JWTs (when profiled with particular structures) are the emerging choice here. (think SAML assertions, although no XML in sight, and far less agreed upon tags).
Eve - @paulmadsen @iglazer Yep. We hope to leverage JWT in #UMA step 3, and also in step 2 for message authn and even claims exchange.
Seems UMA has big plans for JWT. Which is another reason why there needs to be a profile of JWT for OAuth sooner rather than later.
Bob - @paulmadsen Yes, but you can slot XACML PEP into the host with a callback to a PDP at the AM to implement PEP/PDP model
Bob is responding to my original tweet, not the JWT side thread. He is pointing out that, in the UMA model (in which the Host gets the list of returned scopes from the AM), nothing prevents the Host from switching into the XACML world, acting as a PEP, and pushing the burden of the actual authz decision back to an AM-located PDP.
Paul - @bobblakley seems a wee bit chatty. Unless you mean replacing the UMA defined query?
I am objecting to what I am interpreting Bob's suggestion to mean, namely a model in which the interaction between UMA Host & AM is something like the following
Host --> AM: Please give me list of scopes associated with this access token
AM--> Host: read write
Host (to itself whoa, I'm in over my head, think I better ask a different question)
Host-->AM: The requestor is trying to delete, what I should do
AM--> Host: deny
I am asking Bob if he means this 'conversation', or replacing the first request/response with the second
Bob - @paulmadsen No, I mean the chatty version. Depends on your use case...
Bob confirms he is talking about the model above. Which I dont really grok, but I'm hoping he will respond here.
Nishant - @xmlgrrl @paulmadsen @iglazer @bobblakley Would it be possible to aggregate this XACML - UMA thread into a single blog post?
Nishant, realizing he will soon need to create a trip report for his RSA conference boondoggle, asks for something more easily pasteable into a Word doc
Bob - @NishantK @xmlgrrl @paulmadsen @iglazer That sounds like a plan!
Bob, working on an new Burton report on 'cloud authorization models', is has similar motivation to Nishant
Paul - @NishantK @xmlgrrl @iglazer @bobblakley Ill take the AI
The naive Canadian is once again taken advantage of by his wiley Southern colleagues.
Bob & Eve are attending RSA this week (with associated time & drinking responsibilities), and Ian & Nishant are better than I am at avoiding work - and so the burden of trying to collect the jewels of wisdom spread thinly through the various 140-constrained messages falls one me.
Conseqently, I've dusted off my blogging keyboard and temporarily freed myself from my practice of mentally counting characters (you do that too right?) up to 140.
The original tweets are listed in rough chronological order below, with my interpretation interspersed .
--------------------------------
Paul - Just learned something about UMA. Host->AM query different than XACML PEP->PDP - its a 'return privileges' model
User Managed Access (UMA) proposes a separation between where a User stores their identity attributes (or other data) and where they store their authorization (or consents in this context) policies governing those identity attributes. UMA makes possible the theoretical separation that OAuth 2.0 introduces between the Resource Server and the Authorization Server - a User could store their email with Google, but specify/manage, and store the authorizations governing 3rd party access to that email somewhere other than Google (yes there are business issues to resolve).
What surprised me is that I assumed UMA would be using the XACML model, in which a Policy Enforcement Point (PEP), when faced with a authorization decision for some access request, calls out to a Policy Decision Point (PDP) for that decision. In the XACML model, the PEP is not itself expected to have to compare requests to stored policy to determine what to do with the request (ie to make an authz decision ) - that's the PDP's job. In the XACML model, the PEP is insulated from the complexity of policy - and simply given a yes/no answer from the PDP to the 'Should I let this happen?' query it sent to the PDP.
In the UMA authorization model however, the Host (the entity that is hosting the OAuth protected APIs behind which sit some User's identity stores) and which I had expected to act like a XACML PEP plays a more active role. Rather than simply passing the buck to the 'Authorization Manager' (the UMA term for the entity at which a User manages their policies for their various, distributed resources), the UMA Host is expected to be able to actually compare the existing policy (previously created by the User and stored with the AM) against the request being made.
Rather than the Host asking the AM 'Should I let this happen?', the UMA Host asks the AM 'What are the stored policies (for the User in question, for this set of resources)?' And so, rather than the AM returning a yes/no to the query, it returns the existing policy it has (essentially a list of allowed OAuth scopes) for the resource in question. It is the Host's responsibility to then compare the list of allowed scopes against the current request, before making the decision to grant or deny the given access.
Paul - So, ultimately, the UMA Host is is the PDP & PEP
Because the UMA Host is both the entity that interprets the User's authorization policy, and the entity that enforces that policy, it takes on both the PDP and PEP roles of the XACML model.
The UMA AM, in that it stores and supplies policy to the Host on request, but does not itself interpret policy, acts as a policy store in the XACML model.
Ian - @paulmadsen say more on 'return privileges' versus XACML alternative model
Ian asking me to clarify
Paul - You either 1) pass token & req scope to AM, and ask for y/n, or 2)pass token to AM and ask for stored scope back, in order to decide y/n
Me doing so
Paul - @iglazer we'll see if @xmlgrrl agrees with the distinction, and maybe why UMA chose the latter (as I understand it)
Eve - @paulmadsen @iglazer You're right re "return privs" vs PDP, tho we only made this decision last week! Rationale at http://is.gd/0HYN8O
The UMA minutes that Eve refers to nicely set out the different models, and explain why the group choose how they did. The different models are labelled as PDP Option, Hybrid Option, and Meaningful Token Option.
Paul - @xmlgrrl @iglazer thanks Eve, do you imagine a suitably profiled JWT as enabling 'meaningful token' model
The Meaningful token' option that the UMA minutes refer to implies that the OAuth access token that the Requestor includes on its API request to the Host has everyhing the Host needs to determine what to do with the access request. So, rather than requiring the Host to call back to the AM to get a list of allowed scopes, the access token on the API call carries within itself the list of scopes.
And, because packing lists of things into a token implies some sort of structure, I asked Eve if UMA were thinking of using JSON Web Token (JWT) for the use case - as JWTs (when profiled with particular structures) are the emerging choice here. (think SAML assertions, although no XML in sight, and far less agreed upon tags).
Eve - @paulmadsen @iglazer Yep. We hope to leverage JWT in #UMA step 3, and also in step 2 for message authn and even claims exchange.
Seems UMA has big plans for JWT. Which is another reason why there needs to be a profile of JWT for OAuth sooner rather than later.
Bob - @paulmadsen Yes, but you can slot XACML PEP into the host with a callback to a PDP at the AM to implement PEP/PDP model
Bob is responding to my original tweet, not the JWT side thread. He is pointing out that, in the UMA model (in which the Host gets the list of returned scopes from the AM), nothing prevents the Host from switching into the XACML world, acting as a PEP, and pushing the burden of the actual authz decision back to an AM-located PDP.
Paul - @bobblakley seems a wee bit chatty. Unless you mean replacing the UMA defined query?
I am objecting to what I am interpreting Bob's suggestion to mean, namely a model in which the interaction between UMA Host & AM is something like the following
Host --> AM: Please give me list of scopes associated with this access token
AM--> Host: read write
Host (to itself whoa, I'm in over my head, think I better ask a different question)
Host-->AM: The requestor is trying to delete, what I should do
AM--> Host: deny
I am asking Bob if he means this 'conversation', or replacing the first request/response with the second
Bob - @paulmadsen No, I mean the chatty version. Depends on your use case...
Bob confirms he is talking about the model above. Which I dont really grok, but I'm hoping he will respond here.
Nishant - @xmlgrrl @paulmadsen @iglazer @bobblakley Would it be possible to aggregate this XACML - UMA thread into a single blog post?
Nishant, realizing he will soon need to create a trip report for his RSA conference boondoggle, asks for something more easily pasteable into a Word doc
Bob - @NishantK @xmlgrrl @paulmadsen @iglazer That sounds like a plan!
Bob, working on an new Burton report on 'cloud authorization models', is has similar motivation to Nishant
Paul - @NishantK @xmlgrrl @iglazer @bobblakley Ill take the AI
The naive Canadian is once again taken advantage of by his wiley Southern colleagues.
Subscribe to:
Posts (Atom)