XACML Overview

March 02, 2005 The ballot for v2.0 passed. See the announcement: "XACML 2.0 Access Control Markup Language Approved as OASIS Standard. BEA Systems, Booz Allen Hamilton, Computer Associates, Entrust, Gluecode Software, IBM, Sun Microsystems, and Others Advance Open Standard for Information Access Control."

The OASIS Extensible Access Control Markup Language (XACML) TC was chartered "to define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. There are many proprietary or application-specific access control policy languages, but this means policies cannot be shared across different applications, and provides little incentive to develop good policy composition 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."

On December 31, 2004 OASIS announced that the XACML TC had submitted a set of documents collectively referred to as XACML 2.0, an approved Committee Draft, for consideration as an OASIS Standard. Balloting was scheduled for January 17-31, 2005. See the file listing and the ZIP file [source]. "XACML 1.0 became an OASIS Standard on February 18, 2003. New features in XAML 2.0 include a number of new profiles (Digital Signature, Multiple Resource, Hierarchical Resource, Role Based Access Control - RBAC, Security Assertion Markup Language - SAML, Privacy), Combining Algorithm parameters, Policy versions as a part of the reference mechanism, macro capabilities, some new datatypes and functions and a variety of improvements to the syntax to ease implementation." See the summary and other details on XACML 2.0 specifications in "OASIS Extensible Access Control Markup Language TC Approves XACML 2.0 Specifications."

XACML Requirements

As outlined in the Committee Draft Extensible Access Control Markup Language (XACML) Version 1.1 of August 7, 2003, "the basic requirements of a policy language for expressing information system security policy are:

• To provide a method for combining individual rules and policies into a single policy set that applies to a particular decision request
• To provide a method for flexible definition of the procedure by which rules and policies are combined
• To provide a method for dealing with multiple subjects acting in different capacities
• To provide a method for basing an authorization decision on attributes of the subject and resource
• To provide a method for dealing with multi-valued attributes
• To provide a method for basing an authorization decision on the contents of an information resource
• To provide a set of logical and mathematical operators on attributes of the subject, resource and environment
• To provide a method for handling a distributed set of policy components, while abstracting the method for locating, retrieving and authenticating the policy components
• To provide a method for rapidly identifying the policy that applies to a given action, based upon the values of attributes of the subjects, resource and action
• To provide an abstraction-layer that insulates the policy-writer from the details of the application environment
• To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement

[February 11, 2003]   XACML 1.0 Specification Set Approved as an OASIS Standard.    OASIS has announced the successful balloting and approval of the Extensible Access Control Markup Language (XACML) a new OASIS Open Standard. Formal definitions for the XACML language are provided in XML Schema Definitions (a Policy Schema and a Context Schema ). Chaired by Carlisle Adams (Entrust) and Hal Lockhart (BEA Systems), the XACML TC has created an XML specification for expressing policies for information access over the Internet. XACML is designed to enable the expression of well-established ideas in the field of access-control policy. Such a common policy language, "if implemented throughout an enterprise, allows the enterprise to manage the enforcement of all the elements of its access control policy in all the components of its information systems. Managing an authorization policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy." Sun Microsystems announced the release of an open source XACML implementation on 2003-02-18.

[September 30, 2003]   Draft XACML Profile for Web-Services Addresses Web Services Policy Expression.    A version 04 draft of the XACML Profile for Web-Services specification has been produced by members of the OASIS Extensible Access Control Markup Language TC. Also referenced as 'WSPL', the specification "defines a profile of XACML that enables it to be used for describing policy associated with Web service end-points and using them in a successful invocation." Background to the WSPL design is supplied in a Web-Services Policy Language Use Cases and Requirements document, summarized in the version 04 spec: "Access to a standard-conformant Web-service end-point involves a number of aspects, such as: reliable messaging, privacy, authorization, trust, authentication and cryptographic security. Each aspect addresses a number of optional features and parameters, which must be coordinated between communicating end-points if the service invocation is to be successful. The provider and consumer of the service likely have different preferences amongst the available choices of features and parameters. Therefore, a mechanism is required by which end-points may describe the mandatory features of service invocation, optional features that they support and the order of their preference amongst such features. Additionally, a procedure is required for combining and reducing these feature descriptions into a service invocation instance that respects both end-points' requirements. According to the WSPL profile, an XACML <PolicySet> element is associated with a concrete Web-service end-point definition." Appendix A of the specification provides an example from the realm of data-rate allocation; it illustrates the procedure for combining and reducing XACML policies that conform with the WSPL profile using two simple policy instances.

XACML TC charter: "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."

Activity having "substantial overlap with XACML" includes other DRM standardization effort: XACL, XRML, DPRL, W3C DRM Interest Group, eBook Forum (OeBF) Rights and Rules Working Group, MPEG (21) IP/rights, etc. See the list below and "Liaison with other standards groups," from David Parrott (Reuters).

[November 08, 2002]   Public Review for OASIS Extensible Access Control Markup Language (XACML) Specification.    Members of the OASIS Extensible Access Control Markup Language Technical Committee recently approved a version 1.0 Committee Specification for the XACML specification and voted to move the document forward for standardization. The motivation behind XACML is to express well-established ideas in the field of access-control policy using an extension language of XML. The XACML specification defines an XML schema consistent with this goal. The XACML 1.0 Committee Specification is now "undergoing a public review period in preparation for submission to OASIS for consideration as an OASIS Standard; the public review period will extend from Friday, November 8, 2002 until Sunday, December 8, 2002 (inclusive)."

As of 2001-06, the XACML TC had five sub-committeess: Intellectual Property; Standards And Interoperability; Use Case; Protocol; Representation.

Background:

"The modern enterprise is pervaded by information systems and devices. Economies of scale have driven vendors to provide increasingly general-purpose solutions that must be configured to address the specific needs of each situation in which they are applied. This leads to constantly increasing complexity and configurability. Furthermore, the devices and systems may be distributed widely in a global enterprise. The task of analyzing and controlling system and device configuration in a consistent manner across an entire enterprise is an enormous challenge, compounded by the fact that, even when systems and devices support configuration by a remote console, there is no common interface standard. Consequently, it is becoming increasingly difficult for an enterprise to obtain a consolidated view of the policy in effect across its many and diverse systems and devices or to enforce a single policy that affects many of those devices and systems. The objective of XACML is to address this need by defining a language capable of expressing policy statements for a wide variety of information systems and devices The approach taken by XACML is to draw together long-established techniques for access-control and then to extend a platform-independent language (XML) with suitable syntax and semantics for expressing those techniques in the form of policy statements..." [from the Committee Working Draft of OASIS Extensible Access Control Markup Language (XACML)]

XACML exploits long-established techniques, such as:

• Combining independent rules to form a single policy.
• Combining independent policies, optionally from different policy-writers, to form a single policy set.
• The parameterization of the algorithm to be used for combining rules and policies.
• Attaching an indication of the set of decisions that a rule or policy is intended to render to the rule or policy.
• Defining the set of decisions that the rule or policy is intended to render in terms of the name or attributes of the subject, resource and action identified in the decision request.
• Specifying in a policy statement a set of actions that must be performed in conjunction with the rendering of a decision.
• Stating rule conditions as a logical expression of predicates of functions of attributes of the resource and/or subject.
• Providing an abstraction layer between the policy language and the environment to which it applies.
• The communication of policies, either attached to the resources they are intended to protect, or separately.

[July 12, 2002] OASIS Extensible Access Control Markup Language (XACML). Technical Committee Working Draft, Version 15. 12-July-2002. 61 pages. Edited by Simon Godik (Simon Godik) and Tim Moses (Entrust). Document identifier: 'draft-xacml-specification-15.doc'. Location: http://www.oasis-open.org/committees/xacml/docs/. Send comments to: xacml-comment@lists.oasis-open.org. See also the corresponding draft Policy Schema ('draft-xacml-schema-policy-15i.xsd') and Context Schema ('draft-xacml-schema-context-15i.xsd'). "This specification defines an XML schema for a common access-control policy language." [source .DOC]

[March 07, 2002] "The OASIS XML-Based Access-Control Markup Language (XACML)." Committee Draft from the OASIS Extensible Access Control Markup Language Technical Committee ("definng an XML specification for expressing policies for information access over the Internet"). March 08, 2002. 37 pages. Document identifier: 'draft-xacml-v0.10'. Location: http://www.oasis-open.org/committees/xacml/docs. Edited by Tim Moses (Entrust) and Simon Godik (Simon Godik). Contributors: Anne Anderson (Sun Microsystems), Bill Parducci (Bill Parducci), Carlisle Adams (Entrust), Ernesto Damiani (University of Milan), Hal Lockhart (Entegrity), Ken Yagen (Crosslogix), Michiharu Kudo (IBM, Japan), Pierangela Samarati (University of Milan), Polar Humenn (University of Syracuse), Sekhar Vajjhala (Sun Microsystems). Posted by Tim Modes to the XACML mailing list. Send comments to: xacml-comment@lists.oasis-open.org. "This specification defines the syntax and semantics for XML-encoded access control rule statements and policy statements. The XACML schema is an extension schema for SAML... The context and schema of XACML are described in two models that describe different aspects of its operation. These models are: the data-flow model and the policy language model... Some of the data-flows shown [in the diagram] may be facilitated by a repository. For instance, the communications between the PDP and the PIP may be facilitated by a repository, or the communications between the PDP and the PRP may be facilitated by a repository or the communication between the PAP and the PRP may be facilitated by a repository. The XACML specification is not intended to place restrictions on the location of any such repository, or indeed to prescribe a particular communication protocol for any of the data-flows. The model operates by the following steps. (1) PAPs write rules and make them available to the PRP. From the point of view of an individual PAP, its rule statements may represent the complete policy for a particular target. However, the PRP may be aware of other PAPs that it considers authoritative for the same target. In which case, it is the PRP's job to obtain all the rules and (if necessary) use a PMP to remove any conflict amongst those rules and combine the rules in accordance with a meta-policy. The result should be a self-consistent rule statement. (2) The PEP sends an authorization decision request to the PDP, in the form of a SAML request. The decision request contains some or all of the attributes required by the PDP to render a decision, in accordance with policy. (3) The PDP locates and retrieves the policy statement applicable to the decision request from the PRP. (4) The PRP returns the complete policy to the PDP in the form of an XACML rule statement or policy instance. The PDP ensures that the decision request is in the scope of the policy statement or rule statement... [#5 - #9]... Policy Language Model: A rule statement contains: a ruleId; a target; an effect; a metaPolicyRef and a condition. Target defines the set of names for the: resources; subjects and actions -- to which the rule statement applies. If the rule statement applies to all entities of a particular type, then the target definition is the root of the applicable name space. An XACML PDP must verify that the resources, subjects and actions identified in an authorization decision request are each included in the target of the rule statement that it uses to evaluate the request. MetaPolicyRef specifies the meta-policy by which the rule statement may be combined with other rule statements..." See also the XML schema. References: "Extensible Access Control Markup Language (XACML)."

From the 'XACML Policy Proposal' document: "The current syntax for policy in XACL is oriented around the 3-tuple {subject, object, action}. The subject primitive allows user IDs, groups, and/or role names. The object primitive allows granularity as fine as a single element within an XML document. The action primitive consists of four kinds of actions: read; write; create; and delete. Additionally, the concept of a provisional action has been included in the XACL work. The provisional action primitive allows the specification of provisions to be attached to the access decision (e.g., 'Alice is allowed to read the salary field, provided that the access is logged'). This 3-tuple, or triplet, approach to policy language definition is simple and powerful for some environments, but is unfortunately limited -- in at least three ways -- for other environments. [1] Firstly, the built-in assumption that the object to be protected is (some portion of) an XML document is clearly unsuitable for environments that wish to protect other kinds of documents, data, devices, and so on. The XACML TC should not restrict itself to the notion that the only things that need access control in any organization are XML documents. [2] Secondly, the matching of a subject to an object can be of limited usefulness; more generally what is of value is the outcome of a comparison between a particular privilege of a subject and a particular property of an object... The XACL proposal makes a step toward this generality by allowing the subject to be a role name (since a role is simply a named collection of specific privileges), but does not allow the full generality because this mechanism prevents the assignment of privileges directly to users (i.e., assignment can happen only indirectly, through roles). Furthermore, the concept of object properties (sometimes called 'sensitivities') is not taken into account. The XACML TC should strive for the generality that will allow its output to be useful in many environments... [3] Thirdly, explicit inclusion of the action primitive within the policy language inherently limits the use of this language to actions that have been pre-defined by the standard-writers -- in particular, read, write, create, and delete. In any real-world environment, however (especially within any given vertical market), there will be many other examples of actions that warrant access protection (e.g., 'execute', 'initiate', 'approve', 'send', 'sign'). The primary purpose of standardization is interoperability; however, this cannot be achieved if the list of specified actions is incomplete and needs to be extended -- in a proprietary fashion -- within every environment. A preferred approach is to not specify the action primitive at all. In order to address the above limitations in the XACL policy language, the following language is proposed for consideration by the XACML Technical Committee. The language is essentially identical to the PrivilegePolicy syntax contained in an informative annex in the International Standard X.509, translated into XML (both DTD and Schema versions are included). The syntax (1) encompasses the generality of Boolean comparisons between privileges, sensitivities, and other relevant variables, (2) leaves the linkage to action primitives to the implementation environment, and (3) does not assume that the resource for which access control is desired is an XML document..."

Principal References

• XACML Technical Committee - Public Home Page
• Dashboard: OASIS Extensible Access Control Markup Language (XACML) TC
• XACML TC Charter
• XACML TC Document list
• XACML TC Document Repository
• XACML TC FAQ document
• XACML TC mailing list archives
• XACML TC Ballots
• XACML References. Edited by Anne Anderson (Sun Microsystems). Version 1.46, October 17, 2005 (or later). See the earlier versions.
• Sun Microsystems XACML Project Research Home Page
• XACML 1.0 - 2.0 Changes. Draft document posted by Bill Parducci on 24 May 2005. "This document summarizes the changes made in XACML since XACML 1.0 that appear in the XACML 2.0 specification."

XACML Implementations

• Sun's XACML Implementation. An open source implementation on SourceForge. As of January 2005, "Support for three new XACML 2.0 features has just been added to the CVS tree. Combining parameters, variable referencing, and policy versioning is now supported..."
• AX2E - AXESCON XACML 2.0 Engine. AX2E is an "implementation of the OASIS XACML standard, written in the Java programming language. AX2E requires the Java 2 Platform, Standard Edition version 1.4.0 or later... AX2E provides complete support for all the mandatory features of XACML 2.0 as well as a number of optional features. AX2E is built for easy extensibility and customization, through clearly defined public interfaces (APIs) and its component-based architecture. AX2E can be configured to use customized or completely new components, which can, for instance, implement new attribute data types or policy stores. AX2E passes all tests in current XACML 2.0 Conformance Test suite. This project was developed in AXESCON LLC..."
• See also the XACML TC web site and "Products and Deployments" in the XACML References document.

Other references [under revision]:

• OASIS eXtensible Access Control Markup Language (XACML) Committee Specification 1.0 (Revision 1). 12-December-2002. 130 pages.
• "XACML Access Control Markup Language Ratified as OASIS Open Standard. Universal Language for Authorization Policy Enables Secure Web Services." February 18, 2003.
• XACML Context Schema. 2002-12-13 [source]
• XACML Policy Schema. 2002-12-13 [source]
• TC Announcement 2001-04-17.
• Call 2001-04-16: "OASIS TC Call for Participation: XACML."
• Press release 2001-04-24: "OASIS Forms Technical Committee to Standardize Security Access Control with XML. Interoperability Consortium to Develop XACML."
• XACML TC mailing list archives
• XACML TC Members; [snapshot 2001-06-23]
• XACML Policy Proposal. [source]
• XACML Domain Model Reference: 'draft-xtc-use-domain-01'. Proposal. June 07, 2001. Posted by Gilbert Pilz. "Attached is my strawman proposal for the XACML Domain Model. Basically it is just a reference to the SAML Domain Model ['draft-sstc-use-domain-04', by Dave Orchard and Hal Lockhart] The definitions and descriptions contained within this document either serve as changes to or additions on the definitions and descriptions contained within the original document." [source]
• See also on access control and digital rights management:
  • Security Assertion Markup Language (SAML)
  • XML Access Control Language (XACL)
  • Open Digital Rights Language (ODRL)
  • Extensible Rights Markup Language (XrML)
  • Digital Property Rights Language (DPRL)
  • Extensible Media Commerce Language (XMCL)
  • MPEG Rights Expression Language
  • Open Ebook Initiative. [Cf. 'Rights and Rules Working Group']
  • Electronic Book Exchange (EBX) Working Group

---

News, Articles, Reports, Drafts, Papers

• [December 12, 2009] "A Non-technical User-Oriented Display Notation for XACML Conditions." By Bernard Stepien, Amy Felty, and Stan Matwin (School of Information Technology and Engineering (SITE), University of Ottawa, Canada, and Devera Logic, Inc., Ottawa, Canada). Presented at "E-Technologies: Innovation in an Open World" (Fourth International MCETECH Conference on e-Technologies, MCETECH 2009, Ottawa, Canada, May 4-6, 2009). Also published in Springer Lecture Notes in Business Information Processing (LNBIP) #26, pages 53-64, edited by Gilbert Babin, Peter Kropf, and Michael Weiss. "Ideally, access control to resources in complex IT systems ought to be handled by business decision makers who own a given resource (e.g., the pay and benefits section of an organization should decide and manage the access rules to the payroll system). To make this happen, the security and database communities need to develop vendor-independent access management tools, useable by decision makers, rather than technical personnel detached from a given business function. We have developed and implemented such tool, based on XACML. The XACML is an important emerging tool for managing complex access control applications. As a formal notation, based on an XML schema representing the grammar of a given application, XACML is precise and non-ambiguous. But this very property puts it out of reach of non-technical users. We propose a new notation for displaying and editing XACML rules that is independent of XML, and we develop an editor for it. Our notation combines a tree representation of logical expressions with an accessible natural language layer. Our early experience indicates that such rules can be grasped by non-technical users wishing to develop and control rules for accessing their own resources...

  The XACML (eXtensible Access Control Markup Language) access control language (ACL) is naturally precise since it is based on an XML schema that represents the grammar of a given application. But this very property puts it out of reach of nontechnical, and especially casual users that in some cases could even be computer illiterate. The main obstacles for a casual user in using XACML are: Long XML tags; Long and complex domain references; Prefix notation for operations; List-oriented notation for conjunction and disjunction operators. While it is practically impossible for a casual user to start coding rules with a text editor (this would require full knowledge of XML and XACML grammars) a first step toward solving this problem could be to use an XML editor that frees the user from this knowledge up to a certain point, as the supplied XML Schema enables the selection of appropriate tags in a context-oriented way..."

  XACML editors can be an effective and highly desirable tool, assisting nontechnical users in specifying complex XACML rules, e.g., for access and resource control. We have proposed here a simple yet powerful, implemented notation that allows users to perform this task by providing him a representation that is very close to natural language. Also, due to its high compactness, it provides a rare overview quality that is an important factor in reducing errors, thus helping to ensure the commercial success of the application... Our editor based on our notation is not intended to be a replacement for any XACML editor when the user is fully technically qualified. However, while our initial goal was to address the needs of casual, non-technical users, an additional benefit of this approach is that even technical users can easily specify very complex conditions, something that was stated as important to avoid in the past in the XACML user community. This has an important consequence of avoiding the splitting of complex rules into numerous rules with narrower targets, which produces large rule bases that become rapidly unmanageable..."

• [September 23, 2009] "CFP: W3C Workshop on Access Control Application Scenarios". — A Call for Participation has been issued for a "W3C Workshop on Access Control Application Scenarios," to be held November 17-18, 2009 in Luxembourg. "This workshop brings together worldwide research and user communities to explore evolving application scenarios for access control technologies, such as XACML. Results form a number of recent European research projects in the grid, cloud computing, and privacy areas show overlapping use cases for these technologies that extend beyond classical intra-enterprise applications. At this workshop, we will explore commonalities between different application scenarios, and standardization needs (at W3C and elsewhere) above and beyond the technology substrate that exists today. The workshop is co-financed by the European Commission 7th framework program via the Primelife Project. W3C membership is not required in order to participate in the Workshop. The workshop is intended to discuss issues around access control in very wide sense, encompassing conditions and rules derived from the fact of accessing information. Topics that might serve as appropriate discussion points for position papers include, but are not limited to: (1) interaction between access control and privacy policies; (2) language extensions to connect access control languages to novel types of credentials; (3) large-scale cloud and grid computing use cases for access control technologies; (4) policy management; (5) mechanisms for controlling progressive disclosure of information by user agents and servers; (6) the emerging role of trust delegation and supportive mechanisms in cloud computing, grid, and Web use cases; (7) mechanisms for richer user control over downstream data controllers... The Workshop Program Committee incudes: Michele Bezzi (SAP), Laurent Bussard (Microsoft), Marco Casassa-Mont (Hewlett-Packard), David Chadwick (University Kent), Franz Kudorfer (Siemens), Hal Lockhart (Oracle), Gregory Neven (IBM), Dave Raggett (W3C), Babak Sadighi (Axiomatics), Pierangela Samarati (University Milano), Amardeo Sarma (NEC), Rudolf Schreiner (ObjectSecurity), Rigo Wenning (W3C/ERCIM), and Philip Wieder (TH Dortmund)..."

• [August 03, 2009] Oracle and Cisco Contributions for XACML Authorization API and Attribute Manifest File Format (AMF). Materials contributed by Oracle and Cisco: "On behalf of Oracle and Cisco I am contributing the attached materials to the TC for inclusion in XACML specifications. All contributors stipulate that this contribution is in accordance with OASIS IPR policy." See the postings to the XACML TC Discussion List: "Contributions to OASIS XACML TC" and "Authorization Contributions Zip File", together with the XACML TC Repository. Details from the four resources in the main ZIP file:

  1. Overview Presentation: XACML Contributions. By Hal Lockhart, Oracle Corp. 11 slides. "Topics: Authorization API and Finding Input Attributes. (3) Authorization API. XACML 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 and output format. XACML does not specify: API for requesting policy decision. (4) Authorization API Benefits. Needed for call to local PDP: Local PDP required for low latentency 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 ... (7) Draft 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. (8) 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? (9) 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; Two use cases (a) PDP advertizes required attributes (b) PIPs are configured to add attributes to Request Context..." Source .PPT
  2. Java API Materials: A zip file containing the Java materials comprising the Authorization API. See the file listing, from the main contribution ZIP file.
  3. API Examples Document: Supplement to Authorization API. Contributors: Rich Levinson (Oracle Corporation) and Anil Tappetla (Cisco Systems, Inc). Version 0.8. July 16, 2009. 13 pages. "This document includes supplementary materials for the proposed Java Az API. The Az API is primarily intended to allow Authorization decisions to be made by an XACML-compliant PDP, but could also be used to access other types of PDPs that are capable of making use of the inputs provided. It is intended primarily for use by infrastructure components which have be configured to populate the request context with Attributes and/or invoke Authorization decisions, prior to the execution of specified Methods, however it also may be used by applications which have specialized requirements or need to provide inputs not available to the infrastructure..." Source .DOC.
  4. AMF Format Document: Attribute Manifest File. Version 0.8. July 16, 2009. Contributors: Hal Lockhart (Oracle Corporation) and Anil Tappetla (Cisco). 16 pages. "This document defines a format, called an Attribute manifest File (AMF), for communicating metadata about information, in the form of attributes which may be used in making access control policy decisions. It specifies an XML format for exchanging this data. It describes several usecases in which this data might be consumed. It also suggests how the data might be generated. However, it does not specify an specific processing algorithms or system architectures for its generation or consumption... This specification defines a data format which should allow callers of a PDP to provide information more closely tailored to policy needs, while not breaking the encapsulation of the PDP." Source .DOC.

• [August 03, 2009] "Finally: An Open XACML API." By Felix Gaehtgens. Kuppinger Cole Blog. For background and details, see: Oracle and Cisco Contributions for XACML Authorization API and Attribute Manifest File Format (AMF). "A new XACML API that has just been posted to the OASIS XACML TC... XACML, the Extensible Access Control Modeling Language is an XML-based standard for authorization and access control. It is based on the Attribute Based Access Control (ABAC) model that is hailed as the next generation of access control models. According to many, ABAC will ultimately replace RBAC (Role Based Access Control). Instead of only using a role as the determining factor whether to grant access or not, many attributes can be used. Of course roles can be used in ABAC as well — since ABAC can use multiple attributes to make access control decisions, the 'Role' can be one of those attributes — so ABAC can emulate RBAC perfectly while adding many additional advantages. This means that it is possible to add context to the access control decisions and adds for a finer granularity, tighter controls and more flexibility for the business... What has really been missing [with XACML] however was a ready-to-use API that would allow developers to make an access control request in their application and get a decision. Now we finally have an API that allows developers to do just that. I've spent over an hour yesterday hunched over my brand-new netbook with Prateek and Pat Patterson, poring over the API and can only say: thumbs up! [...]

• [April 03, 2009] "XACML v3.0 Hierarchical Resource Profile Version 1.0. Working Draft 7. 01-April-2009. 22 pages. Edited by Erik Rissanen (Axiomatics AB), Rich Levinson (Oracle), and Hal Lockhart (Oracle). Posted to the OASIS Extensible Access Control Markup Language (XACML) TC discussion list and Kavi repository by Hal Lockhart (with details).

  "This document provides a profile for the use XACML with resources that are structured as hierarchies. The profile addresses resources represented as nodes in XML documents or represented in some non-XML way. The profile covers identifying nodes in a hierarchy, requesting access to nodes in a hierarchy, and specifying policies that apply to nodes in a hierarchy... It is often the case that a resource is organized as a hierarchy. Examples include file systems, XML documents, and organizations. This Profile specifies how XACML can provide access control for a resource that is organized as a hierarchy. Why are resources organized as hierarchies special? First of all, policies over hierarchies frequently apply the same access controls to entire sub-trees of the hierarchy. Being able to express a single policy constraint that will apply to an entire sub-tree of nodes in the hierarchy, rather than having to specify a separate constraint for each node, increases both ease of use and the likelihood that the policy will correctly reflect the desired access controls. Another special characteristic of hierarchical resources is that access to one node may depend on the value of another node. For example, a medical patient might be granted access to the 'diagnosis' node in a XML document medical record only if the patient's name matches the value in the 'patient name' node. Where this is the case, the requested node can not be processed in isolation from the rest of the nodes in the hierarchy, and the PDP must have access to the values of other nodes. Finally, the identity of nodes in a hierarchy often depends on the position of the node in the hierarchy; there also may be multiple ways to describe the identity of a single node. In this Profile, a resource organized as a hierarchy may be: (1) a '(rooted) tree' (a hierarchy with a single root), (2) a 'Directed Acyclic Graph' or 'DAG' (a hierarchy with multiple roots, but a DAG may not have cycles; also, a DAG may be expanded to an equivalent set of disjoint hierarchies, a fact, which is useful to know when conceptualizing the hierarchical properties of the DAG), (3) a'polyarchy' (a 'forest', which is a disjoint set of trees, which when applied to a collection of resources may be designed to become a polyarchy, because each disjoint tree is layed on the same collection of resources, and nodes from disjoint trees, in general, may refer to the same resource, and as a result, with respect to the resource, merge to become a single node, which organizes the resources as a polyarchy; note also, that by jumping from one disjoint tree to another while on an intersecting node, that the polyarchy may contain cycles, which are not possible with the DAG).

  All such resources are called hierarchical resources in this Profile. An XML document is always structured as a 'tree'. Other types of hierarchical resources, such as files in a file system that supports links, may be structured as a 'forest'. In this Profile, the nodes in a hierarchical resource are treated as individual resources. An authorization decision that permits access to an interior node does not imply that access to its descendant nodes is permitted. An authorization decision that denies access to an interior node does not imply that access to its descendant nodes is denied... This Profile addresses three ways of representing a hierarchical resource. [A] In the first way, the hierarchy of which the node is a part is represented as an XML document that is included in the Request, and the requested resource is represented as a node in that document. [B] In the second way, the resource must be a part of one or more singly rooted hierarchies. The resource is identified using a hierarchical URI which reflects the resource's place in these hierachies. [C] In the third way, the resource may be a part of one or more singly or multiply rooted hierarchies. The parent and other ancestor nodes of the resource are identified as attributes in the request. The naming of the resource (or its ancestors) has no significance in terms of describing the structure of the hierarchy. Note that the actual target resource in the first case need not be part of an XML document — it is merely represented that way in the Request. Likewise, the target resource in the second case might actually be part of an XML document, but is being represented in some other way in the Request... [reference page and .DOC source]

• [July 24, 2008] "The Theory of (Identity) Relativity." By Steve Coplan. Plausible Deniability - The official blog of The 451 Group's Enterprise Security Practice (ESP). "I was watching closely (albeit from afar), the observations and epiphanies emerging from the the Burton Group's Catalyst conference last month. One of the more interesting conclusions is that identity management is at a crossroads where even the outlines of the intersection are unclear — what I like to describe as a paradigm vacuum, although there are others who view it as a journey where the next destination is uncertain... Now we can see identity management from a different angle: it's not a matter of putting human relationship into system terms but managing the intersection between human organizations and systems, data and resources. I am still wrestling the idea that what's implied here is a resource-based model since at some level the resource and identity have to be reconciled in terms of policy and business definitions... There are a number of proposals on how we get there — the Internet Governance Framework's CARML being one example — and we expect to see a lot more action in the directories realm than we have in years. My vote for protocol of the year goes to XACML, though. The language has its issues, is still too complex for developers to easily code policy and is verbose enough to create latency issues. However, of the vendors we have spoken to looking at being the logic and infrastructure behind that policy management layer — NextLabs, Axiomatics, Rohati, Jericho Systems, ObjectSecurity, BitKOO and Cisco Securent (in no particular order) — all use XACML to communicate policy..."

• [July 02, 2008] "Context Dependent Revocation in Delegated XACML." By Erik Rissanen (Axiomatics AB) and Ludwig Seitz (Swedish Institute of Computer Science, SICS AB, Sweden). SICS Technical Report T2008:10. June 2008. ISSN: 1100-3154. 13 pages, with 10 references. Also available in PostScript format. Abstract: "The XACML standard defines an XML based language for defining access control policies and a related processing model. Recent work aims to add delegation to XACML in order to express the right to administrate XACML policies within XACML itself. The delegation profile draft explains how to validate the right to issue a policy, but there are no provisions for removing a policy. This paper proposes a revocation model for delegated XACML. A novel feature of this model is that whether a revocation is valid or not, depends not only on who issued the revocation, but also on the context in which an attempt to use the revoked policy is done... Informally, in our model someone with the authority to support a policy, either directly or indirectly, can also revoke it. The motivation for choosing this model is that in many cases it is natural for the right to issue and revoke to go together. Also, being able to indirectly support a policy implies authority over the policy, so it is not far fetched to allow for revocation of indirectly supported policies. An alternative would be to only allow to revoke policies which are directly supported, which has the benefit that such a model is not NP-complete. Note however, that since our revocations cascade, revoking a directly supported policy also invalidates indirectly supported policies... The central novel feature of our model, which is not captured by any of the characteristics described [in Hagström, Barka and Sandhu, Sadighi] , is that the effect of a revocation depends on which access request is being processed. We call this characteristics context dependency. A revocation which is context independent will have the same effect on a permission regardless for what the permission is used. We are not aware of any other access control model which has context dependent revocation." See the associated posting from Erik Rissanen to the OASIS XACML TC list: "The paper presents a revocation model for the draft delegation profile in 3.0, where the model could be summarized as 'You may revoke those policies which you could create yourself'. The use case is that administrators may change positions, in which case each administrator should be able to handle those policies which are his duties, whether they were issued by him in person, or someone else. This is in contrast to the more typical revocation model, for instance in X.509 PKI, where the issuer of something is the authority of revocation. In the model we wanted the already existing administrative policies also to define the scope of rights to revoke policies in addition to the scope of rights to issue policies." [cache]

• [June 28, 2008] "Use of XACML Request Context to Obtain an Authorisation Decision". Open Grid Forum (OGF). Edited by David W. Chadwick, Linying Su, and Romain Laborde (University of Kent, Information Systems Security Group). Document type: P-REC (Proposed Recommendation). Announced for public comment through August 13,2008. OGF Area: Security. Produced by members of the OGSA Authorization WG (OGSA-AUTHZ-WG), chartered to define the specifications needed to allow for basic interoperability and plug-ability of authorization components in the OGSA framework. "The purpose of this document is to specify a protocol for accessing a Policy Decision Point (PDP) by a Grid Policy Enforcement Point (PEP) in order to obtain access control decisions containing obligations. The protocol is a profile of the SAML2.0 profile of XACML, tailored especially for grid use. This document describes how an XACML request context can be created and transferred by a Grid Policy Enforcement Point (PEP) to a Police Decision Point (PDP) in order to obtain authorisation decisions (possibly including obligations) for Grid applications. The XACML request context contains attributes of the subject, resource, action and environment, and is transported to the PDP in a SAMLv2 request message. The XACML response context contains an authorization decision and optional obligations that must be enforced by the PEP, either before, with or after enforcement of the user's request... The SAML2.0 profile of XACMLv2.0 specifies extensions to SAML2.0 to enable an XACML request context to be carried in a SAML request message to a PDP, as an XACMLAuthzDecisionQuery extension; and an XACML response context to be carried in a SAML response message to the PEP, as an XACMLAuthzDecisionStatement extension. This profile uses the SAML2.0 profile of XACMLv2.0 specified in Section 3 of "SAML 2.0 profile of XACMLv2.0" to carry the XACMLAuthzDecisionQuery (as a SAML Request extension) and return the XACMLAuthzDecisionStatement (as a SAML Statement extension used in a SAML Response)..." [cache]

• [April 18, 2008] XACML 2.0 RSA 2008 Interop Scenarios. Working Draft. Version 0.12. 15-April-2008. 60 pages. From the ZIP archive; see the file listing. Edited by Rich Levinson (Oracle Corporation), Erik Rissanen (Axiomatics), David Staggs (Department of Veterans Affairs - SAIC), Denis Pilipchuk (BEA Systems, Inc), Duane DeCouteau (Department of Veterans Affairs - Edmond Scientific Company), Dilli Dorai (Sun Microsystems), and Mike Davis (Department of Veterans Affairs). This document specifies scenarios that may be used to demonstrate interoperability of multiple PDP, PEP, and PIP modules that were implemented based on the XACML 2.0 Core Specification. It covers Healthcare Fine Grain Authorization Use Cases, Coarse Grain Authorization Decision Request/Response, and Policy Exchange The XACML 2.0 Specification defines an XML-oriented policy language, which is intended to be used at a Policy Decision Point (PDP) to represent the set of policies that the PDP will use to evaluate decision requests received from a Policy Enforcement Point (PEP). Policies contain expressions that define dynamic access relationship conditions between subjects and resources based on attributes associated with the subject(s) making an access request, attributes associated with the resource(s) to which access is being requested, attributes associated with the action intended to be applied to the resource, and attributes of the operational environment (such as time of day). The PDP determines the set of policies that are applicable to the request, evaluates the applicable policies by collecting attribute information from the request and using it where appropriate in the policy expressions and returns a decision, which may be one of: permit, deny, indeterminate, or not applicable... The Interop demonstrates how it is possible to use XACML to separate access control logic from the business logic provided by an application. The application does not make access control decisions itself; rather it exports its resource model to the policy writers. The access control policy is then defined with XACML based on the vocabulary that the application provides. The Interop demonstrates how an HL7-based access control vocabulary model can be implemented using XACML. However, a completely different access control model would be possible. For instance if the same medical application is deployed in a different regulatory environment, the access control model can be changed in the XACML policies, without modifications to the application itself. This benefits the application vendor as the same application can be used by a wider audience, and the customers who get access to a wider selection of applications and better flexibility..." Note from submitter: "The zip file contains the Interop document which describes the messages and policies used in the RSA Conference 2008 USA XACML 2.0 Interop conducted at the RSA Conference April 7-10, 2008. The zip file contains the document plus the XML files for the policies used at the Interop, plus a collection of test messages that were used prior to the Interop. The policies and messages are copied directly from the document to the XML files with the exception of some additional test messages that simple derivations from the test messages contained in the (prose) doc." [source ZIP file, prose .DOC]

• [June 28, 2007] "Eight Companies Demonstrate Interoperability of XACML OASIS Standard at Catalyst Conference BEA Systems, CA, IBM, Jericho Systems, Oracle, Red Hat, Securent and Others Showcase Access Control Standard in a Web Server Environment." — At Burton Group's Catalyst Conference on June 28, 2007, eight companies joined together for the first time to demonstrate interoperability of the Extensible Access Control Markup Language (XACML) 2.0 OASIS Standard. An extremely flexible language for expressing access control, XACML is particularly designed to support large-scale environments where resources are distributed and policy administration is federated. XACML 2.0 is also ITU/T Recommendation X.1142. The Catalyst demonstration includes two scenarios. In the first, different implementations exchange XACML policies that control access for a variety of Web server addresses. This demonstrates the ability of different implementations to understand the language defined by XACML. In the second scenario, authorization decisions are enforced by applications based on interaction with an external policy decision point. Both the application and the policy decision point can be independently implemented, and communication between them will use the XACML Security Assertion Markup Language (SAML) Authorization Decision Request Protocol. This shows how components such as services, applications and containers are able to defer to a centrally managed authorization service when making authorization decisions. Dan Blum, senior vice president and research director of the Burton Group: 'Access control is a requirement of almost every application. XACML goes beyond simply denying or granting information access; it defines the mechanism for creating the rules and policy sets that enable meaningful authorization decisions'... See also XACML interoperability demo details

• [June 26, 2007] "NETCONF Access Control Profile for XACML." Edited by Ludwig Seitz (SICS, Swedish Institute of Computer Science AB) and Erik Rissanen (Axiomatics AB). IETF Network Working Group. Internet Draft 'draft-seitz-netconf-xacml-00.txt'. June 25, 2007, expires December 27, 2007. 26 pages. The NETCONF remote network configuration protocol currently lacks an access control model. The NETCONF protocol RFC (RFC 4741) specifies in its Section 9 Security Considerations that "This document does not specify an authorization scheme, ... Implementors SHOULD provide a comprehensive authorization scheme with NETCONF". The need for such a model has be recognized within the NETCONF working group. The Extensible Access Control Markup Language (XACML) is an XML-based access control standard, with widespread acceptance from the industry and good open-source support. This document proposes a profile that defines how to use XACML to provide fine-grain access control for NETCONF commands. The reasons why the use of XACML is suggested are the following: (1) XACML is an open standard that has been developed by an industry consortium; (2) XACML is an XML based approach, that is well adapted to the authorization challenges encountered within NETCONF; (3) XACML is widely accepted and used in a number of commercial products; (4) Open-source implementations of the XACML standard are readily available. The memo defines how a PEP should generate a XACML request from a RPC carrying a NETCONF operation. The response to this request determines whether the RPC is processed or discarded. Furthermore this profile defines how policies corresponding to permissions about a specific NETCONF operation on specific data should be formulated... [The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange.]

• [May 28, 2007] "NAC 2007 Spring Conference: OASIS XACML Update." By Hal Lockhart (Office of the CTO, BEA Systems). Network Applications Consortium (NAC). Presented at NAC 2007 ("Enterprise Authorization Management: Policy Administration, Interpretation & Enforcement"), hosted by Cisco in San Jose, CA, USA, April 24-26, 2007. 38 slides. The presentation covered the following topics: Overview of Policy and Authorization; XACML Overview; XACML Concepts; Policy Evaluation; XACML Profiles; XACML 3.0; XACML Interoperability Demo. "Information security" refers to technologies and procedures intended to implement organizational policy in spite of human efforts to the contrary. It concerns policy determination (Expression: code, permissions, ACLs, Language; Evaluation: semantics, architecture, performance) and Policy enforcement (Maintain integrity of Trusted Computing Base - TCB; Enforce variable policy). The OASIS XACML TC was chartered to define a core XML schema for representing authorization and entitlement policies. Target: any object, referenced using XML. It provides fine grained control, characteristics - access requestor, protocol, classes of activities, and content introspection; it is consistent with and building upon SAML. Current work in XACML 3.0: Administration/Delegation; Schema generalization; WS-XACML; Obligation combining rules; Policy provisioning; Metadata/vocabulary advertisement; Closely coupled PDP/PEP. WS-XACML [Web Services Profile of XACML] defines XACML-based policy assertions for authorization and privacy. These can be used in a WS-Policy instance along with other types of web services policy assertions, or can be used as independent service meta-data. The profile defines two new assertion types, one for authorization and another for privacy. An XACML Interoperability Demonstration is planned for the Burton Catalyst Conference in San Francisco (June 25-29, 2007); tentative participants include BEA, IBM, Jericho Systems, Oracle, Red Hat, Securent, and Symlabs. Note on NAC: "NAC is a consortium of IT end-user organizations representing combined revenues of over $800 billion, more than 55,000 network servers, and more than 1 million workstations. Since its founding in 1990, NAC has emerged as a premier group of information technologists dedicated to promoting integration, interoperability, and member and vendor collaboration." [source .PPT file]

• [May 22, 2007] XACML Interoperability Demonstration at Burton Group Catalyst Conference. An Interoperability Event for XACML is being planned for the Burton Catalyst Conference in San Francisco, 28-June-2007. See Burton Catalyst Conference Will Feature XACML Interoperability Demonstration: Seven companies will collaborate to demonstrate interoperability of the Extensible Access Control Markup Language (XACML) 2.0 OASIS Standard at the Burton Catalyst Conference North America 2007 in San Francisco, 28-June-2007. Optimized for large-scale, federated environments, XACML specifies the syntax and processing rules for authorization. In the demo, multiple XACML components are deployed in a hypothetical high value stock portfolio account, where customer and account managers coordinate and approve transactions. Each vendor's implementation will exchange policies with others, and policy enforcement points will request authorization decisions from one another. BEA Systems, IBM, Jericho Systems, Oracle, Red Hat, Securent, and other TC members will participate in this event... "In the first scenario, different implementations exchange XACML policies that control access for a variety of Web server addresses. This demonstrates the ability of different implementations to understand the language defined by XACML. In the second scenario, authorization decisions are enforced by applications based on interaction with an external policy decision point. Both the application and the policy decision point may be independently implemented, and communication between them uses the XACML Security Assertion Markup Language (SAML) Authorization Decision Request Protocol. This shows how components such as services, applications and containers can defer to a centrally managed authorization service when making authorization decisions." Burton Group Inflection Point Podcast, with Hal Lockhart and Rich Levinson (25.29 minutes, MP3).

• [May 21, 2007] "OGC Announces Public Review for GeoXACML and OpenGIS Image Geopositioning Service (IGS) Draft Specifications." Cover Pages News. The Open Geospatial Consortium announced a call for public comment on two draft OpenGIS Implementation Specifications: GeoXACML and OpenGIS Image Geopositioning Service (IGS). The draft Geospatial Extensible Access Control Markup Language (GeoXACML) Implementation Specification defines a geo-specific extension to the Extensible Access Control Markup Language (XACML) OASIS Standard. The OGC GeoXACML draft clarifies that access control systems enable management of access to information only until it is obtained by the user and stored locally, as opposed to rights management systems that remain in force regardless of where the content of the original resource is located or reproduced. The second OGC draft released for public comment is the OpenGIS Image Geopositioning Service (IGS) Draft Implementation Specification. This document defines an Image Geopositioning Service (IGS) interface to services that perform triangulation. Accompanying the IGS draft specification is a separate OpenGIS Image Geopositioning Metadata Geography Markup Language (GML) Draft Application Schema, which is structured to provide consistency between the IGS and other OGC Web Services (OWS) specifications. OGC also recently published KML 2.1 Reference -- An OGC Best Practice. KML is a file format used to display geographic data in an Earth browser, such as Google Earth, Google Maps, and Google Maps for Mobile. KML uses a tag-based structure with nested elements and attributes and is based on the XML standard.

• [March 19, 2007] "Securent Joins With OASIS to Help Advance Open Standards for Application Entitlement Management. Application Entitlement Management Leader Leverages XACML 2.0 OASIS Standard to Provide Customers Fine-Grained Access Control Over Applications and Data." — "Securent, Inc., the award-winning leader in the Application Entitlement Management market, today announced that it is a Sponsor Member of the Organization for the Advancement of Structured Information Standards (OASIS). OASIS is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards, such as the Extensible Access Control Markup Language (XACML). Securent will work with OASIS toward the advancement of current and emerging standards, including XACML, by sharing its expertise in open architectures and best practices learned by addressing customers' needs for application and data security, and compliance. Last year, Securent unveiled the industry's most robust enterprise application entitlement management system based on open industry-accepted standards. By delivering its Entitlement Management Solution (EMS) as an XACML-compliant product, Securent has provided customers such as Credit Suisse and Qualcomm with a scalable and cost-effective alternative to custom coding fine-grained access controls into applications. 'Securent's decision to implement XACML 2.0 in its Entitlement Management Solution is indicative of the value this standard is capable of delivering to real-world enterprise customers,' said James Bryce Clark, director of standards development at OASIS. 'We applaud enterprises that select open standards-based solutions over proprietary alternatives. We look forward to working with Securent to further the advancement of XACML, and further XACML's penetration in the marketplace as a standard that defines access control policy language and protocol.' Securent EMS is comprised of three XACML-based components that empower IT administrators and business users to administer, enforce, audit and review role- and rule-based policies — the Policy Administration Point (PAP), the Policy Decision Point (PDP), and the Policy Enforcement Point (PEP). The open architecture is vastly different from conventional entitlement management products and toolsets that are tied to specific vendor platforms, making them difficult to integrate, manage, and scale across heterogeneous IT environments. By complying with the XACML OASIS Standard, Securent addresses customer concerns about vendor lock-in of current proprietary solutions. This is especially important as more commercial, off-the-shelf applications and infrastructure components are exposing their entitlement policies in XACML, which drives the market for an XACML-based entitlement management solution. Moreover, as customers participate in the OASIS XACML Technical Committee, they help make it a stronger standard, further increasing its broad applicability..."

• [March 16, 2007] "Web Services Profile of XACML (WS-XACML). By Anne Anderson (Sun Microsystems Labs). Presented at the XACML TC Face-to-face Meeting, March 2007. 34 slides. "The presentation I made at the XACML Face-to-Face meeting on 13 March 2007 on the Web Services Profile of XACML (WS-XACML) is now available...(from the Sun Microsystems XACML Project area)". Outline: Web Services Policy Background; XACML Web Services Policy Assertions; XACML Assertion Format; XACML Assertion Matching; Defined XACML Assertions [XACMLAuthzAssertion, XACMLPrivacyAssertion]; New XACML Functions and Attribute Identifiers; Open Issues. See Web Services Profile of XACML (WS-XACML) Version 1.0 (Working Draft 8, 12-December-2006), edited by Anne Anderson, with XML Schema. Abstract: "This document specifies ways to use XACML in the context of Web Services for authorization, access control, and privacy policies. It specifies four types of information. (1) An authorization token or credential based on XACML to be used in a Web Services context for conveying an authorization decision from a trusted third party to a Web Service. (2) A policy Assertion type based on XACML elements for use with WS-Policy or other schemas and protocols; this Assertion may be used to convey both requirements and capabilities related to authorization, access control, and privacy for Web Service clients and for the services themselves. This Profile specifies standard formats, matching semantics, and usage guidelines for two Assertions derived from this type: one for authorization policies and the other for privacy policies. (3) Some ways in which Attributes for a client MAY be passed to a Web Service as part of a SOAP message in such a way that they can be authenticated as having been issued by a trusted authority. These Attributes may be used by the Web Service in evaluating the internal XACML policies of a service or enterprise that are relevant to a given Web Services access. (4) How to express P3P policy preferences and match them using the new Assertion based on XACML..." [PDF source]

• [March 16, 2007] "Waiting on XACML: An Interop Challenge for the Industry." By Gerry Gebel (February 23, 2007). "The Extensible Access Control Markup (XACML) standard has matured enough to be supported in a growing number of commercial identity management products. And several other vendors have put XACML support in their 2007 product plans. Version 2.0 of XACML was formally ratified in March 2005 and the OASIS technical committee is working on improvements for version 3.0. As noted in a previous post, many enterprises have embarked or are considering entitlement management projects where the authorization standard plays a significant role. Despite the growing use of and interest in XACML, there has never been an interoperability demonstration event, and there is no formal certification or interoperability program like the one Liberty Alliance operates for the SAML 2.0 and Liberty specifications. When does this become an issue for the industry? Will the need for interoperability grow as adoption of XACML-based products increases? Can enterprises really mix and match policy administration points (PAPs), policy decision points (PDPs), and policy enforcement points (PEPs) from different vendors? Is the XACML RBAC Profile practical? Or will we find that different interpretations of the specification yield less than satisfactory levels of interoperability? An interoperability demonstration can't answer all of these questions, but it can provide an important indicator of the state of the market... Is it time for an XACML interoperability event? We [at Burton Group] think so and have invited vendors to come up with a game plan for the conference [Burton Group Catalyst Conference North America 2007] this year..."

• [March 12, 2007] "Entitlement Management: The Next Security Wave." By Linda Musthaler. Technology Executive Newsletter. From Network World (March 12, 2007). "There's a new way of looking at security for your enterprise applications. It's called entitlement management. Burton Group analyst Gerry Gebel calls it an important new development in the security arena — one that you'll want to bring into your organization soon... Traditionally, entitlements have been built into each application your enterprise has. The new strategy is to remove access management from the applications and run it as a shared service in front of the applications. Entitlement management can be used to strengthen the security of Web services, Web applications, legacy applications, documents and files, and physical security systems. This approach has several benefits. First and foremost, it gives you the ability to implement a data-driven policy that is consistent across all applications. This is becoming more important in the face of regulatory pressures from Sarbanes-Oxley, HIPAA, PCI and the like. With an entitlement management service, you can simplify your audit and compliance burden. In addition, the approach gives you tighter, more granular security that is more specific to your set of users. With centralized access policies, the moment a policy is entered or updated, all applications automatically receive the benefit of the new/updated rule. And, your applications can become less complex and easier to maintain if you remove the entitlement layer from within them. When you want to implement policy changes, you don't need to modify your application code; rather, you configure the new policy at the external service level. There are several vendors with products on the market today. Many have chosen a three module architecture consisting of the Policy Administration Point (PAP) to provide centralized administration management; the Policy Decision Point (PDP) to evaluate resource-specific authorization policies; and the Policy Enforcement Point (PEP) to enforce the entitlement policies. Rajiv Gupta, founder and CEO of Securent, says that entitlement management is a strategic layer in the enterprise, and that it will take years for most companies to deploy one across their entire company. Many have deployed it across key applications and lines of business in only a few months time, though. He doesn't expect many organizations are willing to rewrite custom applications to remove the entitlement layer today. However, as more companies adopt the notion of a service-oriented architecture (SOA), entitlement management will certainly be a critical service to centralize..." Related: "Start-up Securent aims at 'entitlement management', by Ellen Messmer (Network World, 2006-11-13: "... Securent is carving out a niche for itself with the first software entirely based on the Extensible Access Control Markup Language (XACML) 2.0 standard...").

• [January 20, 2007] "Keeping Track of Authorization Management." By Gerry Gebel. Blog (January 20, 2007). "It's been very interesting to follow the ascension of authorization management as an important segment of the IdM market over the course of the last year. The challenge of handling authorizations across a vast array of applications is not a new problem, certainly — but a number of stars have aligned to alter the market recently. Namely, there is the maturation of the Extensible Access Control Markup Language (XACML) standard, the appearance of startup vendors like Securent and Jericho Systems, and the pressing need by enterprises to enforce business, security, and regulatory policies across applications... Shekhar Jha was in attendance [Catalyst 2006 in June] and posted comments to his blog. James McGovern is also a frequent commenter on authorization in general and XACML in particular on his blog. When contemplating authorization management scenarios, I'm hearing a common set of questions, such as: (1) I have thousands of applications with almost uncountable resources, transactions, data elements, etc. How do I catalog all of this? How do I determine which are in play? (2) How can the namespace for all the rules be managed efficiently? (3) How much granularity is really needed? Isn't this overkill? (4) Won't performance be an issue if I have to process all this XML data? (5) Is XACML expressive enough for my needs? (6) Will this work for COTS applications? (7) How much authorization should be externalized from applications? These are great questions and help to cool the hype around this technology a bit..."

• [October 10, 2006] Web Services Profile of XACML (WS-XACML) Version 1.0. Edited by Anne Anderson. Working Draft 05. 9-October-2006. "This document specifies ways to use XACML in the context of Web Services for authorization, access control, and privacy policies. It specifies three types of information. 1) An authorization token or credential based on XACML to be used in a Web Services context for conveying an authorization decision from a trusted third party to a Web Service. (2) An Assertion based on XACML for use with WS-Policy; this Assertion may be used to convey both requirements and capabilities related to authorization, access control, and privacy for Web Service clients and for the Services themselves. The profile specifies standard formats, matching semantics, and usage guidelines for this Assertion. (3) Some ways in which authenticated Attributes for a client MAY be passed to a Web Service as part of a SOAP message. These Attributes may be used by the Web Service in evaluating internal XACML policies... WS-Policy provides a framework for expressing alternative sets of policy Assertions from various domains, such as security, and reliable messaging, that are supported by a service. But there are no WS-Policy Assertions defined for authorization, access control, or privacy policies. This profile defines a format for such Assertions and describes their use in Web Services policies... The profile specifies how to use existing XACML SAML Assertions in the context of Web Services, and also defines one new schema element: 'XACMLAuthzAssertion'. The 'XACMLAuthzAssertion' [element] allows clients and services to express their Web Service authorization requirements and capabilities, and to match requirements and capabilities between clients and services. The format and usage of this element is described in the profile..." Author's followup (with some major changes) and original note This is a major revision of XACML profile for Web-services (WSPL), designed to address the current Web Services policy environment. It contains some core functionality from WSPL, but confines its use to authorization, access control, and privacy Assertions for use with WS-Policy. It also adds two new specification sections: use of XACML authorization decisions as authorization tokens, and conveyance of Attributes for use by an XACML Context Handler as part of Web Services messages. This draft is not complete. It is being published now for feedback and discussion on the scope and general direction..." source PDF

• [September 27, 2006] Overriding of Access Control in XACML. By Ja'far S. Al-Qatawna. Submitted in partial fulfillment of the requirements for The Master degree in Information and Communication Systems Security at the Royal Institute of Technology Sweden. 2006. 70 pages. MSc Theses, KTH, Number 2006-x-412. ['This thesis has been carried out at Security, Policy and Trust Laboratory (SPOT) of the Swedish Institute of Computer Science (SICS), which is an independent non-profit research organization. The thesis is part of an ongoing project in which SPOT investigates the use of XACML as a policy language for distributed services in the highly dynamic and decentralised networks.'] "In a networked environment, information needs to be protected, therefore authorization and access control systems have been studied in the field of computer security for a long time, as a result of that, many access control mechanisms have been developed. Most of these mechanisms focused on how to define users' rights in a precise way to prevent any violation for the access control policy. To some degree classical access control models are not flexible; they either permit access or deny it completely. The access control decision is made based on the assumption that all access needs are known in advance, and these needs can be expressed by machine readable code. In many situations it's hard to predefine all the access needs, or even to express them in machine readable code. One example of such situation is an emergency case which can not be predictable. A discretionary overriding of access control mechanism is one way for handling such hard to define and unanticipated situations. The override mechanism gives the subject of the access control policy the possibility to override the denied decision, given that the subject should confirm the access (on his discretion), the access will be logged for auditing, and notification will be sent for the responsible authority. Since the override mechanism covers more access needs and helps in writing complete access control policy, the goal hers is introducing this mechanism in a standard way, which will make it applicable for wide range of applications and suitable for distributed systems where a common access control language is needed. In this thesis, the discretionary overriding of access control has been introduced in the standardized framework of the eXtensible Access Control Markup Language (XACML) which gives common language for expressing access control mechanisms. XACML has been extended to support the override mechanism. The override has been introduced as XACML obligation, and since XACML lacks a defined way for combining obligations, a new obligations-combining algorithm has been proposed. The proposed solution provides a general way for combining XACML obligations that can be used to create a chain of obligations-combining algorithms; each has its own purpose and particular type of obligations. As a proof of concept, the general solution has been implemented using Sun Microsystems open source of XACML. This helps in checking if the solution gives the intended result and if it works properly with different XACML components..." [cache]

• [August 28, 2006] "Privacy Preserving Trust Authorization Framework Using XACML." By Uche Mbanaso (University of Salford), Grahame Cooper (University of Salford), David Chadwick (University of Kent), and Seth Proctor (Sun Microsystems Labs). Pages 673-678 in Proceedings of the IEEE 2006 International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2006). "Nowadays many organizations share sensitive services through open network systems and this raises the need for an authorization framework that can interoperate even when the parties have no pre-existing relationships. Trust Negotiation is the process used to establish these first relationships, through the transfer of attributes, embedded in digital credentials, between the two parties. However, these attributes may themselves be considered sensitive and so may need protection from disclosure. In some environments, the policies that govern the protected services may also be considered sensitive and their release to arbitrary strangers may leak confidential business information. This paper describes a way to unify the protection of services, sensitive credentials and policies in a synchronized trustworthy manner. We propose a trust authorization framework (TAF) that builds on the capabilities of XACML to support the bilateral exchange of policies and credentials through trust negotiation... We demonstrate how the XACML model can be explored to enable privacy and trust whilst protecting access to electronic resources in a synchronized manner. We describe how to construct effective trust policy sets, which can optimize trust establishment sessions, and propose a new trust layer component in the primitive XACML model. We have leveraged trust concepts already proposed by researchers and show how our model optimistically addresses the problem of probing attacks such that the risk to which a party is exposed at any point in the negotiation can be minimized. Our framework has the capabilities to protect resources, policies and credentials simultaneously in distributed environment for users with or without pre-existing trust relationships. The implementation of this framework is in an advanced stage using the Sun XACML implementation and the PERMIS Attribute Verifier subsystem..."

• [June 30, 2006] "Domain-Independent, Composable Web Services Policy Assertions." By Anne H. Anderson. Paper presented at the 7th IEEE International Workshop on Policies for Distributed Systems and Networks, 6 June 2006. The paper is available in Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY '06). Anne Anderson describes how the current model for the predicates, or "Assertions", used in a WS-Policy instance is for each policy domain to design new schema elements for that domain's Assertions. "Their semantics are defined in an associated specification and are domain-specific. This model leads to interoperability and maintenance problems and hinders dynamic service composition. WS-PolicyConstraints is a domain-independent language for writing Assertions that is based on the Web Services Policy Language subset of XACML; it differs in addressing only the Assertion layer. This paper describes problems with domain-specific Assertions, the WS-PolicyConstraints alternative, and problems encountered in the development of this language." The paper concludes that "WS-PolicyConstraints promises to significantly reduce the cost of supporting new Assertions. It can improve interoperability and maintainability of Web Services policy processors as well as allowing free development of new application-specific Assertions without requiring changes to deployed policy processors. Since the semantics it must support are limited to a fixed set of functions, it is easy to test an implementation of WS-PolicyConstraints for correctness. WS-PolicyConstraints has not yet been implemented, but most of its functions are taken from XACML, which has been widely deployed and has an unencumbered open source implementation available; its function matching and intersection operations are taken from WSPL, which has been implemented and used successfully. WS-PolicyConstraints has been successfully used to express a significant collection of domain-specific Assertions, demonstrating its flexibility and expressive power." See also: "WS-Security Policy Profile of WS-PolicyConstraints." [cache]

• [April 13, 2006] SAML 2.0 Profile of XACML. Working Draft 1. 12-April-2006. Document identifier: 'xacml-2.1-profile-saml2.0-spec-wd-1'. Produced for the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee. Details in the posting with "Notes on the updated SAML profile." The "SAML 2.0 Profile of XACML" specification defines a profile for the use of the OASIS Security Assertion Markup Language (SAML) Version 2.0 to carry XACML 2.0 policies, policy queries and responses, authorization decisions, and authorization decision queries and responses. It also describes the use of SAML 2.0 Attribute Assertions with XACML. This document, produced for the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee revises and updates the OASIS Standard SAML 2.0 Profile of XACML 2.0. It incorporates the errata found in the OASIS Standard SAML 2.0 Profile of XACML 2.0 and also defines all the types and elements needed to truly implement the XACML extensions to SAML. New functionality that was not in the OASIS Standard is: (1) XACML policies MAY be included in an XACMLAuthzDecisionQuery that MAY be used by the PDP to evaluate the Request Context that is in the query. (2) An XACMLAdvice element is defined for inclusion in an XACMLAssertion that allows XACMLAssertions to be used as advice for any SAML or XACML Statement. Details of changes made in the updated SAML profile: [1] Incorporates all errata reported against our XACML 2.0 standard profile; [2] Defines elements that use xsi:type to pick up the extension types (XACMLAuthzDecisionStatement; XACMLAuthzDecisionQuery; XACMLPolicyStatement; XACMLPolicyQuery) [3] Defines additional extension types and elements for all the SAML elements in which our XACML extensions might be used: (XACMLAssertion and XACMLAssertionType; XACMLAdvice and XACMLAdviceType; XACMLResponse and XACMLResponseType); [4] XACMLAuthzDecisionQuery now allows XACML policies to be included in an authorization decision request, in anticipation of XACML Administration requirements. PDPs MAY use these policies in evaluating that one decision request only;the combining algorithm (i.e., how to combine the policies included and how and whether to combine them with other policies) is up to the PDP. This may need more specification..." See the ZIP file with OTD format and schemas (xacml-2.1-profile-saml2.0-schema-assertion-wd-1.xsd; xacml-2.1-profile-saml2.0-schema-protocol-wd-1.xsd); ZIP source.

• [April 07, 2006] "XACML: The New Standard for Access Control Policy." By Hal Lockhart (BEA Systems). Presented February 17, 2006 at the RSA 2006 Conference (Session Code: STA-403). 29 slides. The companion summary in XACML Policy Model and Unique Features of XACML surveys some of the unique and key features of XACML: "XACML is request centric. A request of some sort triggers the policy evaluation cycle. The policies in force are potentially applied to any information relating to that request. The fundamental issue is: should access be allowed? XACML allows other actions to be specified (Obligations), but the focus if its design is about getting that yes or no answer. Consistent with that, XACML policies operate directly on that information. XACML does not introduce any synthetic concepts to define access policies. Many access control systems invent new concepts which are then referenced by policy. For example, in many environments the concept of a Privilege is used as shorthand for one or more Actions on one or more Resources. The Java authorization model takes this one step further by using a Role as a synonym for some set of Privileges. The main advantage of the XACML approach is that the policy is 'all in one place.' All the machinery is in the Policies and Policy Sets. It is possible that if the chosen abstractions match the problem space well and the policies are not too complex, the synthetic approach might be easier to use than XACML. But XACML's goal is to be a universal language and enable the use of very complex policies. I also believe XACML is superior for policy maintenance, where the administrator may no longer remember exactly how the policies were set up or it may have been done by someone else." From the presentation, Slide 15: Novel XACML Features — (1) Large Scale Environment: Subjects, Resources, Attributes, etc. not necessarily exist or be known at Policy Creation time; Multiple Administrators w/ potentially conflicting policy results; Combining algorithms; (2) Request centric: Use any information available at access request time; Zero, one or more Subjects; No invented concepts (privilege, role, etc.); (3) Dynamically bound to request: Not limited to Resource binding; Only tell what policies apply in context of Request; Two stage evaluation..." RSA Presentation abstract: "XACML is the OASIS Standard policy language for Access Control, the only such open, vendor-neutral language. This presentation will cover its history and its technical features. It will give examples of its use, citing projects utilizing XACML and commercial products implementing it. It will also cover how XACML and its profiles can be used to achieve a variety of access control models, such as Permissions, ACLs and RBAC... Attendees will be able to determine if the XACML Standard is applicable to their access control requirements. Attendees will be able to defend their choice of an open standard for access control [and] will be able locate sources to buy or build an XACML-based solution. See the source, which was posted to the XACML TC discussion list.

• [December 01, 2005] "WS-Security Policy Profile of WS-PolicyConstraints." By Anne Anderson (Sun Microsystems). Working Draft. Version 04. December 01, 2005. 25 pages. "This document defines predicates for specifying constraints on the message security domain covered by the OASIS WS-Security Standard. These predicates are expressed using the generic policy constraint language WS-PolicyConstraints, which is based on the OASIS eXtensible Access Control Language (XACML) Standard. By expressing constraints using this generic constraint language, any policy processor for WS-PolicyConstraints can verify a message against a WS-Security policy, and can automatically find a mutually acceptable WSSecurity policy based on the individual policies of two or more parties. No plug-ins or modifications to the policy processor for WS-PolicyConstraints are required for handling this or any other domain's policy constraints. The profile defined here is not intended to replace WS-SecurityPolicy. It is a 'proof-of-concept' of the WS-PolicyConstraints approach that takes a well-known set of Assertions and demonstrates that they can be expressed using WS-PolicyConstraints. To enable an easy comparison between the two languages, this document has been organized according to the Assertions defined in WS-SecurityPolicy v1.1 because its purpose is to explore various types of Assertions and how they can be expressed using a domain-independent policy assertion language such as WS-PolicyConstraints..." [source PDF]

• [November 08, 2005] "Using XML and XACML to Support Attribute Based Delegation." By Chunxiao Ye and Zhongfu Wu (College of Computer Science, Chongqing University 400044, China). Pages 751-756 in The Fifth International Conference on Computer and Information Technology (CIT 2005). Published September 2005. "This paper proposes an Attribute-Based- Delegation-Model (ABDM) with an extended delegation condition consisting of both delegation attribute expression (DAE) and prerequisite condition. In ABDM, a delegatee must satisfy delegation condition (especially DAE) when assigned to a delegation role. With delegation condition, ABDM relieves delegator and security administrator of security management work in delegation. To implement ABDM, we use XML to describe user, permission, role, delegation constraint, prerequisite condition and user's attribute expression, and XACML to describe DAEs of permissions and roles respectively. Also, we propose an extended data-flow model based on XML and XACML to show how ABDM works... Bhatti ['XML-Based Specification for Web-Services Document Security'] proposes an XML-based RBAC language for document security in XML-based web services. In James/Joshi ['Access-Control Language for Multidomain Environments'], XML is used as an access control language for RBAC in a multidomain environment. Toktar ['RSVP Policy Control using XACML'] uses XACML to model and distribute RSVP access control policies for RSVP-aware application servers. To implement ABDM, we use XML and XACML as a UAE, CR and delegation constraints, and a DAE of permission, role and temporary delegation role definition language respectively. Additional, we also save delegation results and other access control data in XML repository... As a delegation model based on permission and user's attribute, the main feature of ABDM is that it uses user and permission attribute expression as a part of delegation condition. ABDM is a securer delegation model for it can restrict delegatees strictly. In our model, XML and XACML are used to describe UAE, DAE, delegation constraint and other access control data. We also propose a data-flow model and its operation steps to show how our ABDM model works. We believe specify and enforce more delegation constraints with XACML is an interesting topic for future study..."

• [September 2005] "Using XACML for Privacy Control in SAML-Based Identity Federations." By Wolfgang Hommel. The Munich Network Management Team, Leibniz Computing Center, Munich, Germany. Pages 160-169 in Proceedings of Communications and Multimedia Security (CMS 2005). Ninth IFIP TC-6 TC-11International Conference, Salzburg, Austria, September 19 - 21, 2005. Abstract. "With Federated Identity Management (FIM) protocols, service providers can request user attributes, such as the billing address, from the user's identity provider. Access to this information is managed using so-called Attribute Release Policies (ARPs)... In this paper, we first analyzed existing implementations of Attribute Release Policies (ARPs), which are the core privacy management tool in today's identity federation standards. We have found several shortcomings and described their consequences for real world applications and user acceptance. We then provided arguments to use XACML as base for ARPs, a well-established access control language standard, which has been successfully used in the field of distributed access control before. We presented an architecture for the integration of XACML ARPs into SAML-based identity providers, which remains fully compliant to the SAML standard. The syntax and semantics of XACML ARPs have been specified along with the policy evaluation workflow, which makes use of an out-of-the-box XACML policy decision point. Finally, we introduced our implementation, the way to integrate it into Shibboleth, a popular open source identity federation software, and outlined an algorithm which converts existing Shibboleth ARPs lossless to XACML ARPs. We are planning to integrate this ARP engine into the next major version of Shibboleth, but for use in a production environment, intuitive graphical user interfaces for the creation, testing and maintenance of these ARPs must be conceived and implemented to hide the complexity from the end users. We will also investigate the use of XACML for the so-called Attribute Acceptance Policies, which are the counterpart to ARPs on the service provider side; similar deficiencies such as yet another proprietary format can be found there presently. [cache 2006-08 from source PDF]

• [July 21, 2005] "Verification and Change-Impact Analysis of Access-Control Policies." By Kathi Fisler, Shriram Krishnamurthi, Leo A. Meyerovich, and Michael Carl Tschantz. Presented at the International Conference on Software Engineering, 2005. "Sensitive data are increasingly available on-line through the Web and other distributed protocols. This heightens the need to carefully control access to data. Control means not only preventing the leakage of data but also permitting access to necessary information. Indeed, the same datum is often treated differently depending on context. System designers create policies to express conditions on the access to data. To reduce source clutter and improve maintenance, developers increasingly use domain-specific, declarative languages to express these policies. In turn, administrators need to analyze policies relative to properties, and to understand the effect of policy changes even in the absence of properties. This paper presents Margrave, a software suite for analyzing role-based access-control policies. Margrave includes a verifier that analyzes policies written in the XACML language, translating them into a form of decision-diagram to answer queries. It also provides semantic differencing information between versions of policies. We have implemented these techniques and applied them to policies from a working software application..." See Margrave: An API for XACML Policy Verification and Change Analysis. [PDF, cache]

• [June 16, 2005] "GeoXACML, a Spatial Extension to XACML." By Dr. Andreas Matheus (University of the Federal Armed Forces Germany, Neubiberg, Germany). OGC Discussion Paper. Reference: 05-036. June 16, 2005. 18 pages. "This OGC document proposes one possible solution for the declaration and enforcement of access restrictions for object-oriented geodata, available through a Service-based Geo Data Infrastructure. It is the intension of the author to motivate the requirement for such an access control, give a problem statement, discuss an alternative approach and describe the solution, based on GeoXACML... This document describes the profiling of the OASIS standard XACML in order to support the declaration and enforcement of access rights, based on GML feature types, features and the spatial relationship between a feature and a given (restriction) geometry. This extention (called GeoXACML) uses the XACML extension points to define the required functionality. This document also gives examples for access restrictions and how to be declared in GeoXACML. Because GeoXACML is specific to the geospatial problem domain, a standardization with OASIS is not possible. Therefore, this document is posted to the OGC community in order to provide a possible recommendation, how to declare and enforce access rights for object-oriented geodata in an interoperable way..." On OGC, see "Geography Markup Language (GML)." [source PDF]

• [April 29, 2005] "How to Declare Access Control Policies for XML Structured Information Objects using OASIS' eXtensible Access Control Markup Language (XACML)." By Andreas Matheus (Technische Universität München, Munich, Germany). In Proceedings of the 38th Hawaii International Conference on System Sciences - (HICSS '05). " Web Services, as the new building blocks of today's Internet provide the power to access distributed and heterogeneous information objects, which is the base for more advanced use like in electronic commerce. But, the access to these information objects is not always unrestricted. The owner of the information objects may control access due to different reasons. This paper introduces a novel approach for declaring information object related access restrictions, based on a valid XML encoding. The paper shows how the access restrictions can be declared using XACML and XPath. Based on the specified 'fine grained' policies, multiple policies can be applicable. If these policies declare positive and negative permissions for the same subject, policy inconsistencies exist. The paper also focuses on specifying the ground of policy inconsistencies and how to solve them..."

• [February 01, 2005] "Core and Hierarchical Role Based Access Control (RBAC) Profile of XACML v2.0. OASIS Standard. February 01, 2005. Document identifier: 'access_control-xacml-2.0-rbac-profile1-spec-os'. 23 pages. Available in multiple document formats (PDF/HTML/SXW). Edited by Anne Anderson (Sun Microsystems). Produced by members of the OASIS Extensible Access Control Markup Language (XACML) TC. "This specification defines a profile for the use of XACML in expressing policies that use role based access control (RBAC). It extends the XACML Profile for RBAC Version 1.0 to include a recommended AttributeId for roles, but reduces the scope to address only 'core' and 'hierarchical' RBAC. This specification has also been updated to apply to XACML 2.0... The policies specified in this profile do not answer the question 'What set of roles does subject X have?' That question must be handled by a Role Enablement Authority, and not directly by an XACML PDP. Such an entity may make use of XACML policies, but will need additional information. See 'Section 3: Assigning and Enabling Role Attributes' for more information about Role Enablement Authorities. The policies specified in this profile assume all the roles for a given subject have already been enabled at the time an authorization decision is requested. They do not deal with an environment in which roles must be enabled dynamically based on the resource or actions a subject is attempting to perform. For this reason, the policies specified in this profile also do not deal with static or dynamic 'Separation of Duty' (on which, see Role Based Access Control — ANSI INCITS 359-2004). A future profile may address the requirements of this type of environment..." [source PDF, source ZIP with PDF/HTML/SXW]

• [January 07, 2005] "Differences between XACML versions 1.0 and 2.0." Prepared by Eleanor Joslin (Parthenon Computing Ltd). January 07, 2005. See the posting of 2005-01-07 to the OASIS 'xacml-users' list. "This document outlines the apparent differences between XACML versions 1.0 and 2.0. It is based on Committee Draft 04 of XACML 2.0, dated 6 December 2004, and on the schemas accompanying the XACML 1.0 specification." [cache]

• [November 11, 2004] "The Relationship Between XACML and P3P Privacy Policies." By Anne Anderson (Sun Microsystems). Version: 1.12. November 11, 2004 or later. "This note addresses the relationship between the OASIS eXtensible Access Control Markup Language (XACML) and the W3C Platform for Privacy Preferences (P3P) as two privacy policy languages... The expressions in the two languages should be compatible. That is, if a P3P policy says that "the only data the site collects on its home page is the data found in standard HTTP access logs", then the corresponding XACML privacy policy will allow a "write" operation to the specific file that contains the source for the site's home page where the data to be written is the content of specific fields (clientAddress, userName, localTime, bytesSentToClient, referrer, etc.) in the specific file containing the HTTP access log. The XACML policy is a concrete application of the P3P policy to actual users, resources, actions, and purposes. XACML policies express not just privacy policies, but policies for any type of access to resources. In this way, a complete set of XACML policies can be audited to ensure that privacy policies are not being circumvented via other access control policies... P3P policies and XACML policies serve complementary purposes. P3P policies express privacy policies in terms that human users can understand; they express externally published policies in a generalized, high-level form. XACML policies express the same privacy policies in terms that computer access control mechanisms can understand and enforce; they express policies in a fine-grained, internally applicable form. The two levels of policy should be consistent with each other, and together they enable an auditor to determine whether the enterprise is complying with its stated privacy policies..."

• [October 05, 2004] OASIS Extensible Access Control Markup Language TC Approves XACML 2.0 Specifications.     Members of the OASIS Extensible Access Control Markup Language (XACML) Technical Committee have approved several Version 2.0 documents as Committee Drafts. The approved CD documents are available for public review through November 4, 2004. The motivation behind XACML is to express the well-established ideas in the field of access- control policy (e.g., rules, policies, policy sets, subjects, decision requests, authorization decisions,) using an extension language of XML. According to the Core specification, "there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy." The XACML specification thus "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 should provide the opportunity for organizations to perform access and access policy audits directly across such systems." The XACML 2.0 Specification Set includes a normative subset of eleven documents, including four XML Schemas and seven prose specifications. The complete distribution for public review is a ZIP archive with sixty-some files, including non-normative formats and examples. Version 2.0 provides profiles for SAML 2.0, XML Digital Signature, Privacy Policy, Hierarchical/Multiple Resources, and Role Based Access Control (RBAC). The principal features of XACML are documented in the core Extensible Access Control Markup Language (XACML) Version 2.0 specification, supported by the Core Policy Schema and Core Context Schema. This document provides the model descriptions for data-flow, XACML context (canonical representation of a decision request and an authorization decision), and policy language (rule, policy, policy set).

• [July 19, 2004] "A Comparison of EPAL and XACML." By Anne Anderson (Sun Microsystems, Inc). Technical Report. Version 1.18. Updated July 12, 2004 or later. "Two events have recently occurred that raise questions about the relationship between two policy languages: IBM's Enterprise Privacy Authorization Language (EPAL) and the OASIS Standard eXtensible Access Control Markup Language (XACML). IBM submitted EPAL 1.2 to the W3C for consideration as a privacy policy language standard. XACML, which is already an approved standard, also supports privacy policies. Some press and analyst reports have presented EPAL as not only the best available privacy policy language, but also as the best general authorization and access control policy language, sometimes without even mentioning XACML. Questions that need to be answered include: (1) What are the differences between EPAL 1.2 and XACML? (2) Which language is better for expressing privacy policies? (3) Which language is better for expressing access control policies? (4) Should EPAL become a standard? This document compares EPAL and XACML to show where the two languages differ. The differences are used to compare the strengths and weaknesses of each language for expressing privacy policies and authorization or access control policies. Conclusions, including answers to the questions above, are presented at the end... [Conclusion] XACML is both a more comprehensive access control policy language than EPAL 1.2, and a full-featured privacy policy language. It has the important features required by both types of policies, including major features not supported by EPAL 1.2. It has been publicly reviewed and formally analyzed. In addition, it is already an approved OASIS Standard, has an excellent open source implementation (non-viral BSD license), has multiple publicly available implementations, and has a community of users and developers who are continuing to expand, improve, and apply the language. Since EPAL adds no significant functionality, and in particular no new privacy-specific functionality, to what is already supported in XACML, and since XACML contains significant additional functionality, and since XACML has already been accepted as an OASIS Standard, there is no reason to standardize EPAL. Multiple, competing "standards" that address the same problem space, particularly when they are so similar, are a detriment to the industry... The OASIS XACML Technical Committee has minuted an interest in inviting the EPAL authors to work with the XACML TC, and the TC co-chairs have issued this invitation..."

• [March 23, 2004] "Introduction to XACML." By Phil Griffin. From BEA XML and Web services technologies (articles). February 2004. ['A new markup language has been approved by OASIS which promises to standardize policy management and access decisions. Extensible Access Control Markup Language, or XACML, was approved and became an OASIS standard in February 2003. XACML defines a general policy language used to protect resources as well as an access decision language.'] "Every enterprise has a need to secure resources accessed by employees, partners, and customers. For example, browser based access to portals which aggregate resources (web pages, applications, services, etc.) are typical in today's enterprises. Clients send requests to servers for resources, but before a server can return that resource it must determine if the requester is authorized to use the resource. This is where XACML fits in. XACML provides a policy language which allows administrators to define the access control requirements for their application resources. The language and schema support include data types, functions, and combining logic which allow complex (or simple) rules to be defined. XACML also includes an access decision language used to represent the runtime request for a resource. When a policy is located which protects a resource, functions compare attributes in the request against attributes contained in the policy rules ultimately yielding a permit or deny decision. When a client makes a resource request upon a server, the entity charged with access control by enforcing authorization is called the Policy Enforcement Point. In order to enforce policy, this entity will formalize attributes describing the requester at the Policy Information Point and delegate the authorization decision to the Policy Decision Point. Applicable policies are located in a policy store and evaluated at the Policy Decision Point, which then returns the authorization decision. Using this information, the Policy Enforcement Point can deliver the appropriate response to the client... XACML is a significant step forward for standardizing a language for security policies and access decisions. Extensibility will provide most enterprises and security product vendors the ability to overcome any language shortcomings. However, XACML will not be an appropriate solution for all access decision needs and each enterprise must carefully evaluate their unique requirements..."

• [January 23, 2004] "SAML Tops Federation Projects Survey." By Dave Kearns. In Network World (January 09, 2004). Ping Identity, sponsor of the SourceID Web site, recently surveyed folks who downloaded its open-source Liberty Alliance tool kit. "When asked about the priority of federation protocols, it wasn't surprising that the Liberty Alliance protocols out-polled the WS-Federation protocol (favored by IBM and Microsoft) since the respondents were specifically those who downloaded a Liberty Alliance tool kit. But even adding together those who preferred Liberty phase II with those who preferred Liberty phase I (a total of 42% of the respondents) they were still outweighed (at 49%) by those who favored Versions 1.0, 1.1 and 2.0 of the Security Assertion Markup Language (SAML). SAML is the transport mechanism for the Liberty Alliance proposals, and one of the allowed transports for WS-Federation, but it appears that a number of projects are working directly with SAML and by-passing the 'higher' layers of the two competing standards. It might be that the projects being talked about are all early stage developments, with the SAML parts being worked on now while the developers look to see which of the two competing standards will emerge with an edge -- or, perhaps, a consolidation or merger might occur with one standard being created from the two we currently have. If you think that's a likely scenario, then it would be wise to put off any development at that upper level until the parameters of the eventual standard begin to take shape. Another of the survey questions asked downloaders what additional protocols were 'of interest' to them vis-à-vis federation. The big winner there was OASIS' Extensible Access Control Markup Language (XACML), with 49%, followed by Service Provisioning Markup Language (SPML) at 29%, and eXtensible Resource Identifier (XRI) with 14%. A scattering of other protocols took 8% of the responses. XRI could be considered a competitor to Universal Description, Discovery and Integration..." See also: "Security Assertion Markup Language (SAML)."

• [October 31, 2003] "First Experiences Using XACML for Access Control in Distributed Systems." By Markus Lorch (Virginia Tech, Dept. of Computer Science), Seth Proctor (Sun Microsystems Laboratories), Rebekah Lepro (NASA Ames Research Center, Moffett Field, CA), Dennis Kafura (Virginia Tech, Dept. of Computer Science), and Sumit Shah (Virginia Tech, Dept. of Computer Science). Presented at the ACM Workshop on XML Security (October 31, 2003, Fairfax, VA, USA). 13 pages (with 30 references). "Authorization systems today are increasingly complex. They span domains of administration, rely on many different authentication sources, and manage permissions that can be as complex as the system itself. Worse still, while there are many standards that define authentication mechanisms, the standards that address authorization are less well defined and tend to work only within homogeneous systems. This paper presents XACML, a standard access control language, as one component of a distributed and inter-operable authorization framework. Several emerging systems which incorporate XACML are discussed. These discussions illustrate how authorization can be deployed in distributed, decentralized systems. Finally, some new and future topics are presented to show where this work is heading and how it will help connect the general components of an authorization system... Early experiences using XACML in distributed systems have proven positive. The language is indeed useful for specifying arbitrarily complex policies in a wide variety of (distributed) applications and environments. While targeted at traditional access control systems, XACML also proves practical for expressing privilege management policies and defining privilege statements. The standard format works well in tying together heterogeneous systems, and already fosters development of common tools. Its open standard status, definition in XML, and availability of open source projects has already drawn support from diverse applications. XACML's ability to tie into other authorization systems makes it a natural interoperability point, even for legacy systems. Its expressive semantics and extensible nature also make it useful as an intermediary language. The ability to work with decentralized policies, and the ease with which it integrates into the systems presented in this paper point to XACML as an excellent choice for distributed authorization systems..." [cache]

• [August 12, 2003] "XACML J2SE Platform Policy Profile." By Anne H. Anderson (Sun Microsystems Laboratories, Burlington, MA, USA). Version 1.28. Updated July 21, 2003. "This document contains a proposed profile for supporting use of OASIS eXtensible Access Control Markup Language (XACML) Version 1.0 policies for applications written for the Java 2 Platform, Standard Edition (J2SE). The proposal recommends creation of a J2SE Policy Provider that accepts XACML policies as its policy input. The Policy Provider accepts standard XACML policies, but also supports new XACML extensions to deal with J2SE-specific objects and concepts. XACML is designed to be extensible, and the proposed extensions are fully in the spirit of those intended. The profile defines mappings between certain Java Class objects and standard XACML Attributes. Such mappings allow Java applications to use standard XACML policies that protect resources accessed by multiple applications, not all of which are written using the Java programming language... This would provide a way for Java applications using the standard Java Policy API to use XACML policies and [other features] that come with XACML, including dynamic policies, use of arbitrary Subject and target attributes independent of the application, distributed policies, policies shared between multiple applications, policies shared between Java and non-Java applications, role based access control, and resource labels..."

• [March 28, 2003]   XACML XML DSig Profile Supports Authentication of XACML Schema Instances.    The OASIS Extensible Access Control Markup Language (XACML) TC has published a draft XACML XML DSig Profile specifying the use of the W3C XML-Signature Syntax and Processing Standard in providing authentication and integrity protection for XACML schema instances -- policies, authorization decision requests, and authorization decision responses. The draft profile attempts to be consistent with the SAML profile wherever possible. A normative section of the draft profile specifies guidelines for the construction of XACML schema instances that are to be signed. These guidelines apply to XMLDSig digital signatures as well as to other digital signature formats. Another section describes the formats for an XMLDSig <Reference> element that references an XACML schema instance. The OASIS XACML TC has been chartered to "define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML."

• [March 14, 2003] "A Brief Introduction to XACML." A contribution from Sun Microsystems to the OASIS Extensible Access Control Markup Language TC. Last updated: March 14, 2003. Posted 2003-03-14 to the XACML TC mailing list by Anne Anderson (Sun Microsystems Laboratories, Burlington, MA, USA). Note from the contributor: "Sun Microsystems is contributing the attached document, taken from our Open Source implementation of XACML at SourceForge (http://sunxacml.sourceforge.net) to the OASIS XACML TC for possible use as the basis for an XACML Primer. This document itself might be appropriate as an interim Primer until a more extensive document can be prepared. Under OASIS IPR guidelines, the XACML TC is free to modify, extend, or otherwise prepare derivative works based on this document, so long as the derivative work contains the Sun Microsystems copyright notice." From the Introduction: "This web page provides a brief introduction to XACML. For more information about XACML, you should visit the OASIS XACML technical committee's web site. In a nutshell, XACML is a general-purpose access control policy language. This means that it provides a syntax (defined in XML) for managing access to resources... XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML). The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed, and interpret the result. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can't be answered by this service). The typical setup is that someone wants to take some action on a resource. They will make a request to whatever actually protects that resource (like a filesystem or a web server), which is called a Policy Enforcement Point (PEP). The PEP will form a request based on the requester's attributes, the resource in question, the action, and other information pertaining to the request. The PEP will then send this request to a Policy Decision Point (PDP), which will look at the request and some policy that applies to the request, and come up with an answer about whether access should be granted. That answer is returned to the PEP, which can then allow or deny access to the requester. Note that the PEP and PDP might both be contained within a single application, or might be distributed across several servers. In addition to providing request/response and policy languages, XACML also provides the other pieces of this relationship, namely finding a policy that applies to a given request and evaluating the request against that policy to come up with a yes or no answer. There are many existing proprietary and application-specific languages for doing this kind of thing but XACML has several points in its favor..."

• [March 07, 2003] "Web-Services Policy Language Use-Cases and Requirements." Edited by Tim Moses (Entrust) Contributors: Anne Anderson (Sun Microsystems) and Simon Godik (Overxeer). Produced by members of the OASIS Extensible Access Control Markup Language TC. Committee Working draft version 01. 7-March-2003. Document identifier: wd-xacml-wspl-use-cases-01.doc 19 pages. A first draft of the WSPL use-cases document, posted by Tim Moses (Entrust) to the OASIS TC mailing list. Abstract: "This working draft defines use-cases for negotiating a variety of forms of policy in the Web-services architecture. Its purpose is to identify the policy requirements of the Web-services application domain and the shortcomings of XACML when applied to that domain." From the Introduction: "XACML is potentially well suited to serve the policy needs of the Web-services application domain. This document explores the requirements for XACML when used in that domain, in order to identify XACML's shortcomings. Several aspects of policy are considered, including: cryptographic-security policy, authentication policy, authorization policy, privacy policy, reliable-messaging policy and transaction policy..." [cache .DOC, source]

• [February 25, 2003] "XACML -- A No-Nonsense Developer's Guide." By Vance McCarthy. In Enterprise Developer News (February 24, 2003). "Earlier this month, OASIS adopted XACML 1.0 as its first cut at an open standard to help developers build interoperable access controls security for XML documents and end-to-end transactions. In general, XACML (the Extensible Access Control Markup Language) describes two key areas for security -- an access control policy language and a request/response language for two-way communications. At the root of XACML is a concern with access policies -- what XACML refers to as a Policy or a PolicySet. When XACML refers to 'policy,' it specifically means Authorization (AuthN) Policy. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. A PolicySet is a container that can hold other Policies or PolicySets, as well as references to policies found in remote locations. A Policy represents a single access-control policy, expressed through a set of Rules. [Said OASIS XACML committee co-chair Hal Lockhart:] XACML defines and describes 'layering' between XML entities to clearly distinguish between security technologies that: (1) Create policy; (2) Collect the data required for policy evaluation; (3) Evaluate policy; and (4) Enforce policy. Why be so granular? One key answer is to enable interoperability for access control approaches, Lockhart said. 'While deployed systems may combine two or more of these into a single entity, the architecture maximizes flexibility. For example, a management tool from one vendor could generate policies that are evaluated by a product from another vendor,' he said. One early reaction from a web services software firm was also bullish on the opportunities for simplicity that XACML might provide. 'The XACML standard specifies how policies for information access can be communicated between systems in an XML format. Such a description can allow an application built by a developer to automatically discover the security policies in force to access the resource,' said Mukund Balasubramanian, CTO at Infravio, a provider of web services management and security software in Redwood City, California..."

• [February 18, 2003]   Sun Microsystems Releases Open Source XACML Implementation for Access Control and Security.    Sun Microsystems Laboratories has published an open source implementation of the OASIS Open Extensible Access Control Markup Language (XACML) Standard. The implementation is written in the Java programming language and is available from SourceForge. XACML, recently approved as an OASIS Open standard, is "an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language. The policy language is used to express access control policies (who can do what when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries (responses). XACML contributes to the simplification and cost reduction of developing and deploying secure web services -- or any application that requires secure access control. The Sun project provides complete support for all the mandatory features of XACML as well as a number of optional features. Specifically, there is full support for parsing both policy and request/response documents, determining applicability of policies, and evaluating requests against policies. All of the standard attribute types, functions, and combining algorithms are supported, and there are APIs for adding new functionality as needed. There are also APIs for writing new retrieval mechanisms used for finding things like policies and attributes. The project was developed in Sun Microsystems Laboratories, part of Sun Microsystems, Inc., and is part of an ongoing project on Internet Authorization in the Internet Security Research Group." The project team welcomes additional involvement from developers.

• [August 30, 2002] "OASIS XACML TC and Rights Language TC." By Hal Lockhart (Entegrity). Among the presentations given at the Forum on Security Standards for Web Services, Boston, 26 August, 2002. XACML and RLTC 'Forty Thousand Foot View': Both deal with the problem of Authorization; Both draw requirements from many of the same application domains; Both share many of the same concepts, but in some cases use different terms; Both base specification on XML Schema; Each approaches the problem differently. Types of Authorization Information: [1] Attribute Assertion (Properties of a system entity, typically a person; Relatively abstract - business context; Same attribute used in multiple resource decisions; Examples: X.509 Attribute Certificate, SAML Attribute Statement, XrML PossessProperty); [2] Authorization Policy (Specifies all the conditions required for access; Specifies the detailed resources and actions/rights; Can apply to multiple subjects, resources, times...; Examples: XACML Policy, XrML License, X.509 Policy Certificate); [3] AuthZ Decision (Expresses the result of a policy decision; Specifies a particular access that is allowed; Intended for immediate use; Example: SAML AuthZ Decision Statement). Web Services Security: [1] SAML, XACML and RLTC Spec can all convey AuthZ Info, carry in SOAP header [2] Possible use in Policy Advertisement [3] Issues: Substantial overlap between SAML/XACML & XrML - not clear what is best for what use; Intellectual Property Issues; Controversies over DRM itself; XACML and XrML are complex, will take time to understand. [source .PPT]
• [December 11, 2001] "Controlling Access to XML Documents." By Ernesto Damiani (University of Milan), Pierangela Samarati (University of Milan), Sabrina De Capitani di Vimercati (University of Brescia), and Stefano Paraboschi (Milan Polytechnic). In IEEE Internet Computing Volume 5, Number 6 (November/December 2001), pages 18-28. Special Issue on Personalization and Privacy, guest edited by John Riedl (University of Minnesota). ['Access control techniques for XML provide a simple way to protect confidential information at the same granularity level provided by XML schemas.'] See publications from the University of Milan Security Group, Dipartimento di Tecnologie dell'Informazione and the Fine-Grained XML Access Control Project.