PPS – Permission <PolicySet>. See Section 1.4 Policies.
RBAC – Role based access control. A model for controlling access to resources where permitted
actions on resources are identified with roles rather than with individual subject identities.
RPS – Role <PolicySet>. See Section 1.4 Policies.
role – A job function within the context of an organization that has associated semantics regarding the
authority and responsibility conferred on the user assigned to the role [RBAC].
senior role – In a role hierarchy, Role A is senior to Role B if Role A inherits all the permissions
associated with Role B.
policy – A set of rules indicating which subjects are permitted to access which resources using which
actions under which conditions.
1.3 Role
In this specification, roles are expressed as XACML Subject Attributes. There is one exception: in a Role
Assignment <PolicySet> or <Policy>, the role appears as a Resource Attribute. See Section 3:
Assigning and Enabling Role Attributes for more information.
Role attributes may be expressed in either of two ways, depending on the preferences of the application
environment. In some environments there may be a small number of “role attributes”, where the name
of each such attribute is some name indicating “role”, and where the value of each such attribute
indicates the name of the role held. For example, in this first type of environment, there may be one “role
attribute” having the identifier urn:someapp:attributes:role. The possible roles are values for
this one attribute, and might be officer, manager, and employee. This way of expressing roles
works best with the XACML way of expressing policies.
Alternatively, in other application environments, there may be a number of different attribute identifiers,
each indicating a different role. For example, in this second type of environment, there might be three
attribute identifiers: urn:someapp:attributes:officer-role,
urn:someapp:attributes:manager-role, and urn:someapp:attributes:employee-role.
In this case the value of the attribute may be empty or it may contain various parameters associated with
the role. XACML policies can handle roles expressed in this way, but not as naturally as in the first way.
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. XACML identifies each such
Subject with a SubjectCategory xml attribute that indicates the type of subject being described. For
example, the human user has a SubjectCategory of &subject-category;access-subject;
(this is the default category); the application that generates the access request has a
SubjectCategory of &subject-category;codebase; and so on. In this Profile, a role
attribute may be associated with any of the categories of subjects involved in making an access request.
1.4 Policies
In this Profile, there are four types of policies.
1. Role <PolicySet> or RPS : a <PolicySet> that associates holders of a given role attribute with a
Permission <PolicySet> that contains the actual permissions associated with the given role. The
<Target>
element of a Role <P
o
licySet>
limits the applicability of the <PolicySet> to subjectsholding the given role attribute. Each Role <PolicySet> references a single corresponding
Permission <PolicySet> but does not contain any other <Policy> or <PolicySet> elements.
2. Permission <PolicySet> or PPS: a <PolicySet> that contains the actual permissions associated
with a given role. It contains <Policy> elements and <Rules> that describe the resources and
actions that subjects are permitted to access, along with any further conditions on that access, such
as time of day. A given Permission <PolicySet> may also contain references to Permission
cd-xacml-rbac-profile-01 13 February 2004
Copyright © OASIS Open 2004. All Rights Reserved. Page 4 of 21
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
