This document provides a summary of a presentation about authorization using XACML, REST, JSON, and ALFA. It introduces XACML as the de facto standard for attribute-based access control and discusses how REST, JSON, and ALFA help bring XACML to developers by making it easier to integrate and use. Examples are given of how to send authorization requests via REST/JSON and how to write policies using the ALFA language. The presentation promotes using XACML to externalize and decouple authorization logic from applications for scalability and flexibility.
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.