Successfully reported this slideshow.
Your SlideShare is downloading. ×

Updates from the OASIS XACML Technical Committee - Making Authorization Developer-Friendly using ALFA, REST, and JSON

Check these out next

1 of 27 Ad
1 of 27 Ad

Updates from the OASIS XACML Technical Committee - Making Authorization Developer-Friendly using ALFA, REST, and JSON

Download to read offline

In this 20-minute presentation, David of the OASIS XACML TC and Axiomatics will show how XACML can be used to address fine-grained authorization, attribute-based access control, and policy-based access control using the REST, JSON, and ALFA profiles of XACML making authorization easy to create and consume.
This presentation was initially delivered at Oxford University in 2019.

In this 20-minute presentation, David of the OASIS XACML TC and Axiomatics will show how XACML can be used to address fine-grained authorization, attribute-based access control, and policy-based access control using the REST, JSON, and ALFA profiles of XACML making authorization easy to create and consume.
This presentation was initially delivered at Oxford University in 2019.

Advertisement
Advertisement

More Related Content

Advertisement

Updates from the OASIS XACML Technical Committee - Making Authorization Developer-Friendly using ALFA, REST, and JSON

  1. 1. © Axiomatics 2019 - All Rights Reserved 1© Axiomatics 2019 - All Rights Reserved 1 Easy Authorization with REST, JSON, and ALFA Updates from the OASIS XACML Technical Committee September 10th, University of Oxford David Brossard, OASIS XACML TC Member, IDPro Founding Member, @davidjbrossard
  2. 2. © Axiomatics 2019 - All Rights Reserved 2 What is XACML? ⁃ Founded in 2001 – https://www.oasis-open.org/committees/xacml/ ⁃ eXtensible Access Control Markup Language ⁃ Members include ⁃ Oracle, US Government, Axiomatics, IBM, Thales and others ⁃ Statement of purpose (from the first email on the ML) ⁃ To define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. ⁃ The schema will be capable of representing the functionality of most policy representation mechanisms available at the time of adoption. ⁃ It is also intended that the schema be extensible in order to address that functionality not included, custom application requirements, or features not yet envisioned.
  3. 3. © Axiomatics 2019 - All Rights Reserved 3 The challenge? ⁃ You’ve been tasked with developing a new application ⁃ Micro-service, API, SPA... You name it ⁃ There are many non-functional requirements ⁃ Authentication ⁃ Logging ⁃ Authorization ⁃ Authorization ties together business logic and security ⁃ How can you achieve scalable, future-proof authorization? ⁃ Something you don’t have to rewrite all the time?
  4. 4. © Axiomatics 2019 - All Rights Reserved 4 You could… ⁃ Think really hard and design your own model ⁃ Use RBAC ⁃ Hard-code the authorization logic within your app
  5. 5. © Axiomatics 2019 - All Rights Reserved 5
  6. 6. © Axiomatics 2019 - All Rights Reserved 6 Or you could… ⁃ Decouple your app code from your authorization logic ⁃ Focus on your app ⁃ Make it spiffy! ⁃ Implement your authorization requirements as ⁃ policies & attributes ⁃ Integrate your app(s) with an externalized authorization service Aloha XACML
  7. 7. © Axiomatics 2019 - All Rights Reserved 7 XACML is the de-facto standard for ABAC ⁃ Attribute-Based Access Control ⁃ Also known as Policy-Based Access Control ⁃ Context-aware, dynamic, externalized Who? What? When? Where? Why? How?
  8. 8. © Axiomatics 2019 - All Rights Reserved 8 XACML with respect to other standards ⁃ XACML is not ⁃ SAML ⁃ Identity federation ⁃ OAuth ⁃ Access delegation ⁃ OpenID ⁃ This handles authentication ⁃ UMA ⁃ User-managed access & consent management ⁃ XACML can collaborate with any of these standards to deliver better authorization
  9. 9. © Axiomatics 2019 - All Rights Reserved 9 What does XACML define? XACML Reference Architecture Policy Language Request / Response Scheme
  10. 10. © Axiomatics 2019 - All Rights Reserved 10 The XACML Reference Architecture Enforce DecideManage
  11. 11. © Axiomatics 2019 - All Rights Reserved 11 The XACML Reference Architecture Flow 1.View record #123 6.View record #123 2. Can Alice view record #123? 5. Permit, Alice can view record #123 3. Evaluate policies 4. Retrieve additional attributes
  12. 12. © Axiomatics 2019 - All Rights Reserved 12 XACML Uses Attributes ⁃ Key-value pairs ⁃ Key: Department ⁃ Value: Engineering ⁃ Multi-valued ⁃ Grouped into different categories ⁃ Different data types ⁃ Unique identifier ⁃ Name and namespace
  13. 13. © Axiomatics 2019 - All Rights Reserved 13 Did someone say XML?
  14. 14. © Axiomatics 2019 - All Rights Reserved 14 Don’t get me wrong, I <love>XML</love>
  15. 15. © Axiomatics 2019 - All Rights Reserved 15© Axiomatics 2019 - All Rights Reserved 15 (abbreviated language for authorization) ALFA JSON (JavaScript Object Notation) REST (we all know what that means)
  16. 16. © Axiomatics 2019 - All Rights Reserved 16 Bringing XACML to Developers REST A standard means to POST authorization requests to the PDP Faster (than SOAP) Easier to integrate with JSON Lightweight representation of a XACML request & response 80% smaller than XML Easier to integrate with ALFA Abbreviated Language For Authorization Developer-friendly Easier to read and write (than XML)
  17. 17. © Axiomatics 2019 - All Rights Reserved 17 The REST Profile of XACML ⁃ Provide easy means to send authorization request ⁃ Just POST an authorization request ⁃ Provide standard transport protocol in XACML ⁃ Current implementations use proprietary bindings e.g. SOAP ⁃ SOAP in itself is losing has lost popularity ⁃ Integrate with more environments, languages, and SaaS
  18. 18. © Axiomatics 2019 - All Rights Reserved 18 POSTing a Request in Javascript var xmlHttp = null; function authorize() { var xacmlRequest = document.getElementById( "xacmlrequest" ).value; var Url = "https://localhost:5443/axio/authorize"; xmlHttp = new XMLHttpRequest(); xmlHttp.onreadystatechange = ProcessRequest; xmlHttp.withCredentials = true; xmlHttp.open( "POST", Url, false ); xmlHttp.setRequestHeader("Accept","application/xacml+json"); xmlHttp.setRequestHeader("Content-Type","application/xacml+json"); xmlHttp.setRequestHeader("Authorization","Basic cGVwOnBhc3N3b3Jk"); xmlHttp.send(xacmlRequest); } Create an HTTP request to the PDP Choose to authenticate the call and use POST Set the content type and the username/password
  19. 19. © Axiomatics 2019 - All Rights Reserved 19 The JSON Profile of XACML – Building a JSON request in Javascript Create a new Request object Create a new AccessSubject attribute category Add an attribute and its value function createAttribute(identifier, value){ var attr = new Object(); attr.AttributeId=identifier; attr.Value=value; return attr; function generateXACMLRequest(){ // 1. Create empty request var jsonRequest = new Object(); jsonRequest.Request = new Object(); jsonRequest.Request.AccessSubject = new Object(); jsonRequest.Request.AccessSubject.Attribute = []; // 2. Add attributes jsonRequest.Request.AccessSubject.Attribute.push(createAttribute("com.acme.user.employeeId", "Alice")); // 3. Return request return jsonRequest; }
  20. 20. © Axiomatics 2019 - All Rights Reserved 20 Sample JSON/XACML Request & Response { "Request": { "ReturnPolicyIdList": true, "AccessSubject": { "Attribute": [ { "AttributeId": "axiomatics.demo.user.userId", "Value": "Alice" } ] }, "Resource": { "Attribute": [ { "AttributeId": "axiomatics.demo.record.recordId", "Value": "123" }, { "AttributeId": "axiomatics.demo.resourceType", "Value": "record" } ] }, "Action": { "Attribute": [ { "AttributeId": "axiomatics.demo.actionId", "Value": "view" } ] }, } } { "Response" : [{ "Decision" : "Deny" }] }
  21. 21. © Axiomatics 2019 - All Rights Reserved 21 The ALFA Profile of XACML ⁃ Simplified C#-like language ⁃ Easy on the developer ⁃ Uses namespaces to organize policies ⁃ Easy to scale up to hundreds of policies ⁃ Easy to add comments ⁃ All the main keywords of XACML are in ALFA ⁃ PolicySet, Policy, Rule, Combing Algorithms ⁃ Target, Condition ⁃ Obligation, Advice ⁃ More on Wikipedia and StackOverflow
  22. 22. © Axiomatics 2019 - All Rights Reserved 22 An example ALFA policy /* Medical Record policies */ policyset medicalRecords{ target clause objectType=="medical record” apply firstApplicable /* Physician access */ policy physiciansAccessMedicalRecords{ target clause user.role=="physician” apply denyUnlessPermit /* A primary physician can read a patients medical record */ rule readMedicalRecord{ target clause action=="read” condition primaryPhysician==requestorId permit } } } Same structural elements as XACML: • PolicySet • Policy • Rule
  23. 23. © Axiomatics 2019 - All Rights Reserved 23 An example ALFA policy /* Medical Record policies */ policyset medicalRecords{ target clause objectType=="medical record” apply firstApplicable /* Physician access */ policy physiciansAccessMedicalRecords{ target clause user.role=="physician” apply denyUnlessPermit /* A primary physician can read a patients medical record */ rule readMedicalRecord{ target clause action=="read” condition primaryPhysician==requestorId permit } } } Combining algorithms help resolve conflicts between policies and rules. Choose from: • firstApplicable • denyOverrides • permitOverrides • denyUnlessPermit • …
  24. 24. © Axiomatics 2019 - All Rights Reserved 24 An example ALFA policy /* Medical Record policies */ policyset medicalRecords{ target clause objectType=="medical record” apply firstApplicable /* Physician access */ policy physiciansAccessMedicalRecords{ target clause user.role=="physician” apply denyUnlessPermit /* A primary physician can read a patients medical record */ rule readMedicalRecord{ target clause action=="read” condition primaryPhysician==requestorId permit } } } Use targets to define the scope of the policy set / policy / rule
  25. 25. © Axiomatics 2019 - All Rights Reserved 25 An example ALFA policy /* Medical Record policies */ policyset medicalRecords{ target clause objectType=="medical record” apply firstApplicable /* Physician access */ policy physiciansAccessMedicalRecords{ target clause user.role=="physician” apply denyUnlessPermit /* A primary physician can read a patients medical record */ rule readMedicalRecord{ target clause action=="read” condition primaryPhysician==requestorId permit } } } Use conditions for advanced matching and relationship checks
  26. 26. © Axiomatics 2019 - All Rights Reserved 26 An example ALFA policy /* Medical Record policies */ policyset medicalRecords{ target clause objectType=="medical record” apply firstApplicable /* Physician access */ policy physiciansAccessMedicalRecords{ target clause user.role=="physician” apply denyUnlessPermit /* A primary physician can read a patients medical record */ rule readMedicalRecord{ target clause action=="read” condition primaryPhysician==requestorId permit } } } Lastly, we have the effect. Choose from: • Permit • Deny
  27. 27. © Axiomatics 2019 - All Rights Reserved 27© Axiomatics 2019 - All Rights Reserved 27 Live Demo

Editor's Notes

  • With the growth of users, apps, and data as well as the advent of cloud and DevOps, we see a sharp increase in the need to tackle contextual, fine-grained authorization. To address this, the members of the OASIS XACML Technical Committee have been working on the latest generation of their policy-based language to make it adapted to developers. When developers can implement policies without having to compile source code, then the application is policy-enabled. Policy-driven authorization has several benefits including lessening the burden on developers who will no longer have to write authorization code. Policies are also easier to maintain and audit and can tie straight into an enterprise’s existing IAM environment. Policy-driven authorization makes it easier to implement complex scenarios such as GDPR compliance, export control, and many more use cases. This talk will navigate the universe of policy-driven authorization to introduce attendees to the different alternatives before diving into a live example using ALFA, Java, and JSON. the Abbreviated Language for Authorization. Attendees are encouraged to bring a laptop, follow along, and implement their own examples.
  • A new OASIS technical committee is being formed. The eXtensible Access Control Markup Language (XACML) Committee has been proposed by Simon Blackwell, PSoom; Ken Yagen, CrossLogix; Gilbert Pilz, Jamcracker; Michiharu Kudoh, IBM; Krishna Sankar, Cisco; Ernesto Damiani, individual member; Bill Parducci, individual member; Frank Chum, PSoom; Joe Pato, HP; Fred Moses, EntitleNet; and Meg Kistin Anzalone, EntitleNet. The request for a new TC meets the requirements of the OASIS TC process, and is appended to this email. To become a member of this new TC you must 1) be an employee of an OASIS member organization or an Individual member of OASIS, 2) notify the committee chair, Simon Blackwell (sblackwell@psoom.com), of your intent to participate at least 15 days prior to the first meeting, and 3) participate in the first meeting on 21 May, 2001. You should also subscribe to the TC's discussion list. (For the procedure for joining after the first meeting see the TC process at http://www.oasis-open.org/committees/process.shtml.) The mail list xacml@lists.oasis-open.org is for committee discussions. TC members as well as any other interested OASIS members should subscribe to the list. Do this by sending a message to xacml-request@lists.oasis-open.org with the word "subscribe" as the body of the message. (Note that subscribing to the mail list does not make you a member of the TC; to become a member you must contact the TC chair as described in the preceeding paragraph.) </karl> ================================================================= Karl F. Best OASIS - Director, Technical Operations 978.667.5115 x206 karl.best@oasis-open.org http://www.oasis-open.org Name of TC: eXtensible Access Control Markup Language - XACML Statement of purpose: The purpose of the XACML TC is to define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. The schema will be capable of representing the functionality of most policy representation mechanisms available at the time of adoption. It is also intended that the schema be extensible in order to address that functionality not included, custom application requirements, or features not yet envisioned. Issues to be addressed include, but are not limited to: fine grained control, the nature of the requestor, the protocol over which the request is made, content introspection, the types of activities authorized. List of deliverables (timing is given as days from first meeting): - statement of scope (45 days), - glossary (v1.0 45 days), - bibliography (v1.0 45 days), - use cases (v1.0 90 days), - detailed requirements (v1.0 120 days) - proposed standard (v1.0 180 days) - model examples for "native" and non-native XML targets of control (v1.0 180 days) - reference implementations (v1.0 270 days) Related Work: To ensure work is not duplicated and standards adoption is as simple as possible, XACML shall adopt as baseline documents the work products of the Security Services TC including but not limited to a Domain Model and Glossary. Furthermore, Use Cases and Requirements documents will share content that is common through normative references. The XACML TC shall keep its work consistent with the work of the Security Services TC by requesting enhancements to, modifications of, and cross-references from Security Services TC documents through a formal liaison with the Security Services TC. This liaison will include the regular sharing of deliverables and status reports during teleconferences or at face-to-face meetings. Language in which the TC will conduct business: English Date, time and place of first meeting: Via teleconference at 8AM PST May 21st. Proposed meeting schedule for first year: Teleconference calls will be held by the full TC on the second Monday of each month at 8AM PST, except when a face-to-face meeting is scheduled during the same week. A tentative date for a face-to-face meeting is XML World Sep 30th-Oct 3rd, San Jose, CA. Names and e-mail addresses of members: Ken Yagen [kyagen@crosslogix.com], Gilbert Pilz [gpilz@jamcracker.com], Michiharu Kudoh [KUDO@jp.ibm.com], Krishna Sankar [ksankar@cisco.com], Ernesto Damiani [edamiani@crema.unimi.it], Bill Parducci [bill@parducci.net], Frank Chum [fchum@psoom.com], Joe Pato [joe_pato@hp.com], Fred Moses [fmoses@entitlenet.com], Meg Kistin Anzalone [meganzalone@entitlenet.com], Simon Blackwell [sblackwell@psoom.com] Name of chair: Simon Blackwell [sblackwell@psoom.com] Names of meeting sponsors: Simon Blackwell will sponsor the first teleconference and co-ordinate the first face-to-face.
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 
  • Policy Enforcement Point
    Protect the targeted application
    Policy Decision Point
    Evaluate incoming authorization requests against a set of policies
    Policy Information Point
    Provide the PDP with missing attributes
    Policy Administration Point
    Manage authorization policies
  • Before we can write a policy we need attributes
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 
  • Here is some pointers to frame the conversation:
    #1  Light-weight/coarse-grained authorization.  Social logon.  How do OAuth and OIDC fit into Axiomatics model (or do they)?  Are those competing or complementing technologies?  Is Axiomatics playing  into this space at all? 
    #2  Microservices.  Controlling access to APIs. 
    #3   Subscription management.   Consent Management. 
    #4  Transparency to consumers while spanning Authorization services across multiple cloud providers. 
    #5  We already know you have a big data solution.  But please re-iterate. And tell us how your components (XACML-based or not) are interacting like a suite. 

×