Re: [xacml] For Thursday: XACML and OAuth

Hi Hal and Srijith,

    

    The link you provided is fine for an overview.

    

    For more direct information on how the OAuth simulation works,

    I suggest the following links:

    

    Javadoc description of simulator (describes the OAuth 2.0 mechanics
    used w xacml policy interception points):

       
http://svn.code.sf.net/p/openaz/code/trunk/openaz/test/doc/test/OAuthSimulator.html

    

    XACML shorthand (pseudo) policy for simulation:

       
https://sourceforge.net/p/openaz/code/HEAD/tree/trunk/openaz/test/policy/TestAzApi-OAuth-Only-Pseudo-Policy.txt

    

    Generated XACML XML Policy:

       
https://sourceforge.net/p/openaz/code/HEAD/tree/trunk/openaz/test/policy/TestAzApi-OAuth-Only-Generated-Policy.xml

    

      Thanks,

      Rich

    

    

    

    
On 4/14/2016 1:35 PM, Hal Lockhart
      wrote:

    

    
      
      
      
      

        
A
            document describing my proposal to use XACML Policies as
            OAuth Scope is in the XACML archives here:

        
 

        
https://www.oasis-open.org/committees/document.php?document_id=49416&wg_abbrev=xacml

        
 

        
Rich
            can perhaps give better links, but here is a slide deck
            describing his OAuth Simulator.

        
 

        
https://sourceforge.net/p/openaz/code/HEAD/tree/trunk/openaz/docs/OpenAz-OAuth-110330-simulation-summary.ppt

        
 

        
The
            build tree starts here:

        
 

        
https://sourceforge.net/p/openaz/code/HEAD/tree/trunk/openaz/

        
 

        
Hal

        
 

        

          
From:
              Srijith Nair [mailto:] 

              Sent: Tuesday, April 12, 2016 4:17 AM

              To: Hal Lockhart

              Cc: XACML TC

              Subject: Re: [xacml] For Thursday: XACML and OAuth

        

        
 

        

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