Proposal for XACML RBAC Profile

[Anne Anderson <Anne.Anderson@Sun.com>]

Dear RBACers,

Attached is a draft proposal for how XACML can address the
requirements for Role Based Access Control expressed in "Role
Based Access Control", proposed ANSI Standard, BSR INCITS 359,
4/4/2003, available from
http://csrc.nist.gov/rbac/rbac-std-ncits.pdf

This has not yet been reviewed by the XACML TC, but I hope it
will help make our discussions more productive by providing a
concrete proposal and concrete examples.  It is very much a
draft, however.

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Title: XACML RBAC Profile

XACML RBAC Profile

Author: Anne Anderson Version: 1.2, updated 03/04/17 (yy/mm/dd)

Contents

1. Introduction
2. Proposed XACML Profile for RBAC
3. Example
   1. Permission PolicySet for Officer Role
   2. Permission PolicySet for Manager Role
   3. Role PolicySet for Officer Role
   4. Role PolicySet for Manager Role
4. Core RBAC
5. Hierarchical Roles
6. Static Separation of Duty
7. Dynamic Separation of Duty
8. References

Introduction

This document contains a draft proposal for using the OASIS eXtensible Access Control Markup Language Version 1.0 (XACML) [1] to meet the requirements for Role Based Access Control (RBAC) as specified in [1]. The proposal describes a profile for the use of XACML to meet these requirements that requires no changes to standard XACML.

The proposal is followed by an example, then by a discussion of how the proposal satisfies each general requirement in Core RBAC, Hierarchical RBAC, Static Separation of Duty, and Dynamic Separation of Duty.

This proposal assumes the reader is somewhat familiar with XACML. A brief overview sufficient to understand these examples is available in [3].

Proposed XACML Profile for RBAC

In this Profile, a Role is defined as a specific XACML Attribute. An XACML Attribute has an identifier and a value of a particular data type. Any XACML PDP can evaluate policies using arbitrary Attribute identifiers.

XACML defines about 20 standard data types (string, integer, x500Name, etc.), along with standard functions for comparing and manipulating these data types. Any compliant XACML PDP can evaluate policies using any values of any of the XACML standard data types. XACML can be extended to use new data types and their corresponding functions without affecting the structure of the language.

An XACML Attribute may pertain to a Subject, a Resource, an Action, or to the Environment in which the access request is being made. In this Profile, a Role is defined as a Subject Attribute. XACML supports multiple subjects per access request, indicating various entities that may be involved in making the request. For example, there is usually a human user who initiates the request, at least indirectly. There are usually one or more applications or code bases that generate the actual low-level request on behalf of the User. There is some computing device on which the application or code base is executing, and this device may have an identity such an IP address. In this profile, a Role Attribute may be assigned to any of the types of subjects involved in making an access request.

In this Profile, there are two types of policies, each expressed as an XACML <PolicySet>.

• Role PolicySets
  • These are applicable only to holders of a given Role.
  • They reference the Permission PolicySet that specifies the permissions to be granted to holders of this Role.

• Permission PolicySets
  • These are never used as base policies, but only by reference from Role PolicySets.
  • These are applicable to any Subject
  • They specify a set of Permissions to be granted to holders of a given Role or to holders of any Role that is senior to the given Role.

Permission PolicySets need to be stored in the policy repository in such a way that they can never be used as the initial policy for an XACML Policy Decision Point (PDP). This is because A Permission PolicySet by itself needs to be applicable to any user (Subject) in order to allow Hierarchical RBAC. It is the Role PolicySet that controls which Permission PolicySets will be applied to holders of a particular role.

The Permission PolicySets that do not reference other Permission PolicySets could be XACML <Policy> elements rather than <PolicySet>. Requiring them to be <PolicySet> elements allows roles that were initially non-hierarchical to later include other permissions without requiring any change to the definitions of roles that reference them.

The two types of policies allow support for Hierarchical RBAC, where a more senior role can acquire the permissions of a more junior role. A simpler Profile supporting only the Core RBAC requirements is almost trivial to create with XACML. Designing the Profile to support both Core RBAC and for Hierarchical RBAC, however, seems preferable to having two separate profiles.

XACML does not handle the assignment of role attributes to users, so this Profile assumes that the presence in the XACML Request Context of a role attribute for a given user (Subject) is a valid assignment.

Example

Assume there are two roles Manager and Officer. In this example, these are expressed as two separate values for a single XACML Attribute called "Role". A Manager has permission to Submit Purchase Order. An Officer has permission to Sign Purchase Order, plus any permissions granted to the more junior Manager role.

According to the proposal, there will be two Permission PolicySets:

• One for the permissions associated with the Officer role.

  These are Sign Purchase Order plus the permissions associated with the Manager role.

• One for the permissions associated with the Manager role.

  This is the one permission Submit Purchase Order.

There will also be two Role PolicySets:

• One for holders of the Officer role.

  This references the permissions in the Officer Permission PolicySet.

• One for holders of the Manager role.

  This references the permissions in the Manager Permission PolicySet.

In the following examples, a few liberties have been taken with the XACML syntax in order to make the examples more readable: DataType attributes are omitted, PolicySetIds and PolicyIds have been expressed as strings rather than as URNs, and the URNs for standard FunctionIds, AttributeIds, and Combining Algorithms are shortened. Anyone familiar with XACML should be able to convert these examples to fully compliant XACML policies easily.

Here are the two Permission PolicySets:

Permission PolicySet for Officer Role

<PolicySet PolicySetId="Permission PolicySet for Officer Role"
           CombiningAlgorithm="permit-overrides">
  <Target>
    <Subjects>
      <AnySubject/>
    </Subject>
    <Resources>
      <AnyResource/>
    </Resources>
    <Actions>
      <AnyAction/>
    </Actions>
  <Target>
  <Policy PolicyId="Permissions specifically for the Officer role"
           CombiningAlgorithm="permit-overrides">
    <Target>
      <Subjects>
        <AnySubject/>
      </Subject>
      <Resources>
        <AnyResource/>
      </Resources>
      <Actions>
        <AnyAction/>
      </Actions>
    </Target>
    <Rule RuleId="Permission to Sign Purchase Order"
        Effect="Permit">
      <Target>
        <Subjects>
          <AnySubject/>
        </Subjects>
        <Resources>
          <Resource>
            <ResourceMatch MatchId="string-match">
              <AttributeValue>Purchase Order</AttributeValue>
              <ResourceAttributeDesignator AttributeId="resource-id"/>
            </ResourceMatch>
          </Resource>
        </Resources>
        <Actions>
          <Action>
            <ActionMatch MatchId="string-match">
              <AttributeValue>Sign</AttributeValue>
              <ActionAttributeDesignator AttributeId="action-id"/>
            </ActionMatch>
          </Action>
        </Actions>
      </Target>
    </Rule>
  </Policy>
  <PolicySetIdReference>Permission PolicySet for Manager Role</PolicySetIdReference>
</PolicySet>

Permission PolicySet for Manager Role

<PolicySet PolicySetId="Permission PolicySet for Manager Role"
           CombiningAlgorithm="permit-overrides">
  <Target>
    <Subjects>
      <AnySubject/>
    </Subject>
    <Resources>
      <AnyResource/>
    </Resources>
    <Actions>
      <AnyAction/>
    </Actions>
  <Target>
  <Policy PolicyId="Permissions specifically for Manager role"
           CombiningAlgorithm="permit-overrides">
    <Target>
      <Subjects>
        <AnySubject/>
      </Subject>
      <Resources>
        <AnyResource/>
      </Resources>
      <Actions>
        <AnyAction/>
      </Actions>
    </Target>
    <Rule RuleId="Permission to Submit Purchase Order"
        Effect="Permit">
      <Target>
        <Subjects>
          <AnySubject/>
        </Subjects>
        <Resources>
          <Resource>
            <ResourceMatch MatchId="string-match">
              <AttributeValue>Purchase Order</AttributeValue>
              <ResourceAttributeDesignator AttributeId="resource-id"/>
            </ResourceMatch>
          </Resource>
        </Resources>
        <Actions>
          <Action>
            <ActionMatch MatchId="string-match">
              <AttributeValue>Submit</AttributeValue>
              <ActionAttributeDesignator AttributeId="action-id"/>
            </ActionMatch>
          </Action>
        </Actions>
      </Target>
    </Rule>
  </Policy>
  <!-- PolicySetIdReferences can be added here if the Manager role later
       obtains permissions associated with any other role -->
</PolicySet>

Here are the two Role PolicySets:

Role PolicySet for Officer Role

<PolicySet PolicySetId="Role PolicySet for Officer Role"
           CombiningAlgorithm="permit-overrides">
  <Target>
    <Subjects>
      <Subject>
        <SubjectMatch MatchId="string-match">
           <AttributeValue>Officer</AttributeValue>
           <SubjectAttributeDesignator AttributeId="Role"/>
        </SubjectMatch>
      </Subject>
    </Subjects>
    <Resources>
      <AnyResource/>
    </Resources>
    <Actions>
      <AnyAction/>
    </Actions>
  </Target>
  <PolicySetIdReference>Permission PolicySet for Officer Role</PolicySetIdReference>
</PolicySet>

Role PolicySet for Manager Role

<PolicySet PolicySetId="Role PolicySet for Manager Role"
           CombiningAlgorithm="permit-overrides">
  <Target>
    <Subjects>
      <Subject>
        <SubjectMatch MatchId="string-match">
           <AttributeValue>Manager</AttributeValue>
           <SubjectAttributeDesignator AttributeId="Role"/>
        </SubjectMatch>
      </Subject>
    </Subjects>
    <Resources>
      <AnyResource/>
    </Resources>
    <Actions>
      <AnyAction/>
    </Actions>
  </Target>
  <PolicySetIdReference>Permission PolicySet for Manager Role</PolicySetIdReference>
</PolicySet>

Core RBAC

The following sections address the ways in which the proposed Profile satisfies various basic requirements of Core RBAC, as defined in [1].

Multiple Users per Role

XACML imposes no restrictions on the number of users to which a particular XACML Attribute is assigned. XACML Policies defined in terms of possession of a particular Attribute will apply to any requesting user for which that Attribute is in the XACML Request Context.

In the above example, two users Alice and Bob, could both possess a Role Attribute with a value of Manager. They would both receive the Permissions associated in the policies with the Manager Role.

Multiple Roles per User

XACML imposes no restrictions on the number of roles assigned to a particular user. If a particular user has multiple different Role Attributes, then the user will receive the Permissions defined by the XACML Policies applicable to that collection of Roles.

XACML policies may be written to impose arbitrary restrictions on combinations of Attributes. For example, an XACML Policy can be written such that a user receives the union of all the Permissions associated with the user's multiple Roles. As another example, an XACML Policy can be written such that a user must possess two or more specific Roles in order to gain certain Permissions. XACML supports arbitrary Boolean combinations of predicates on Attributes, along with a rich set of functions for comparing and manipulating values of Attributes.

Multiple Permissions per Role

XACML imposes no restrictions on the number of permissions associated with a particular Attribute. The example shows how the Role "Officer" is associated with two different permissions, one to submit a Purchase Order and another to sign a Purchase Order.

Multiple Roles per Permission

XACML imposes no restrictions on the number of Attributes that are associated with a particular permission. The example shows how the Roles "Officer" and "Manager" are associated with the permission to submit a Purchase Order.

Hierarchical Roles

XACML imposes no restrictions on how the permissions associated with roles are organized into hierarchies. XACML supports components that may be composed in various ways: Rules, Policies, and Policy Sets. These components are composed according to combining algorithms. XACML defines several useful combining algorithms that are supported by any compliant XACML PDP. XACML can be extended to support other combining algorithms without changing the structure of the language.

The example illustrates how the Profile supports General Hierarchical RBAC.

Limited Hierarchical RBAC is also supported, as the XACML policies can be written to impose arbitrary restrictions on the ways permissions are granted. These restrictions may be applied in two ways. Using the <Condition> element in an XACML <Rule>, a particular set of Permissions can be restricted to apply only under certain arbitrary conditions. Using combining algorithms, arbitrary restrictions can be imposed on the way various rules, policies, and policy sets are composed.

Static Separation of Duty

XACML policies can be written to require arbitrary combinations of role Attributes. The possible combinations include requirements that certain Attributes NOT be present. For example, the Permission PolicySet for Role A can include a <Condition> element specifying that the Attribute for Role B must not be present. These restrictions apply to the role hierarchies as defined in the Profile and as illustrated in the example.

Dynamic Separation of Duty

Dynamic Separation of Duty in [1] is specified in terms of relations that define a constraint (role set, n) where n is a natural number >= 2, with the property that no user session may activate n or more roles from the role set.

Dynamic Separation of Duty imposes restrictions on the activation of Role Attributes. In XACML terms, this is a policy to be applied to the entity that makes particular Attributes accessible in an XACML Request Context during a given user session, rather than to an access request from user for which certain roles have been activated.

The following XACML Policy example implements such restrictions. It expects the Role Activation Entity to submit the set of Roles already activated for the user during this session along with the proposed additional Role as values for Subject Attributes with AttributeId="Role". This example policy imposes the following two Role Set constraints:

• ({ A, B, C, D }, 2)
• ({ D, E, F }, 1)

Note that the standard XACML function n-of treats its first argument as the value for n. It returns true if at least n of the arguments is true. The desired relation is then expressed in terms of not n-of roles, where n is one greater than the maximum number of roles from the set allowed to be activated.

<Policy PolicyId="Role Activation Restrictions">
  <Target>
    <Subjects>
      <AnySubject/>
    </Subjects>
    <Resources>
      <Resource>
        <ResourceMatch MatchId="string-match">
          <AttributeValue>Role</AttributeValue>
          <ResourceAttributeDesignator AttributeId="resource-id"/>
        </ResourceMatch>
      </Resource>
    </Resources>
    <Actions>
      <Action>
        <ActionMatch MatchId="string-match">
          <AttributeValue>Activate</AttributeValue>
          <ActionAttributeDesignator AttributeId="action-id"/>
        </ActionMatch>
    </Actions>
  </Target>
  <Condition FunctionId="and">
    <Apply FunctionId="not">
      <Apply FunctionId="n-of">
        <AttributeValue>3</AttributeValue>
        <Apply FunctionId="string-is-in">
          <AttributeValue>A</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
        <Apply FunctionId="string-is-in">
          <AttributeValue>B</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
        <Apply FunctionId="string-is-in">
          <AttributeValue>C</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
        <Apply FunctionId="string-is-in">
          <AttributeValue>D</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
      </Apply>
    </Apply>
    <Apply FunctionId="not">
      <Apply FunctionId="n-of">
        <AttributeValue>2</AttributeValue>
        <Apply FunctionId="string-is-in">
          <AttributeValue>D</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
        <Apply FunctionId="string-is-in">
          <AttributeValue>E</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
        <Apply FunctionId="string-is-in">
          <AttributeValue>F</AttributeValue>
          <SubjectAttributeDesignator AttributeId="Role"/>
        </Apply>
      </Apply>
    </Apply>
  </Condition>
</Policy>

References

[1] Role Based Access Control, proposed ANSI Standard, BSR INCITS 359, 4/4/2003. Available from http://csrc.nist.gov/rbac/rbac-std-ncits.pdf.

[2] OASIS eXtensible Access Control Markup Language (XACML) Version 1.0, OASIS Standard, 18 February 2003. Available from http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/1642/oasis-%23%23%23%23-xacml-1.0.pdf.

[3] A Brief Introduction to XACML, by Seth Proctor, 7 February 2003. Available in the XACML Programmers Guide located at http://sunxacml.sourceforge.net/guide.html. This is part of Sun's XACML Implementation , an Open Source BSD License implementation of XACML.

---