[[TOC(Internal/Rbac, Internal/Rbac/OrbitRbacLevels, Internal/Rbac/OrbitRbacDesign, Internal/Rbac/OrbitRbacDesign/ThreatAnalysis, Internal/Rbac/OrbitRbacDesign/AuditingTools, Internal/Rbac/OrbitRbacDesign/ConsistencyChecking, Internal/Rbac/OrbitRbacDesign/NistRbacSoftware, Internal/Rbac/OrbitRbacDesign/SolarisRbac, Internal/Rbac/OrbitRbacDesign/OasisRbac, Internal/Rbac/OrbitRbacDesign/DesignByWiki, Internal/Rbac/OrbitRbacDesign/OpenIssues, 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 sepraration 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.

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 iin [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p59-bacon.pdf BM02a]], and Bacon, Moody, and Yao present a more in-depth preentation 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 implementaiton of a file storage and publication service for tlhe 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 cistributed 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]]