Presently OASIS only supports core and hierarchical RBAC, but not static and dynamic separation of duty. As stated in the abstract of "Core and Hierarchical Role Based Access Control (RBAC) Profile of XACML, v2.0" OAS05a:

This specification defines a profile for the use of XACML in expressing policies that use role based access control (RBAC). It extends the XACML Profile for RBAC Version 1.0 to include a recommended AttributeId for roles, but reduces the scope to address only core and hierarchical RBAC. This specification has also been updated to apply to XACML 2.0.

Later, on page 4 in Section 1.3 Scope:

The policies specified in this profile assume all the roles for a given subject have already been enabled at the time an authorization decision is requested. They do not deal with an environment in which roles must be enabled dynamically based on the resource or actions a subject is attempting to perform. For this reason, the policies specified in this profile also do not deal with static or dynamic Separation of Duty (see ANSI-RBAC). A future profile may address the requirements of this type of environment. Minutes of the 5 February 2004 XACML TC Meeting in which this document was approved includes issues raised by NIST and the comment that XACML "does not currently support integrated administrative policies."

The OASIS Technical Committee also produced the XACML Profile for Role Based Access OAS04 and the OASIS eXtensible Access Control Markup Language (xacml) v2.0. T OAS05b.

When asked for a comment on ANSI INCITS 359-2004, the XACML committee editor responded Anne Anderson

From: Anne.Anderson@Sun.COM
To: Robin Cover <
Subject: Re: [xacml] ANSI INCITS 359-2004 etc
Date: Tue, 06 Apr 2004 07:32:18 -0400


The XACML TC had the opportunity to work with the NIST RBAC team as they
were doing their final review of what has become the ANSI RBAC standard
and as we were developing the XACML Profile for Role Based Access Control.
The XACML RBAC Profile, recently approved by the
XACML TC as a Committee Draft, uses the ANSI terminology and model, and
completely implements the functionality described in the ANSI RBAC standard.
The authors of the ANSI standard are listed in the acknowledgments for the

I believe the RBAC model described in the ANSI standard is consistent with
consensus modern understandings of RBAC.

The weakness of the ANSI RBAC standard is in its APIs: they are designed for
small, special-purpose, turnkey systems, and could not be implemented on
top of any modern operating system.The authors of the standard agree with
this, but were eager to get something minimal out and felt it would be years
before they could reach agreement on anything more substantial.The XACML 
RBAC profile does not support the ANSI RBAC APIs.

Anne Anderson

Yao, Moody, and Bacon present a model of OASIS RBAC and its support for active security YMB01.

Bacon and Moody promote RBAC using XML for open, secure, widely distributed services in BM02a, and Bacon, Moody, and Yao present a more in-depth presentation of OASIS Role-Based Access Control in BMY02.

Belokosztolszki and Eyers discuss shielding OASIS RBAC infrastructures from cyberterrorism BE03.

Dimmock, Belokosztolszki, Eyers, Bacon, and Moody compare trust management and distributed access control to OASIS and describe their Prolog-based OASIS implementation of a file storage and publication service for the Grid DBEE04. Markup Languages site.

Lorch, Proctor, Lepro, Kafura, and Shah describe some first experiences using XACML for access control in distributed Systems LPLE03.

Jat Singh's review

Last modified 18 years ago Last modified on Oct 3, 2006, 6:11:25 PM
Note: See TracWiki for help on using the wiki.