OASIS eXtensible Access Control Markup Language TC

FAQ

  1. What does the OASIS XACML Technical Committee do?

    The OASIS XACML TC focuses on the development of a standard access control policy language. "XACML" stands for "eXtensible Access Control Markup Language". The full charter is at http://www.oasis-open.org/committees/xacml/charter.php.

  2. What is the need for such a standard?

    Currently, there are many proprietary or application-specific access control policy languages. This means policies cannot be shared across different applications, and provides little incentive to develop good policy composition and auditing tools. Many of the existing languages do not support distributed policies, are not extensible, or are not expressive enough to meet new requirements. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, "deny" policies, and dynamic policies--all without requiring changes to the applications that use XACML. Adoption of XACML across vendor and product platforms provides the opportunity for organizations to perform access and access policy audits directly across such systems.

  3. Who will benefit from XACML and how?

    Every developer, user, or maintainer of applications that require secure authorization will benefit.

  4. What has the OASIS XACML TC produced to date?

    In February of 2003, the OASIS membership at-large approved XACML version 1.0 as an OASIS Standard. In August of 2003, the OASIS XACML TC approved XACML Version 1.1 as an OASIS Committee Specification. As this version contained only clarifications and minor changes, and did not change the Version 1.0 schemas, it was not submitted for consideration as an OASIS Standard.

    In February of 2005, XACML version 2.0 was approved as an OASIS Standard, along with six profiles of XACML: SAML 2.0, XML Digital Signature, Privacy Policy, Hierarchical Resource, Multiple Resource, and Core and Hierarchical Role Based Access Control (RBAC).

    Links to these documents are available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml.

  5. How does this work compare with related standards efforts?

    No other standard access control language written in XML currently exists. The OASIS XACML TC is aware of several related efforts:

    • The OASIS Security Services Technical Committee has defined the Security Assertion Markup Language (SAML). XACML is an outgrowth of work to support SAML's very basic authorization decision query protocol, although XACML is not intended to be limited to use with SAML protocols. The SAML 1.0 authorization decision query protocol was insufficient for meeting the requirements for fine-grained access control addressed by XACML, so the SAML AuthzDecisionStatement and AuthzDecisionQuery have been frozen as of SAML 2.0. A new XACMLAuthzDecisionStatement and XACMLAuthzDecisionQuery have been specified in the "SAML 2.0 profile of XACML v2.0", developed by the OASIS XACML TC with the approval and help of the OASIS Security Services TC. This profile also defines SAML extensions for using SAML to query a Policy Administration Point for XACML policies, specifies the use of signed SAML Assertions to protect XACML requests, responses, and policies, and specifies the mapping between SAML Attributes and XACML Attributes.

    • ISO 10181-3 defines an architecture for access control, but not a language. In ISO 10181-3 terms, XACML specifies an "Access Control Decision Function" (ADF), and defines its interactions with an "Access Control Enforcement Point" (AEF).

    • The IETF and Distributed Management Task Force (DMTF) have specified a framework for policies, but not a language. In IETF/DMTF terms, XACML defines a "Policy Decision Point" (PDP), and defines its interactions with a "Policy Enforcement Point" (PEP).

    • The Open Group has defined an Authorization (AZN) API, but not a language for authorization policies themselves. The OASIS XACML TC does not define an API, but is designed to work well with SAML AuthorizationDecisionQuery and its related protocols.

    • ANSI has standardized a framework and API for Role Based Access Control in ANSI INCITS 359-2004. The OASIS XACML TC developed a "Core and hierarchical role based access control (RBAC) profile of XACML v2.0" that satisfies the requirements of the ANSI framework, although XACML does not map easily onto the proposed API.

  6. What are the current activities of the OASIS XACML TC?

    There are pointers to our current working drafts on the OASIS XACML TC public home page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml. Our main focus for the next release is support for delegation of rights and for access controls on the creation of policies within XACML; these two activities are closely related, and are being addressed in the XACML3 "Administration Policy" drafts. There is not yet a schedule for completion of these activities, but discussions are active within the TC.

  7. Where are the archives for the OASIS XACML TC mailing lists?

    The archives are located at http://lists.oasis-open.org/archives/xacml/. These are publicly viewable.

    There is also a mailing list of comments received, primarily during the public review period leading up to the 1.1 standard. This mailing list is archived at http://lists.oasis-open.org/archives/xacml-comment/.

  8. Who should be involved in the OASIS XACML TC?

    Anyone with an interest in access control, authorization, entitlement and related policy issues, either willing to propose requirements or contribute technically should get involved.

  9. When does the OASIS XACML TC meet?

    General body meetings are held by teleconference every other week at 10am EST. There is an informal Focus Group meeting as needed on alternate weeks at 10am EST, to delve into details on particular topics. A few times each year, the TC holds a face-to-face meeting. The schedule for meetings is located at http://www.oasis-open.org/committees/calendar.php?wg_abbrev=xacml.

  10. Where do I use this technology?

    Anywhere you need rules to control access to some resources. It could operate at the network, server, container or object level.

  11. Where should I expect vendors to be using this technology?

    It may be imbedded in products such as gateways, firewalls, web servers, application servers or applications or provided by a specialized access control product.

  12. What problem does it solve?

    It provides an extremely flexible language for expressing access control that can use virtually any sort of information as the basis for decisions. It is a functional superset of other familiar access control schemes, such as permissions, ACLs, RBAC, etc. It is particularly designed to support large-scale environments where resources are distributed and policy administration is Federated.

  13. Is it used between the browser and the web server to control application behaviour at a browser level?

    Policy enforcement in distributed systems must always occur at a choke point (reference monitor) which cannot be bypassed. Usually this is at or close to the resource. Policy evaluation may occur anywhere.

    XACML is suitable to specify the access control policies for a web server.

  14. Is it used from applications to web applications or web services to control access?

    Again, XACML is well suited to decide if requests to a Web Server or Web Service should be allowed.

  15. Is it used from policy servers/stores to policy enforcement agents (or applications) to describe their policies (to be enforced)?

    The SAML 2.0 Profile of XACML specifies a protocol by which a Policy Enforcement Point (PEP) may request that an XACML Policy Decision Point (PDP) determine if access is allowed under some set of conditions. It is considered undesirable for a PEP to have to be aware of the semantics of policy.

    There is a proposed enhancement for XACML 3.0 which would permit a PEP to supply additional policies with the request which would be combined with policies the PDP already has.

  16. Is it used from policy administration interfaces to policy stores to read/update/commit policies?

    XACML 2.0 only specifies the syntax and semantics of access control policy. However, it would be completely straightforward to implement a CRUD interface based on the POSIX file system, WebDAV or something of that sort and protect it using XACML policies.

    For XACML 3.0, the TC is attempting something more ambitious -- the ability to create polices which control what sorts of policies may be created, e.g. policy delegation.

 

TOP OF PAGE