Re: [xacml] For Thursday: XACML and OAuth

[Srijith Nair <srijith.nair@axiomatics.com>]

Hi Hal,

Could you point me to the material that Rich and you worked on, as mentioned by you in in your email?

Regards,

Srijith

On Tue, Mar 29, 2016 at 9:08 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

The most significant development in access control recently is the OAuth family of protocols. Classic ABAC brings all the attribute values and policies together and makes one decision at a time whether proposed requests should be allowed. In contrast, OAuth creates a software token which contains information about what the party presenting the token is allowed to do. Initially this was used for explicit delegation from one person to another, with a manual approval in the middle. Since then, OAuth this has been extended to cover delegation to hardware or software components, such as an App or smart phone acting on behalf of a user. It is also used to encode in the token the rights to perform a number of different requests which can then be approved one by one without repeating the initial authorization steps.

 

OAuth offers potential benefits of enabling explicit delegation, the ability to deal with multiple components which are controlled by different entities with potentially adverse interests (e.g. user, phone, app and web service), the ability to approve multiple requests from the same token, the ability to hide user identity information from parties who don’t need it and various kinds of performance benefits.

 

However, OAuth as it stands today does not address several key issues. First, it is silent on how the authorization server decides what permissions should be put in the token. The format of the Scope, which is that part of the token which says what is allowed, is unspecified. This means a) that there has to be close cooperation between an authorization server and the resource servers it generates tokens for, and b) there is no standard for code to interpret the Scope. This forces applications back to all the bad practices of pre-ABAC days. Authorization code is written in a high level language and often intertwined with non-policy code. Typically the allowed functionality is very limited.

 

The OpenAz project examined OAuth and its potential relationships to XACML from several angles. Rich Levinson built a demonstration of how the OAuth protocol logic can be drive entirely by XACML policies which guard the different OAuth handshakes.

 

I made proposed a scheme where XACML policies themselves (in a more compact JSON format) could be used to express OAuth Scope, but omitting the Subject information. This could be done either by having simple rules for providing certain policies for certain users, or perhaps by using an XACML PDP to evaluate policy and then tell us what policies were used. In either case, the resource server can pass the policies from the Scope to a PDP rather than have to invent some new scheme.

 

I believe work like the above and other future efforts will lead to a deeper understanding of the ABAC and token models and what their relationships are. I see a need to have systems which allow consistent policy _expression_ and governance across the enterprise, regardless of the handshake used.

 

Hal