1 / 23

XACML 3.0 New Features and Standardization Status

XACML 3.0 New Features and Standardization Status. Prepared for ITU-T by Hal Lockhart Oracle September 17, 2009. XACML Current Status. XACML 2.0 OASIS Standard – Feb 2005 ITU-T Recommendation X.1142 – Jun 2006 XACML 3.0 In progress Core & base profiles recently completed Public Review

aubrianna
Download Presentation

XACML 3.0 New Features and Standardization Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XACML 3.0 New Features and Standardization Status Prepared for ITU-T by Hal LockhartOracleSeptember 17, 2009

  2. XACML Current Status • XACML 2.0 OASIS Standard – Feb 2005 • ITU-T Recommendation X.1142 – Jun 2006 • XACML 3.0 In progress • Core & base profiles recently completed Public Review • Administration/delegation {New} • Hierarchical resource {Enhanced} • Multiple resource {Enhanced} • SAML {Enhanced} • Digital Signature, Privacy, RBAC • XSPA Profile submitted for OASIS Standard • Additional profiles under development • Obligation families, Export Compliance, Policy Distribution, Metadata, WS-XACML, Intellectual Property Control

  3. Request Context Schema Generalization • Triggered by need to add “delegate” for reduction • Eliminate <Subject>, <Environment>, <Resource> & <Action> Elements • Everything carried in <Attributes> Element • URNs used to identify categories • XACML 2.0 Subject categories • New URNs for Environment, Resource, Action & Delegate Categories • Generally upwardly compatible • Attribute selectors may require manual conversion • Policy & Context Schemas combined

  4. XACML 2.0 Request Context <Request …> <Subject> <Attribute AttributeId=“ … subject-category” …> <AttributeValue> … access-subject</AttributeValue> </Attribute> <Attribute> AttributeId=“ … subject-id” …> <AttributeValue>John Smith</AttributeValue> </Attribute> <Attribute> AttributeId=“ … group” …> <AttributeValue>Engineer</AttributeValue> </Attribute> </Subject> <Resource> <Attribute> AttributeId=“ … resource-id” …> <AttributeValue>http://www.example.com/</AttributeValue> </Attribute> </Resource> … </Request>

  5. XACML 3.0 Request Context <Request …> <Attributes Category=“ … access-subject”> <Attribute> AttributeId=“ … subject-id” …> <AttributeValue>John Smith</AttributeValue> </Attribute> <Attribute> AttributeId=“ … group” …> <AttributeValue>Engineer</AttributeValue> </Attribute> </Attributes> < Attributes Category=“ … resource”> <Attribute> AttributeId=“ … resource-id” …> <AttributeValue>http://www.example.com/</AttributeValue> </Attribute> </Attributes> … </Request>

  6. XACML 3.0 Administration/Delegation • Two primary use cases • “HR-Admins can create policies concerning the Payroll servers” • “Jack can approve expenses while Mary is on vacation” • Backward compatible • Defined as an optional Profile • Policies can contain Issuer • Policies can be Access or Admin • Admin policies enable policy creation

  7. Policy Evaluation • Select potentially applicable policies by Target matching • For each Policy evaluate Rules and combine • Target Match • Evaluate condition • Return Effect and associated Obligations • For each Policy Set combine policy results • Return Effect and Obligations

  8. Policy Evaluation with Admin Policies • Select potentially applicable policies by Target matching • For each Policy evaluate Rules and combine • Target Match • Evaluate condition • Return Effect and associated Obligations • For every un-trusted policy • Find an applicable Admin policy which authorizes the Issuer • Repeat until a chain to a trusted policy is found • Discard unauthorized policies • For each Policy Set combine policy results • Return Effect and Obligations

  9. Fine Points of Reduction • Access and Administrative policies are matched against the situation, not each other • Current vs. Historic attribute mode • Indeterminate results must be propagated for combining • Maximum delegation depth • Obligations in Administrative policies apply to access decision

  10. Obligation Families • Allows Obligations to be grouped in families with the same properties • Specific Obligations semantics still undefined • Timing – before, after, with access or any • Exclusive - Fallback = true or false • Sequential • Ordered = true or false • Repetitive = true or false • Failure Mode = fail fast, continue or atomic • Work in process

  11. New Combining Algorithms • More rational handling of Indeterminate • Same algorithms for rule and policy combining • Indeterminate are classified by possible effect • Example: for deny overrides, if Indeterminate rule or policy could only result in Permit & there is at least one Permit, result is Permit • New algorithms are mandatory to implement • Old algs are present, but not recommended

  12. Other new features • Multiple decisions in a single request, varying any attribute category (just Resource in 2.0) • Advice – like Obligations, but can be ignored if not understood by PEP • New XPath 2.0 functions • New time duration functions • Policy distribution protocol • Decision request protocol based on WS-Trust • Metadata profile • Authorization API, Attribute Manifest File

  13. Authorization API • XACML 2.0 Specifies • Policy language evaluation semantics • XML format for policy interchange • Abstract format for inputs and outputs, expressed in XML • Protocol for remote requests using XML input & output format • XACML 2.0 does not specify • API for requesting policy decision

  14. Authorization API Benefits • Needed for call to local PDP • Local PDP required for low latency calls • Inefficient to serialize data to and from XML • XML form not required by the standard • Also useful to have standard API for remote requests • Common code to build message

  15. API General Characteristics • Java initially, C++ and perhaps others to follow • Modeled on XACML Request/Response Contexts • Use XACML datatypes – in format natural to language • Mostly to be used by infrastructure components • Occasionally application may need to provide data • Infrastructure could be Container, Aspects, tool-generated code, etc.

  16. Why not Java Authorization/JSR 115? • Java Authorization (with or w/o JSR 115) based on Permissions • Passive enforcement by container is a good idea • Limitations to use of XACML features • No convenient, standard way to provide XACML inputs • No method to return outputs, e.g. Obligations, missing Attributes • New Resource type requires definition of new permissions class (recompile)

  17. API Overview • Methods to build (and access) Request Context • Methods to process Response Context • “decide” method to invoke PDP • Single or bulk decisions • “whatIsAllowed” method to obtain allowed alternatives • Operates in the context of some scope • Creates invokes a series of decisions • Returns allowed alternatives within scope • Other convenience methods

  18. The Input Attributes Problem • XACML Policies operate on data provided • Only PDP sees/evaluates policies • What attributes should be provided? • Where can attributes be obtained from? • How can the proper instance value be obtained?

  19. Attribute Manifest File • File in XML format identifies attributes to be added to Request Context • Name of Attribute, Issuer, datatype, location, access method, other attribute to use as key • Not all fields may be present • Three usecases: • PDP advertizes required attributes • PIPs are configured to add attributes to Request Context • Policy authoring tools use attribute name & format

  20. AMF AMF AMF Multiple PIP’s – Enhancing Request Context ReqCtx P I P Application LDAP ReqCtx OVD P I P PEP DB ReqCtx SAML P I P PDP

  21. AMF AMF AMF Multiple PIP’s – Reacting to Missing Attributes RespCtx Miss Attr P I P Application LDAP RespCtx Miss Attr OVD P I P PEP DB RespCtx Miss Attr SAML P I P PDP

  22. API and AMF Standardization Approach • Contributed to OASIS XACML TC in July 2009 • Intent is to standardize Interoperable components • Open Source Project started to develop implementations • API • Mate with open source XACML impl • Implement remote client • Mate with JAAC • AMF • Deployment time access methods • More info: http://www.openliberty.org/wiki/index.php/Main_Page#OpenAz

  23. Projected Status - Spring 2010 • Only XSPA Profile likely to reach OASIS Standard • Core & 1st set of Profiles will reach Committee Specification • Need Implementations • TC may adopt XACML 2.0 Approved Errata

More Related