Contents
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
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).
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
- XACML TC Charter
- XACML TC Document list
- XACML TC Document Repository
- XACML TC FAQ document
- XACML TC mailing list archives
- 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
[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..."
[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 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..."
- [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.
