CIS14: Authorization: It's What's for Dessert

858 views

Published on

Gil Kirkpatrick, ViewDS
The basic concepts of authorization, the
continuum of “graininess” of access,
various authorization architectures, and
the advantages of controlling authorization
with some sort of policy mechanism, along
with discussion of the modern authorization
protocols XACML and OAuth2 and how you can
use them in your environment.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
858
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CIS14: Authorization: It's What's for Dessert

  1. 1. nmelbournensydneynsantacruz www.viewds.com n e w Cookies and Hash: Basic Identity and Access Management Recipes Authorization Gil Kirkpatrick gil.kirkpatrick@viewds.com
  2. 2. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 2  h#p://www.twistedoak.com/assets/client/File/chix/mary-­‐jean-­‐stclaire-­‐Take-­‐a-­‐Chicken-­‐to-­‐Dinner-­‐Tahoefull.jpg  
  3. 3. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #0 3 No f*cking passwords!
  4. 4. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #1 4 § Develop your identity strategy starting with your authorization and audit requirements §  Identify your most critical/sensitive data, applications, and apis §  What attributes do you need to decide who is allowed to do what? §  Where do those attributes come from? §  How do you trust those attributes? §  What is their lifecycle? §  Who owns them?
  5. 5. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #2 5 § Separate authorization code from the application § Manageability § Auditability § Security § Maintainability § Convenience § Efficiency
  6. 6. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Externalizing Identity and Access Management IdenBty   LDAP directories Cloud identity stores AuthenBcaBon   Kerberos SAML OpenID Connect Audit   Syslog Windows event log AuthorizaBon   XACML OAuth 2 UMA
  7. 7. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #3 7 § Have resource owners define authorization policy § Otherwise you get Surprise du Chef § App devs and IT can’t say what the authorization policy should be
  8. 8. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #4 8 § Authorization policy, not authorization code § Remove developers from the authZ policy loop § Give resource owners the tools to manage who gets access to their stuff
  9. 9. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #5 9 § Authorization has to be fast and scalable § Mobile friendly § Web friendly § API friendly
  10. 10. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Ingredient #6 10 § Accommodate different authorization models §  User consent §  Role-based Access Control (RBAC) §  Attribute-based Access Control (ABAC) §  Context-based Access Control (CBAC)
  11. 11. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Authorization Technologies 11 XACMLOAuth 2 UMA
  12. 12. OAuth 2
  13. 13. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m OAuth 2 § The motivation – eliminate the “Password Anti-Pattern” on the web §  Giving my FB password to Twitter so my tweets show up on my timeline §  Giving my FB password to Instagram so my photos show up on my timeline §  Giving my FB pass…. You get the idea § Answers the question “How to I allow this program I am using controlled access to my stuff?” §  Authorizing an application, used by the resource owner §  Substantially different scenario than XACML
  14. 14. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m The Fundamental Idea § Instead of giving my FB password to Twitter I will make FB give Twitter a token § Twitter can use the token instead of my password § The token will only let Twitter do certain things (scope) that I say it can do, like access my pictures § The token only works for a certain amount of time in case it gets stolen so Twitter has to periodically renew the token
  15. 15. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Canonical OAuth2 Roles 15 Resource Owner (RO) Client Authorization Server (AS) Resource Server (RS) Entity that can make authorization decisions about a resource Program that needs to access a protected resource on behalf of the resource owner Program that issues tokens after authenticating the owner and getting authorization Server that implements the protected resource
  16. 16. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m OAuth2 Tokens 16 Access Access token – presented to the resource server to get access to a particular scope AuthZ Grant   AuthZ grant – Represents the owners consent to access with a particular scope Refres h Refresh token - Used to generate another access token without requiring the resource owner to reauthorize the request
  17. 17. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 17 Canonical OAuth2 Flow AuthZ  Request AuthZ  Grant AuthZ  Grant Access  Token (Refresh  Token) Refresh  Token Protected  Resource Access  Token Protected  Resource Access  Token Access  Token Access  Token Protected  Resource Authenticate
  18. 18. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Grant: Authorization Code 18 Notes: •  Client pre-registers return URI and obtains credentials from AS •  Client authenticates with AS when redeeming access code •  Access token optionally includes a refresh token 3  AuthZ request 5  AuthZ Grant 4  AuthN/AuthZ 6  AuthZ Grant 7  Access Token 1  Access  with no  token 2  Access denied 10  Protected resource 8  Access  with token 9  Validate token
  19. 19. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 19 Grant: Implicit Notes: 1.  Client pre-registers return URI and obtains an identifier 2.  Client does not authenticate with AS 3.  Client is typically supported by Javascript running in browser to parse out token 4.  Refresh tokens are not supported 3  AuthZ request 4  AuthN/AuthZ 5  Access Token 1  Access  with no  token 2  Access denied 7  Protected resource 6  Access  with token JS
  20. 20. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 20 Grant: Client Credentials 3  AuthZ request 4  Access Token 1  Access  with no  token 2  Access denied 6  Protected resource 5  Access  with token Notes: 1.  No resource owner involvement in authorization flow 2.  Client authenticates with AS 3.  Authorization policy determined by prior configuration 4.  Refresh tokens are not supported
  21. 21. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 21 Grant: Resource Owner Credentials 4  AuthZ request 3  Username  and   password 5  Access Token 1  Access  with no  token 2  Access denied 7  Protected resource 6  Access  with token Notes: 1.  Resource owner provides resource credentials to client 2.  Client authenticates with AS and provides RO’s credentials 3.  Refresh tokens are supported
  22. 22. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Scopes 22
  23. 23. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Scopes § What they are §  Set of space-delimited strings § What they mean §  ACL? Permission? Claims? Policy identifier? Operation? § Problem §  Creates coupling between authorization server, resource server, and client application 23
  24. 24. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m OAuth 2 Pros § Externalizes authZ from application § Integrates user authentication, app authorization and user consent § Fits well with web architecture § Easy-ish to implement § Performance should be excellent Cons § Policies? We don’t need no stinkin’ policies. § Deprovisioning timing subject to token lifetime constraints § Design of scopes is left to the reader §  Coupling between client, AS and RS § Not really oriented to enterprise scenarios, but… 24
  25. 25. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Architectural Differences between Oauth and XACML §  In Oauth and UMA, you authz once to get a token, then use the token for many transactions §  Efficient §  But unauthorization is not immediate and depends on token lifetime §  Makes contextual authorization problematic §  In XACML, the PDP evaluates every single transaction §  Relatively inefficient, promotes complexity with caching, etc. §  But you can deaut §  In Oauth, the authorization process happens in two places: the AS and the RS §  In XACML the AS makes the authorization decision §  In UMA you §  Client, AS, and RS all have to have a common understanding of scopes, and scopes are left to the reader §  An unfortunate coupling between components that should evolve separately §  In XACML, RS and AS work at arm’s length §  The RS provides a minimal set of attributes to identify the policy §  The Context Handler fills in the blanks §  The PDP says yes or no 25
  26. 26. XACML
  27. 27. ~ } Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML is dead. Andras Cser, Forrester May 2013 http://blogs.forrester.com/andras_cser/13-05-07-xacml_is_dead 27
  28. 28. ~ } Copyright © 2014 ViewDS Identity Solutions www.viewds.co m The rumours of XACML’s death are greatly exaggerated. Dave Wilson, ViewDS 2013 With a tip of the hat to Samuel Clemens aka Mark Twain
  29. 29. ~ } Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML isn’t dead, it just smells funny. Gil Kirkpatrick, ViewDS 2014 With a tip of the hat to Frank Zappa
  30. 30. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML § eXtensible Access Control Markup Language § Architecture for application authorization § Standardized XML-based policy language §  Attribute-based §  Fine-grained §  Extensible § Standardized authorization request protocols §  SOAPy §  RESTful § Programmatic APIs (OpenAZ and EzAz)
  31. 31. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML Data Flow 31 Context  handler   Policy  decision   point   Policy   administraBon   point   Policy   enforcement   point   ObligaBon   service   Policy   informaBon  point   Subjects   Policy   ObligaBons  Access  request   Request  noBficaBon   Request   A#ribute  queries   Response   A#ributes   Response  context   Environment   Resources   Access  requestor   A#ribute  query   A#ributes   Resource  content   Resource  a#ributes   Environment  a#ributes   Subject  a#ributes  
  32. 32. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 32 Policy Allow Deny I don’t know XACML: A machine that turns attributes and policies into decisions +  ObligaBons  and   Advice  
  33. 33. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML Flow 33 AuthZ  Request AuthZ  Response LDAP  request LDAP  reposnse SAML/XML or REST/JSON
  34. 34. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 34 <Request> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"> <AttributeValue>gil@gilkirkpatrick.com</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http:// www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue>http:// app.example.com/projects/docs/pricelist2014.html</AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/ 2001/XMLSchema#string"> <AttributeValue>read</AttributeValue> </Attribute> </Action> </Request>
  35. 35. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 35 { "Request" : { ”Subject” : { ”Attribute”: { ”Id” : ”subject-id”, ”Value” : ”gil@gilkirkpatrick.com” }, }, ”Action” : { ”Attribute”: { ”Id” : ”action-id”, ”Value” : ”read” } }, ”Resource” : { ”Attribute”: { ”Id” : ”resource-id”, ”Value” : ” http://app.example.com/projects/docs/pricelist2014.html” }, } }
  36. 36. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML Policy Model § Policy Set §  Policy combining algorithm §  Policies § Policy §  Target §  Rules §  Rule combining algorithm §  Obligations §  Advice 36 § Target §  Resource §  Subject §  Operation § Rule §  Condition §  Effect §  Allow §  Deny
  37. 37. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m XACML Pros §  Externalizes authZ §  Standardized policy language §  Well thought out §  Flexible and extensible §  XML-based §  Instantaneous deprovisioning §  Can work with pretty much any application §  Plenty of vendors §  Incorporates application and user Cons § Over-elaborated for many scenarios § Does not address passwords, user authentication or consent § Every access implies IPC 37
  38. 38. UMA
  39. 39. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m User-Managed Authorization 39 § Described as a new profile of OAuth 2 § But starts with some different fundamental assumptions § Not fully baked…
  40. 40. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Different Assumptions Than OAuth2 § Controls access by people who are not the resource owner § Defines access using resource sets and scopes (“nouns and verbs”) § Formalizes the relationship between resource servers and authorization servers § Explicit recognition of responsible parties as part of the “Binding Obligations” spec 40
  41. 41. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m UMA Roles 41 Client An application making resource requests on the requesting party's behalf Requesting Party The entity that seeks to access a resource using a client Service that provides access to resources through APIs Resource Server Entity that can make authorization decisions about a resource Resource Owner Authorization Server (AS) Service that governs access to resources by creating tokens
  42. 42. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m UMA Tokens 42 RPT Requesting Party Token – token that represents the authorization status of the requesting party and client aka “the user”. PAT   Protection API Token – OAuth2 token used to register resource server and resource sets AAT Authorization API Token – OAuth2 token used to protect access to the authorization API of the authorization server. It associates the requesting party, the client, and the authorization server
  43. 43. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Canonical UMA Flow 43 2  Register RS 4  Register resource  set 1  Register application 4  Authenticate client 6  Authenticate 7  AAT 12  Request  RPT 10  Register permission 13  Protected resource 7  Operate client 9  Request resource 11  Grant  perm ticket 3  PAT
  44. 44. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m Responsibility for Authorization Decision 44 AuthorizaBon   Server   Resource   Server  
  45. 45. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m UMA Pros § Externalizes authZ from application § Fits well with web architecture § Accommodates policy-based authorization § Supports user and application authN and authZ § Puts resource owner in control § Leverages OAuth2 Cons § Not fully baked § Appears complex § No definition of policy § No major adopters… early days yet 45
  46. 46. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m 46 Reduces   password   use   Separates   authZ   code   from  app   Resource   owners   define   policy   Policy   instead  of   code   Mobile,   web,  and   API   friendly   RBAC   ABAC   CBAC   Scalable   and  fast   XACML   OAuth2   UMA   ?
  47. 47. Copyright © 2014 ViewDS Identity Solutions www.viewds.co m The Chef Recommends § Use OAuth2 to externalize web authN and authZ § Use XACML as the authorization policy engine behind the authorization server § Keep an eye on UMA – it formalizes a lot of things people are doing with OAuth2 on an ad hoc basis 47
  48. 48. Q&A 4

×