[[TOC(Internal/Rbac, Internal/Rbac/OrbitRbacLevels, Internal/Rbac/OrbitRbacDesign, Internal/Rbac/OrbitRbacDesign/ThreatAnalysis, Internal/Rbac/OrbitRbacDesign/ResourcesRoles, Internal/Rbac/OrbitRbacDesign/ImplementationResearch, Internal/Rbac/OrbitRbacDesign/AuditingTools, Internal/Rbac/OrbitRbacDesign/ConsistencyChecking, Internal/Rbac/OrbitRbacDesign/NistRbacSoftware, Internal/Rbac/OrbitRbacDesign/SolarisRbac, Internal/Rbac/OrbitRbacDesign/OasisRbac, Internal/Rbac/OrbitRbacDesign/xoRbac, Internal/Rbac/OrbitRbacDesign/DesignByWiki, Internal/Rbac/OrbitRbacDesign/OpenIssues, Internal/Rbac/OrbitRbacDesign/WorkToDo, Internal/Rbac/LdapResources, Internal/Rbac/RbacResources)]]
==== OASIS RBAC ====
Presently [[http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml 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" [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/access_control-xacml-2.0-rbac-profile1-spec-os.pdf 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 
[[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/ANSI+INCITS+359-2004.pdf ANSI-RBAC]]). A future profile may address the requirements of this type of environment.

[[http://www.oasis-open.org/archives/xacml/200402/msg00039.html 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 [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/cd-xacml-rbac-profile-01.pdf OAS04]] and the OASIS eXtensible Access Control Markup Language (xacml) v2.0. T[[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/access_control-xacml-2.0-saml-profile-spec-os.pdf OAS05b]].

When asked for a comment on ANSI INCITS 359-2004, the XACML committee editor responded [[http://lists.oasis-open.org/archives/xacml/200404/msg00036.html Anne Anderson]]
{{{
From: Anne.Anderson@Sun.COM
To: Robin Cover <robin@isogen.com
Subject: Re: [xacml] ANSI INCITS 359-2004 etc
Date: Tue, 06 Apr 2004 07:32:18 -0400

Robin,

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
XACML RBAC Profile.

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 [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p171-yao.pdf YMB01]].

Bacon and Moody promote RBAC using XML for open, secure, widely distributed services in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p59-bacon.pdf BM02a]], and Bacon, Moody, and Yao present a more in-depth presentation of OASIS Role-Based Access Control in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p492-bacon.pdf BMY02]].

Belokosztolszki and Eyers discuss shielding OASIS RBAC infrastructures from cyberterrorism [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/belokosztolszki03shielding.pdf 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 [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/sacmat04-tbac.pdf DBEE04]].


[[http://xml.coverpages.org/techSociety.html#security Markup Languages site]].

Lorch, Proctor, Lepro, Kafura, and Shah describe some first experiences using XACML for access control in distributed Systems [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p25-lorch.pdf LPLE03]].

[[Jat Singh's review http://www.srcf.ucam.org/~js573/research/index.php?option=com_content&task=view&id=64&Itemid=49]]