Comparing Authorization Management Cost for Identity-Based and
Role-Based-Access Control

######### David F. Ferraiolo, John F. Barkley and Ramaswamy Chandramouli

**National Institute of Standards and Technology**

**Gaithersburg, Maryland 20899**

######## Abstract 

> The cost of managing authorization data is one of the key elements in
> the overall cost of enterprise security management. The nature of
> authorization data is a function of access control schemes that
> enterprise information systems support. Among the several access
> control schemes, the Role Based Access Control (RBAC) has been proven
> to reduce the cost of authorization management. However there has not
> been any work in actually quantifying those savings. In this paper, we
> analyze the various variables involved in administration of access
> control using Identity Based Access Control (IBAC) and RBAC schemes
> and derive cost expressions for basic authorization management
> tasks/functions. We then compare the overall administrative costs of
> creating and maintain­ing authorization data for IBAC and RBAC and
> illustrate the potential payoffs in implementing a RBAC based scheme.

# 1.0 Introduction

The increasing use of information systems to support more and more of
business processes, and the distributed nature of these new systems has
increased the risk of unauthorized disclosure and misuse of corporate
data. To realize the full benefits of automation and to minimize the
risk of corporate data exposure, organizations need effective access
control schemes as part of their overall enterprise security strategy.
In particular, the creation and maintenance of authorization data which
forms the core component of any access control scheme, presents a great
technical and financial challenge.

> One of the promising access control schemes which has been proven to
> address the above issue is Role-Based Access Control (RBAC). However,
> since majority of the legacy systems as well many new systems only
> support the conventional identity-based access control (IBAC),
> switching to a RBAC approach will require a significant investment on
> the part of an enterprise. These costs are in terms of new security
> management software and the engineering process of redefining
> authorization information with respect to roles. Non the less, it is
> our opinion that the potential benefits RBAC offers should outweigh
> these costs. These benefits include reduced complexity of
> authorization manage­ment, the ability to enforce important access
> control policies, increased operational assur­ance, and a reduced cost
> in administering access control policies.
>
> Recently a number of papers have been published describing these
> benefits of RBAC \[3\]\[4\]\[5\]\[6\]\[7\], without any attempt at
> quantifying how role concepts relate to administrative cost. The
> purpose of this paper is to provide greater insight as to the
> quantitative adminis­trative cost benefits of RBAC over an existing
> identity-based approach. This is achieved through the development of a
> computational cost model for authorization data management (creation,
> update and deletion) that can be applied to various security
> administration scenarios. The cost model is used to calculation a
> return on investment (ROI) and to analyze the economic impact of
> switching over to the RBAC scheme.
>
> Section 2 of this paper describes some basic similarities and
> differences between identity-based (IBAC) and role-based access
> control approaches. The differences between identity-based and
> role-based access control approaches are further delineated throughout
> the remaining sections of this paper. Section 3 describes basic
> administrative functions that are fundamentally required by an
> enterprise regardless of the type of access control deployed. Section
> 4 provides a comprehensive definition of the RBAC computational model.
> This model is in terms of the relative costs associated with
> performing authorization management functions with respect to IBAC and
> RBAC mechanisms and enterprise specific architectural and
> administrative parameters. Section 5 provides an example calculation
> of expected annual savings for a typical mid-sized enterprise.

# 2.0 Identity and Role Based Access Controls

> Before any access is granted, a user identity check is made, possibly
> by calling an authentication server. If this "logon" test succeeds, a
> connection operation binds the session to a subject, i.e., creates a
> 1-to-1mapping from the user *u* to some subject *s*. Thus for the
> purpose of performing an access control calculation we can drop the
> user denotation *u* below and use the subject *s* it binds instead.
> Access means having the permission to perform an action within a
> computing environment, such as the ability read, write, append or
> delete information. The access control mechanism is used to protect
> information, or more generally speaking protect objects from
> unauthorized access. Autho­rization management is the administrative
> process of defining what subjects may have access to what objects,
> with respect to a set of predefined enterprise security policies. An
> access control mechanism restricts which subjects can perform which
> operations on which object. In general an approval of a particular
> operation to be performed on one or more objects is referred to as a
> privilege. Even though privilege and permission are often used
> interchangeably, we make a distinction between what is tabulated from
> what is calculated. We use privilege for an express access grant,
> i.e., a datum which is tabulated as part of the access control
> information, and permission for a value calculated by combining
> privileges, and subject attributes.
>
> For the purposes of this paper, restrictions can be either
> identity-based or role-based. For identity-based mechanisms, access is
> controlled on the basis of the identity of the user *u*, or more
> accurately, the identity of the subject *s* acting as a surrogate of
> *u* that is requesting to perform an operation *op* on an object *o*.
> For role-based mechanisms, access control decisions are based on the
> role *r* of a subject *s* acting on behalf of a user *u* requesting to
> perform an operation *op* on an object *o* where the user *u* is a
> known member of role *r*.

By far the most prevalent type of identity-based access control
mechanism, is an access control list (ACL) \[8\]. An access control list
is a lower level mechanism that contains the names of subjects that are
authorized to access the object to which it refers, as well as specific
permissions that are granted to each authorized subject. Thus, when a
subject wants to access an object, the system searches for an entry of
the subject in the appropriate ACL. If an entry exists, and if the
necessary operation is part of that entry, then access is permitted.
Privilege to create and modify ACLs is restricted to the owners of the
objects for which the ACLs protect. To support discretionary policies,
ownership or control typically resides with the creators of the objects.
In an attempt to support non-discretionary policies, that are typical of
most organizations, ownership is assumed by the enterprise, where
security administrators centrally control ACL entries on behalf of the
enterprise. For administrative efficiency reasons, a group is often used
as an entry on the ACL as a shorthand notation for describing a
collection of individual subjects. For purposes of access control
calculations, the subject's identity is compared to the identities
maintained in the group. If a match is found, the subject is allowed to
perform the operation cor­responding to the group entry.

From a modeling perspective, roles are equivalent to groups. A role can
represent a collection of users and a user can be a member of multiple
roles. Unfortunately, in practice not all group mechanisms allow users
to be a member of more then one group. Similarly, a single privilege can
be associated with one or more groups/roles and a single group/role with
one or more privileges. As such, by assigning a user to a group/role
implicitly provides the user with the ability to execute those
privileges that are associated with that group/role. For the purposes of
this paper we will assume a group/ACL mechanism (ACLg) to be equivalent
to that of a RBAC role. A real world mechanism ACLg, would be considered
equivalent to an RBAC role if:

## There were no practical restrictions on the number of groups that could be created;

## There were no practical restrictions on the number of users that could become a member of any group; and

## There were no practical restrictions on the number of groups to which a user can have simultaneous membership.

Although, identity based systems often include a similar group structure
to that of a role, roles and groups differ fundamentally in the way they
are used and managed. See Appendix A for a more formal delineation of
these differences. Under the RBAC model, membership within a role is
resolved independently of the object attributes. This allows for the
centralized management of user/role relationships, to include mutual
exclusivity of role membership, as well as, the centralized
establishment of subject security attributes (i.e., the user's active
role set). As such, a role-subject attribute can take on a general
meaning across multiple systems, making it simpler and cheaper to
administer user/role and role/role relationships over the semantically
equivalent group mechanism. E.g., by granting a user membership into a
role on a front-end server has the effect of granting the user privilege
to objects across back-end servers that contain corresponding role
attributes.

Under an IBAC scheme groups are defined as object security attributes.
Group membership is typically determined within the system for which the
object resides. From an authorization management perspective, each
system is treated as a stand-alone system. Their underlying access
control mechanisms are locally and individually adminis­trated with
little or no regard to the authorization data that is maintained within
other enterprise systems.

To provide further administrative efficiency, the RBAC model allows
roles to contain other roles, and as such form role hierarchies. Role
hierarchies are strict partial orderings on the set of roles. A strict
partial ordering is a relation which is asymmetric and transitive and
which is often represented by the symbol "\>". The notation " r \> r' "
means that r "inherits" r' or r "contains" r'.

Strict partial orderings can be visualized by means of a directed
acyclic graph. Given a strict partial ordering, the directed acyclic
graph corresponding to that relation can be constructed by drawing an
arrow from r to r' if and only if r directly inherits r'. Under this
scheme, the roles toward the top of the graph would represent the more
powerful roles (i.e., those roles containing a greater number of
privileges and a fewer number of users). And the roles toward the bottom
of the graph would represent the least powerful roles (i.e., those roles
containing a fewer number of privileges and a greater number of users).
By assigning a user to a role has the effect of assigning the user to
all roles that are contained by that role. And by assigning a privilege
to a role has the effect of assigning the privilege to all roles that
contain that role. Although, it is not inconceivable that a group
mechanism could provide semantically similar features, in general group
mechanisms do not support hierarchies.

By taking advantage of the multiple inheritance properties of the
directed role graph, individual users can be introduced directly into
the role graph as a UserRole. As such individual users and their unique
privileges can be included as part of the overall RBAC scheme (i.e.,
privileges specific to a particular user are assigned to the UserRole
that represents the user in the role graph). By initially assigning a
user to a given role has the effect of creating a UserRole and
establishing an inheritance relationship between the UserRole and the
role that the user was assigned. Any subsequent user-role assignments
would be in terms of role-role inheritance relationships. Because user
privilege assignments are always established in the context of the role
graph, the UserRole can be treated as any other role in the graph for
the purposes of creating and inheriting privileges. Because a UserRole
is a special type of role, always consisting of one user, a UserRole
must always be a topmost node in the role graph (it can not have
ascendants).

# 3.0 Administrative Functions

> Regardless of the type of access control implemented, an enterprise
> must perform basic authorization management functions to support
> operational requirements. These administrative functions include two
> categories of operations:

## Distribution of privileges, and 

-   Revocation of privileges

    Both distribution and revocation of privileges may involve a third
    category of operation

```{=html}
<!-- -->
```
-   Review of privileges.

Distribution of privileges refers to the administrative operations
involved in the appropriate establishment of user privileges. The
distribution of privileges is necessary in order to establish or modify
a user's functional capabilities. Typically, distribution operations
pertain to:

The initial assignment of permissions to establish functional
capabilities for new users; the reassignment of permissions to reflect a
user's change of responsibility; and the assignment of new privileges to
existing users to reflect a change in or the creation of new functions
within the enterprise. When a new employee enters on duty, privileges
must be appropriately assigned to the user. When a user's function
changes within the enterprise, the existing privileges of the user must
be reviewed and changes made accordingly. In addition, new privileges
are assigned to the user in order for the user to effectively perform
his/her new responsibil­ities. In order to establish new functions within
the enterprise, new privileges must be assigned to existing users that
are authorized to perform the new functions.

> When distributing privileges, special attention is taken to abide by
> the principle of least privilege. Least privilege is the time honored
> administrative practice of selectively assign­ing privileges to a user
> such that the user is given no more privilege than is necessary for
> the performance of his/her job function. Achieving least privilege has
> the benefit of avoiding an individual the ability to perform
> unnecessary and potentially harmful actions merely as a side effect of
> granting the ability to perform a desired function \[9\]. Privileges
> are the legal rights granted to an individual, to enable the holder to
> those rights to act in the system within the bounds of those rights.
> The question then becomes how to assign users the appropriate set of
> permissions, among the aggregate of system permissions, that
> correspond to the user's authorized functions or duties within the
> enterprise.
>
> When a user separates from the enterprise, changes jobs or
> responsibilities within the enterprise, or an existing function
> becomes obsolete an administrator must subsequently revoke appropriate
> user privileges. In the case where the user separates from the
> enterprise all of the user's privileges would need to be effectively
> revoked. One approach to this problem might be to simply delete all of
> the user's existing accounts within the enterprise. However, this
> would leave garbage in the system, that might lead to inappropriate
> and potentially damaging accesses. In the case where the employee
> changes responsibilities within the enterprise, the administra­tor must
> take great care in selectively revoking privileges. By deleting
> privileges that are necessary for the performance of the user's new
> responsibilities would inhibit the user's ability to effectively
> perform his/her job. By not deleting privileges that are no longer
> necessary in performing the user's new responsibilities would be a
> violation of the principle of least privilege, and thereby provide the
> potential for abuse.

# 4.0 RBAC Cost Model

> RBAC exhibits cost advantages over IBAC, such as that of an ideal ACLg
> mechanism described in section 2, by reducing the number of
> administrative operations that must be performed to achieve and
> maintain a common access control policy. In terms of the RBAC model,
> these cost advantages can be realized through the creation and use of
> role hierarchies, and through centrally maintained user-role and
> role-role relationships. Because an RBAC role spans multiple systems
> within an enterprise, user-role and role-role relationships can be
> created and maintained at an abstraction above, and independently of
> each enterprise system. E.g., by centrally granting a user membership
> into a role has the effect of granting the user the set of privileges
> that are associated with that role and all roles that are contained by
> that role. Because, role hierarchies reduce cost independently of the
> enterprise's back-end systems we begin specification of the RBAC cost
> model by first qualifying savings through the use of hierarchical role
> relationships.

## **4.1 Hierarchical and Non-hierarchical Role Representations**

> Job functions within an enterprise often have overlapping
> responsibilities and privileges, i.e., users belonging to different
> roles may need to perform common operations. Further­more, within many
> organizations there are a number of general operations that are
> per­formed by a large number of users. As such, it would prove
> inefficient and administratively cumbersome to specify repeatedly
> these general privileges for each role or group that gets created.
> Role hierarchies provide a means of dramatically reducing and in many
> cases eliminating the need to perform repetitive administrative
> operations.
>
> The administrative advantages of RBAC are realized when an
> organization makes use of RBAC in the following manner. Roles are
> defined and associated with privileges with respect to resources that
> are maintained within the back-end systems. Role relationships, e.g.,
> a role hierarchy, are also defined. Within a role hierarchy, if one
> role inherits another, then the inheriting role obtains the privileges
> of the inherited role by virtue of the inheritance relationship, not
> as a result of the inheriting role having a direct association with
> the privileges of the inherited role. Resource access then becomes a
> matter of associating users with roles.
>
> Lets consider how hierarchies can be used to express policy. Figure 1a
> shows a simple access control policy using hierarchies. The roles
> r~1~, r~2~, and r~3~ are assigned privileges p~1~, p~2~, and p~3~
> respectively. User u has been assigned role r~1~. As a result of the
> hierarchy, user u has been effectively authorized privileges p~1~,
> p~2~, and p~3~. This authorization is accomplished by a single
> administrative operation, associate user u with role r~1~. When u is
> replaced by another user, a total of two administrative operations
> must be performed, one to remove u from r~1~ (and by inheritance, also
> from r~2~, and r~3~) and one to assign the new user to r~1~ (and by
> inheritance to r~2~, and r~3~).
>
> The same access control policy can be accomplished without using
> hierarchies, by making three assignment operations, i.e., associate
> user u with r~1~, r~2~, and r~3~ (figure 1b). Although figure 1b
> provides the same effect of granting user u, privileges p~1~, p~2~,
> and p~3~, as that of figure 1a, figure 1b, does not provide the same
> access control policy or functional expression as that of figure 1a.
> To achieve the same policy expression would entail three additional
> permission assignments, i.e., associate p~3~ with r~2~, and r~3~, and
> associate p~2~ with r~1~ (figure 1c).

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### 

#### **4.1.1 User-Role Relationships**

> The cost model for this example can be described as follows:
>
> Let
>
> *m~u~*= the number of distinct roles inherited by any role *R*
> assigned to user *u* where *u* is not assigned to any role inherited
> by *R*
>
> More precisely:
>
> *m~u~* = the number of roles in the set: {*r*\|(*u*→ *R*) ∧ (*R* \>
> *r*) ∧ \~ (*u* → *r*)}
>
> where: "*u* → *R*" means "user *u* is assigned role *R*"
>
> The administrative cost is qualified as the number of user-role
> assignments required by the policy expression. When a hierarchical
> role expression is used as in figure 1a, the administrative cost for
> user *u*, *CH(u)*, is 1 by definition. However, when the
> non-hierarchical role representation is used as in figure 1b,
> additional role assignments for user *u* must be made for each of the
> roles which has a hierarchical relationship in figure 1a. The number
> of these additional role assignments is *m~u~*. Thus including the
> cost of the additional role assignments, the administrative cost for
> user *u*, *CNH(u)*, is:

> *CNH*(*u*) = *m~u~* + 1

> = *m*~u~ + *CH*(*u*)
>
> If *u* is assigned *k*~u~ different roles in a hierarchy, then the
> cost of the non-hierarchical role expression is:
>
> *CNH*(*u*) = *m~u~* + *k~u~*
>
> C*NH*(*u*) = *m~u~* + *CH(u)*
>
> Now, let:
>
> *n~u~* = the number of users which are assigned at least one role *r*
>
> More precisely:
>
> *n~u~* = the number of users in the set: {*u*~i~ ∃*r*, *u*~i~ → *r*}
>
> $\begin{array}{r}
> C_{\text{NH}_{u}}^{\text{total}} = \sum_{i = 1}^{n_{u}}{C\text{NH}_{u}(u_{i}}) = \sum_{i = 1}^{n_{u}}{(m_{u_{i}}} + k_{u_{i}}) \\
>  = \sum_{i = 1}^{n_{u}}m_{u_{i}} + \sum_{i = 1}^{n_{u}}k_{u_{i}} \\
>  = \sum_{i = 1}^{n_{u}}m_{u_{i}} + C_{H_{u}}^{\text{total}}
> \end{array}$Thus, with the non-hierarchical role expression, the cost
> for all users assigned at least one role is:
>
> As an example consider the role graph depicted in figure 2. Figure 2
> includes three users, u1, u2, and u3, each assigned at least one role.
> As such *n~u~* equals three. u1 is assigned to one role r2, which
> contains three roles, r5, r7, and r8. Therefore, *m~u1~* and *k~u1~*
> are three and one respectively. Because u2 is assigned two roles, r1
> and r2, *k~u2~* is two. r1 contains five roles, r3, r5, r6, r7, and
> r8. r2 contains three roles, r5, r7, and r8. Because r5, r7, and r8
> are contained by roles r1 and r2, these roles are counted only once,
> thus *m~u2~* is five. u3 is assigned to one role, r4, and r4 contains
> three role, r6, r7, and r8, and as such, *k~u3~* and *m~u3~*, are one
> and three respectivly.

> $\begin{array}{r}
> C_{H_{u}}^{\text{total}} = \sum_{i = 1}^{n_{u}}k_{u_{i}} = 4 \\
> C_{\text{NH}_{u}}^{\text{total}} = \sum_{i = 1}^{n_{u}}m_{u_{i}} + \sum_{i = 1}^{n_{u}}k_{u_{i}} = \text{15}
> \end{array}$Therefore, the total cost of the hierarchical and
> non-hierarchical role expressions of the role graph depicted in figure
> 2, are:

> Although accurate, determining cost with respect to a known role graph
> would be inappropriate in the calculation of a return on investment,
> for the deployment of RBAC. This is due to the limited knowledge an
> enterprise would have as to the details of the role graph prior to
> performing role engineering. As such, we look at a more practical
> approach.
>
> $\begin{array}{r}
> m_{u_{i_{\text{ave}}}} = \frac{\sum_{i = 1}^{n_{u}}{(m_{u_{i}})}}{n_{u}}, \\
> k_{u_{i_{\text{ave}}}} = \frac{\sum_{i = 1}^{n_{u}}{(k_{u_{i}})}}{n_{u}}
> \end{array}$$$$$Although, determining a complete role graph for an
> enterprise is difficult, estimating the average *m~ui~* and *k~ui~*
> could be achieved with minimal analysis. Because average *m~ui~* and
> *k~ui~* can be expressed as follows:
>
> $$$$$$
>
> Using the variables *m~uiave~* and *k~uiave~*, we can re-specify the
> non-hierarchical and hierarchical cost expressions by the following
> equations:
>
> $\begin{array}{r}
> C_{\text{NH}_{u}}^{\text{total}} = n_{u}m_{u_{i_{\text{ave}}}} + n_{u}k_{u_{i_{\text{ave}}}} \\
> \text{or} \\
> C_{\text{NH}_{u}}^{\text{total}} = n_{u}m_{u_{i_{\text{ave}}}} + C_{H_{u}}^{\text{total}}
> \end{array}$
>
> $\begin{array}{r}
> C_{H_{u}}^{\text{gain}} = \frac{C_{\text{NH}_{u}}^{\text{total}} - C_{H_{u}}^{\text{total}}}{C_{\text{NH}_{u}}^{\text{total}}}, \\
> C_{H_{u}}^{\text{fact}} = \frac{C_{\text{NH}_{u}}^{\text{total}}}{C_{H_{u}}^{\text{total}}} = \frac{n_{u}m_{u_{i_{\text{ave}}}}}{C_{H_{u}}^{\text{total}}} + 1
> \end{array}$Now we can practically calculate the gain in efficiency
> and the hierarchical cost factor for administering user assignments
> using a hierarchical role representation versus a non-hierarchical
> role representation for a common policy using the following two
> equations:
>
> As an example, consider the cost of administering user-role
> assignments for the policy represented in figure 2. By using the
> hierarchical representation provides a gain in administrative
> efficiency of 73% over the use of the non-hierarchical representation,
> and a hierarchical cost factor of 3.75.

#### 

#### **4.1.2 Privilege Role Relationships**

> Thus far we have consider the cost of administering user/role
> relations for hierarchical and non-hierarchical role representations.
> However, role hierarchies also afford a similar but dual efficiency as
> that of user-role relationships when administering role-privilege
> relationships.

To better understand how role hierarchies provide this efficiency
consider Figure 3. Figure 3a shows a simple access control policy using
hierarchies. The hierarchy presented in figure 3a is an equivalent
representation of the three roles or groups presented in figure 3b.
Users u1, u2, and u3 have been assigned to roles r1, r2, and r3,
respectively, for both the hierarchical and non-hierarchical
representations. Privilege p has been assigned role r~3~ within in the
role hierarchy. As a result of the hierarchy, privilege p has been
effectively authorized for users u~1~, u~2~, and u~3~. This
authorization is accomplished by a single administrative operation,
assign privilege p to role r~3~. To achieve the same access control
policy without using hierarchies can only be accomplished by making
three assignment operations, i.e., assign privilege p to r~1~, r~2~, and
r~3~.

> Because role-privilege relationships are inherited in the opposite
> direction as user-role relationships we can replace the definitions
> for *m~u~* and *k~u~* with the dual definitions with respect to
> privilege relationships.
>
> Let
>
> *m~p~*= the number of roles that are inherited by any role *R*
> assigned to privilege *p* where *p* is not assigned any role that
> inherits *R*
>
> More precisely:
>
> *m~p~* = the number of roles in the set: {*r*\|(*p*→ *R*) ∧ (*R* \<
> *r*) ∧ \~ (*p* → *r*)}
>
> where: "*p* → *R*" means "privilege *p* is assigned role *R*"
>
> If *p* is then assigned *k~p~* different roles in a hierarchy, then
> the cost of the non-hierarchical role representation is:
>
> *CNH*(*p*) = *m~p~* + *k~p~*
>
> *CNH*(p) = *m*~p~ + *CH*(*p*)
>
> Now, let
>
> *n~p~* = the number of privileges which are assigned at least one role
> *r*
>
> More precisely:
>
> *n~p~* = the number of privileges in the set: {*p~i~* ∃*r*, *p~i~* →
> *r*}
>
> Thus, for the non-hierarchical role representation, the cost for all
> privileges assigned at least one role is:
>
> $\begin{array}{r}
> C_{\text{NH}_{p}}^{\text{total}} = \sum_{j = 1}^{n_{p}}{C\text{NH}_{p}(p_{j}}) = \sum_{j = 1}^{n_{j}}{(m_{p_{j}}} + k_{p_{j}}) \\
>  = \sum_{j = 1}^{n_{p}}{(m_{p_{j}})} + \sum_{i = 1}^{n_{u}}{(k_{p_{j}}}) \\
>  = \sum_{j = 1}^{n_{p}}{(m_{p_{j}})} + C_{H_{p}}^{\text{total}}
> \end{array}$
>
> $\begin{array}{r}
> m_{p_{j_{\text{ave}}}} = \frac{\sum_{j = 1}^{n_{p}}{(m_{p_{j}})}}{n_{p}}, \\
> k_{p_{j_{\text{ave}}}} = \frac{\sum_{j = 1}^{n_{p}}{(k_{p_{j}})}}{n_{p}}
> \end{array}$But, Because
>
> We can state:
>
> $C_{\text{NHp}}^{\text{total}} = n_{p}m_{p_{j_{\text{ave}}}} + n_{p}k_{p_{j_{\text{ave}}}}$

$C_{\text{Hp}}^{\text{gain}} = \frac{C_{\text{NHp}}^{\text{total}} - C_{\text{Hp}}^{\text{total}}}{C_{\text{NH}_{p}}^{\text{total}}}$Finally,
the gain in administrative efficiency for administering privilege
assignments using a hierarchical role representation versus a
non-hierarchical role representation for a common policy is expressed
using the following equation:

$$Assuming for figure 2, that each role, *r~i~* has been assigned one
privilege *p~i~*. The gain in administrative efficiency for
administering privilege assignments for the role graph represented in
figure 2 using the hierarchical representation over the non-hierarchical
representation is 71%.

## 

## **4.2 Centralized User-Role Management**

To lay the groundwork for centralized authorization management vendors
are introducing enterprise security administration systems, single
sign-on, and directory services allowing a user subject attributes to be
shared in the network so that each subject would be described only once.
Under an IBAC scheme, a user's identity could be centrally verified and
bound to a subject, allowing the subject direct entry to back-end
servers where object access checks could be performed through the use of
the centrally verified subject identity. As such, centralized
authorization management offers IBAC greater administrative efficiency
by reducing the number of times a user would need to log-on across
multiple servers. Although, impressive from a users' point of view,
centralized management has no effect on efficiency from an authorization
management perspective. This is because user-privilege associations must
be performed either at the object level, in the case of an subject ACL
entry or at the server level in the case of group membership. On the
other hand, centralized authorization management offers RBAC great
benefits because roles and user role assignments can be maintained
centrally, independent of the object attributes that are used in the
calculation of access permission. By centrally assigning a user to a
role, grants the user privilege within multiple servers. Thus, security
administrators can focus much of their efforts on the central server as
users are added or deleted and as users change roles rather than
attempting to maintain lists of users and groups on multiple servers.

###### 4.2.1 Assigning User Privilege through Predefined Roles and Groups

Lets consider how user-privilege relationships as expressed by centrally
maintained roles are mapped onto ACL group entries that are maintained
on back-end systems (see figure 4 below). Recall that a privilege is an
approval to perform an operation on an object. From the previous section
we know that granting a user, *u*, membership into the set of *ku*
roles, assigns the user the set of privileges that are associated with
the set of *ku* roles, plus the set of privileges that are inherited by
the *ku* roles . Thus by assigning a user to *ku* roles within an RBACH
scheme would require the assignment of the user to *ku + mu* roles in
the RBACNH scheme to achieve the same policy effect. Within each
back-end system each user-privilege assignment is managed as an entry on
an ACL, where the entry includes an operation or a set of operations and
either a subject ID or a group ID. When roles are centrally maintained,
each *ku + mu* role in the role graph maps one-to-many onto multiple
back-end system groups. With respect to a particular system, a single
role maps one-to-one onto a single group and indirectly to multiple
group ACL entries. Thus to achieve the same policy effect of assigning a
user to the *ku + mu* roles in the RBACNH scheme would require the
assignment of the user to multiple instances of *ku + mu* groups. For
example, the group Accounts Receivable Clerk that corresponds to the
role Accounts Receivable Clerk may exist on multiple systems. To better
qualify the number of *ku + mu* groups instances we define the following
term:

Let:

> *n~sys/grp~* = the average number of systems containing a common
> instance of a single group.

We can now quantify the relative cost of assigning privilege to a user
via role membership in a RBACH, RBACNH and IBAC schemes.

> RBACH: *k~ui\ ave~*
>
> RBACNH: *k~ui\ ave~* + *m~ui\ ave~*
>
> IBAC: *n~sys/grp~* \* (*k~ui\ ave~* + *m~ui\ ave~*)

**4.2.2 Assigning New Privilege to Existing Users and Roles (Augmenting
a Function)**

Although users may obtain predefined privilege through membership into
existing roles and groups, not all user privileges can be expressed
through roles and groups. To establish privileges that are unique to a
user, new privileges must be created for the user in the form of new ACL
entries. Creating these user unique privileges involves the creation of
new ACL entries on the systems where the objects reside. From our ACL
definition, an ACL entry may include a subject identifier and/or group
identifier and a set of one or more operations for a protected object.
The \<object, operation\> pair is an expression of privilege, and the
subject and group identifiers associate the privilege with a user or a
set of users respectively. For IBAC scheme this is the extent of
privilege creation and assignment. In an RBAC scheme users are not
directly assigned privilege, but rather a privilege is assigned to a
role and a user is assigned to a role in the centrally maintained role
graph. For the purposes of qualitatively comparing the RBAC to IBAC
schemes, the basic action of assigning privilege to a subject or group
identifier can be thought of as an equivalent action to that of
assigning privilege to a role. For this equivalence to hold the subject
or group identifier must correspond to a specific role in the role
graph.

To consider the qualitative cost factors of privilege inheritance, each
subject or group identifier in the IBAC scheme would need to map
directly to one role in the RBACNH scheme, and by virtue of privilege
inheritance to (*m~pi~ave* + *k~pi~ave*) roles in the RBACH scheme.
Although technically accurate from a privilege inheritance perspective,
such a mapping would result in an expression of policy similar to that
depicted in figure 1c. I.e., users would be redundantly assigned
privilege. This would be unnecessary from a policy perspective and
inappropriate from a cost perspective.

This implies that reflecting user-role and role-role relationships of
RBACH within IBAC with the selective assignment of privilege to group
and subject identities is sufficient to express RBACH policies in an
IBAC environment. As such, we conclude that the assignment of a
privilege to an existing group or subject identifier is equivalent to
the assignment of a privilege to a role from a qualitative cost
perspective.

However, in order to create new privileges in an IBAC environment,
appropriate groups and user accounts must first be created if they do
not already exist. Consider the case where a new system is introduced
into the enterprise to support new payroll applications and files.
Before users can be assigned privilege to access these resources, new
groups need to be created that reflect the appropriate payroll
functions, new user accounts need to be created before assigning
privilege to subject identifiers and users need to be appropriately
assigned to the groups that are created. In an RBAC scheme, role
creation and role population is unnecessary. To understand the
qualitative cost relationship between IBAC and RBACH consider the
actions within IBAC of assigning a privilege to a role within a system
that does not contain a corresponding group within the system. To
achieve the same RBACH effect, a group that corresponds to the role
would need to be created on the system, and the users that are directly
assigned to the role would need to be assigned to the newly created
group. In addition, the users that are assigned to roles that would
inherit the newly created privilege would also need to be assigned to
the group. If any of the user accounts do not exist on the system, then
these accounts must also be created.

To quantify this cost we consider the following variables:

> *n~grp/yr-exst-fun~* = the number of groups per year that must be
> created to correspond to an enterprise function to enable the
> expression of privileges for files and applications that are included
> as part of an enterprise function.
>
> *n~usrs/grp~*~-new~ = the average number of users that are assigned to
> a new group.
>
> *n~new-acct/grp~* = the average number of new user accounts that must
> be created in order to completely populate a new group.

We can now quantify the administrative actions that are required due to
the assignment of a privilege to an existing enterprise function on a
system where a group does not exist locally that corresponds to the
function in an IBAC scheme.

> IBAC: *n~grp/yr-exst-fun~* \* (*n~usrs/grp~*~-new~ + *n~new-acct/grp~*
> )

For RBACNH and RBACH there is no incurred cost because the roles already
exist and are populated with users.

**4.2. 3 Creating a new function**

Creating a new enterprise function (i.e., Accounts Receivable) in RBAC
entails the creation of a new role (encapsulating the new function),
inserting it into the role graph, and directly assigning privileges to
the role on the back-end systems where the applications and files that
comprise the function reside. By inserting the role into the role graph
(in the RBACH scheme), the role could then become available for the
explicit assignment of user membership and would automatically inherit
user membership from the roles that are contain by the inserted role. By
considering the privilege role relationships established in section
4.1.2, we assume a role that is created for the purposes of privilege
assignment to be contained by *mp~i~ave* roles. Once inserted into the
role graph, the role would then become available across the enterprise
for privilege assignment. To qualify cost of user assignment for the
creation of a new function within RBACH and to derive qualified cost for
RBACNH and IBAC we define the average number of users that are
explicitly assigned to a role in a role graph.

> *n~usr/roleH~* = the average number of users that are directly
> assigned to an enterprise function and are not assigned to other
> enterprise functions that are included as a specialization of the
> function.

The number of users explicitly assigned to a role that represents an
enterprise function in RBACH can be expressed simply as:

> RBACH: *n~usr/roleH~*

To achieve the same policy effect of RBACH, in RBACNH would require the
creation of a new role, with the explicit assignment of users that would
be equal to the set of users assigned (explicitly and through
inheritance) to a corresponding role in RBACH. The number of users
explicitly assigned to a role that represents an enterprise function in
RBACNH can be expressed as:

> RBACNH: *n~usr/roleH~* \* *m~pi\ ave~*

To create a new function in the IBAC scheme would entail creating a
group on each system where the files and applications that comprise the
new function reside. Users would need to be assigned to the groups in a
manner that would correspond to the users that were assigned to a role
in RBACNH. If any of the users that were to be assigned to the group do
not have an account on the system where the group resides, then accounts
would need to be created for those users.

We can now qualify the annual cost of creating new enterprise functions
in the IBAC scheme.

> IBAC: *n~usr/roleH~* \* *m~pi\ ave~* \* *n~sys/grp~* + *n~sys/grp~* \*
> *n~new-acct/grp~*

To create a new enterprise function in RBAC would require creating a new
role, inserting the role into the role graph, and assigning new members
to the role.

> Although, privileges are created on the back-end systems, once role
> privilege relationships are created, privileges associated with users
> and roles can be centrally specified. This is because each centrally
> maintained role, to include UserRoles is mapped to privileges that are
> maintained on the back-end systems.

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## **4.3 Quantifying Cost**

Now that we have qualified the administrative relationships of using
RBAC hierarchies and centrally administering user-role relationships we
can begin to quantify the advantage of RBAC over IBAC in terms of the
administrative functions that were described back in section 3.0.
Regardless of the type of access control in use an organization will
incur cost through the distribution, revocation and review of user
privileges. Within this section we will compare the relative cost of
performing these administrative functions using an IBAC approach and an
RBAC approach that deploys role hierarchies and a centralized user-role
assignment approach. Recall that an RBAC role, *r* and an IBAC group
mechanism, *ACLg*, are considered equivalent under the properties
described in section 2. We use this equivalency to determine enterprises
ROI for the deployment of an RBAC scheme over an IBAC scheme. To
calculate ROI we define cost equations for each administrative function,
with respect to the IBAC and RBAC schemes. To define these equations we
define additional parameters to represent administrative labor cost,
time requirements to perform administrative tasks, and access control
architectural characteristics.

#### **4.3.1 Administratation cost** 

We first consider the cost per hour for a security administrator.

> Let:
>
> *a~cost~*= The average cost for a security administrator per year.
>
> The cost for *a~cost\ ~*includes the cost for benefits such as health,
> life, and retirement.
>
> Let:
>
> *d* = the number of working days per year.
>
> The number of working day should take into consideration holidays,
> vacation days, and sick days.
>
> Let:
>
> *h* = the number of hours an administrator performs actual
> administrative tasks.
>
> The number of hours, *h*, should take into consideration, time spent
> performing other essential activities related to performing
> administrative tasks, such as attending meetings and reviewing
> documentation and reports.
>
> Taking into consideration the cost parameters described above, we can
> define the net cost to perform actual administrative functions per
> hour.
>
> *a~net~* = *a~cost~ / d \* h*

#### **4.3.2 Assigning existing privileges to new users**

Next we quantify the cost to assign privileges to new users, for IBAC
and RBAC. The quantification uses general relationships defined in
section 4.1.1 as well as cost parameters that are derived from an
enterprises existing IBAC approach at assigning privileges to new users.
This method relies on a m~ui\ ave~ as estimated through analysis.
m~ui\ ave~ as estimated takes into consideration efficiencies pertaining
to the layering of user/role inheritance relationships that are
difficult to visualize and implemented within the existing enterprise
group structures.

> Let:
>
> *n~newu~*= the number of new users that are assigned privileges within
> the system, each year.
>
> *t~full-func~* = the average time in minutes for an administrator to
> create appropriate ACL user entries and group memberships for the
> establishment of a user's full functional capabilities.
>
> We now define the cost in an IBAC scheme for the assignment of
> privileges to new users, *C~set-upibac~*

> *C~set-upibac~* = *a~net~* \* *n~newu~* \* *t~full-func~* / 60

We now define the cost of assigning privileges to new users for RBAC.
For RBAC and IBAC we assume that the annualized cost to perform
administrative functions, *a~net~* and the annual number of new users,
*n~newu~* to be the same under each scheme. Thus, to understand the
relative costs for *C~set-upibac~* and *C~set-uprbac~*, we must describe
the relationship between the time to establish user privilege in an IBAC
and RBAC scheme. The time to assign privileges in IBAC is directly
related to the required administrative tasks of assigning users to
groups and ACL entries for all objects in all systems that the user will
require access. These tasks can be mapped to the non-hierarchical role
space that is then mapped to the hierarchical role space using the
relationships identified in section 4.1. We first define component
variables related to *t~full-func~*:

> Let:
>
> *n~sys/usr-new~* = the average number of systems in which a new user
> will posses privileges
>
> *n~acl/u-new/sys~* = the average number of new user acl entries per
> user per system.
>
> *t~acl-ent~* = the time to create an ACL entry, to include the time to
> specify the operation(s) that the user will be permitted to perform on
> the object.
>
> *n~grps/user~* = the average number of groups per user.
>
> *n~sys/grp~* = the average number of systems per group.
>
> *t~u-role/grp~* = the time to assign a user to a role or group.
>
> *t~usr-acct~* = the time to create a user's account.
>
> *t~full-func~* can now be redefined in terms of the time to perform
> its subtasks:
>
> *t~full-func~* = *n~sys/grp~* \* *n~grps/user~* \* *t~u-role/grp~* +
> *n~sys/usr-new~* (*n~acl/u-new/sys~* \* *t~acl-ent~* + *t~usr-acct~*)

Note that each *t~full-func~* equation contains three components \-- the
time spent assigning users to groups, the time spent creating user
identity ACL entries, and the time spent creating user accounts.

In the IBAC scheme, administrators would need to be expended
*t~full-func~* minutes for *n~newu~* new users, for a total time of:

> *T~full-funcIBAC~* = *n~newu~* \* (*n~sys/grp~* \* *n~grps/user~* \*
> *t~u-role/grp~* + *n~sys/usr-new~* (*n~acl/u-new/sys~* \*
> *t~acl-ent~* + *t~usr-acct~*))

In the non-hierarchical role scheme, each new user is assigned to
k~ui\ ave~ + m~ui\ ave~ roles within a single system rather then
directly to groups or ACL entries on a system by system basis. As such,
the total annual time required to assign new users system privileges in
a non-hierarchical RBAC scheme, *T~full-funcNH~* is:

> *T~full-funcNH~* = *n~newu~* \* (*n~grps/user~* \* *t~u-role/grp~* +
> *n~sys/usr-new~* \* *n~acl/u-new/sys~* \* *t~acl-ent~* +
> *t~usr-acct~*)

With respect to RBACH, each new user is assigned k~ui\ ave~ roles in a
single system to establish back-end system privileges. Using the mapping
relationships defined section 4.2.1 we derive *k~ui\ ave~* in terms
*m~ui\ ave~* and *n~grps/user~* and redefine time spent assigning users
to groups in IBAC in terms of *k~ui\ ave~* and *m~ui\ ave~*:

> *k~ui\ ave~* + *m~ui\ ave~* = *n~grps/user~*
>
> *k~ui\ ave~* = *n~grps/user~ - m~ui\ ave~*
>
> The total annual time required to assign new user's system privileges
> in a hierarchical RBAC scheme, *T~full-funcH~* is:
>
> *T~full-funcH~ = n~newu~ \** (*k~ui\ ave~ \* t~u-role/grp~ +
> n~sys/usr-new~ \* n~acl/u-new/sys~ \* t~acl-ent~ + t~usr-acct~*)

We can now quantify the relative cost of assigning privilege to a user
via role membership in a RBACH, RBACNH and IBAC schemes:

> *C~set-upibac~ = a~net~ \* n~newu~ \* T~full-funcibac~* / 60
>
> *C~set-uprbac-h~* = *a~net~* \* *n~newu~* \* *T~full-funcH\ ~*/ 60
>
> *C~set-uprbac-nh~* = *a~net~* \* *n~newu~* \* *T~full-funcNH\ ~* / 60

#### 

#### **4.3.3 Change of user responsibility**

> We next determine the annual cost associated with users changing
> functions, *C~ch-funibac~*.
>
> Let:
>
> *n~chngu~* = the number of users that are expected to undergo a change
> of responsibility each year.
>
> To determine the cost associated with a change of user responsibility
> we must identify several cost factors. First we need to determine
> average time required review and modify all privileges associated with
> a user's existing responsibilities. Second, we need to determine the
> average time required establishing new permissions to completely
> achieve the user's new responsibility.
>
> Let:
>
> *t~revp~* = the time spent to identify and review all ACL entries for
> which a user's identity is either included as an entry or is
> associated with a group that is included as an ACL entry, plus the
> time to verify or delete the user's identity as appropriate.
>
> *t~full-funcrem~* = the average time in minutes spent by an
> administrator to identify and establish appropriate ACL user entries
> and group memberships for the remainder of the user's new enterprise
> responsibility given the functionality that was established during
> *t~revp~*.
>
> By, using the hourly administrative cost, *a~net~*, we define the
> annual cost associated with the change of user responsibility for IBAC
> scheme:

> *C~ch-funibac~* = (*t~revp~* + *t~full-funcrem~*) \* *n~chngu~* \*
> *a~net~* / 60

> Too define the annual cost associated with the change of user
> responsibility RBACNH and RBACH we assume that the environmental
> parameters *n~chngu~* and *a~net~* remain the same under all three
> schemes and define *t~revp~* and *t~full-funcrem~* relative to the
> three schemes. Taking a similar approach to that of defining relative
> cost for the assignment of existing privileges to new users, we
> examine *t~revp~* and *t~full-funcrem~* in terms of the subtasks
> involved in reviewing privilege and distributing new user privilege
> for users changing functions.

> Let:

> *t~rev-acl-ent~* = the average time to identify each ACL entry within
> a system for which a user's identity is explicitly included, plus the
> time to verify or delete that user's identity as appropriate.

> *t~rev-u-role/grp~* =the average time to identify each group/role
> within a system that is assigned to a user, plus the time to verify or
> delete that user's identity as appropriate.

> *t~revp~* can now be re-defined in terms of its subtasks:

> *t~revp~*= *t~rev-acl-ent~* \* *n~acl/u/sys~* \* *n~sys/usr~* +
> *t~rev-u-role/grp~* \* *n~sys/grp~*\* *n~grps/usr~*

Now let:

> *P~fract~* = the fraction of the total number of UID ACL entries and
> group memberships (i.e., *n~acl/u/sys~* + *n~grp/u/sys~*) that are
> deleted due to a change of user responsibility.

*t~full-funcrem~* can now be re-defined in terms of its subtasks:

> *t~full-funcrem~* = *p~fract~* \* (*n~sys/grp~* \* *n~grps/user~* \*
> *t~u-role/grp~* + *n~sys/usr-new~* (*n~acl/usr/sys~* \* *t~acl-ent~* +
> *t~usr-acct~*))

> The annualized time required too administer the change of user
> responsibilities across all systems is the time to review all user
> privileges plus the time to assign new privileges. It should be noted
> that on average the number of privileges that are deleted from a
> user's full functionality as a result in a changing of user
> responsibility is the same as the number of privileges that are added
> to achieve a user's full functionality.

> *T~ch-funibac~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *n~sys/grp~*\* *n~grps/usr~* +
> *p~fract~* \* (*n~sys/grp~* \* *n~grps/user~* \* *t~u-role/grp~* +
> *n~sys/usr~* (*n~acl/usr/sys~* \* *t~acl-ent~* + *t~usr-acct~*)))

> The annualized time required too administer the change *n~chngu~*
> users responsibilities across all systems for RNACNH is
> *T~ch-funNH~*,:

> *T~ch-funNH~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *n~grps/usr~* + *p~fract~* \*
> (*n~grps/user~* \* *t~u-role/grp~* + *n~sys/usr~* \* *n~acl/usr/sys~*
> \* *t~acl-ent~* + *t~usr-acct~*))

> The annualized time required too administer the change *n~chngu~*
> users responsibilities across all systems for RNACH is *T~ch-funH~*,:
>
> *T~ch-funH~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *k~ui\ ave\ ~*+ *p~fract~* \*
> (*k~ui\ ave\ ~*\* *t~u-role/grp~* + *n~sys/usr~* \* *n~acl/usr/sys~*
> \* *t~acl-ent~* + *t~usr-acct~*))
>
> By, using the hourly administrative cost, *a~net~*, we can define the
> annual cost associated with the change of user responsibility for the
> non-hierarchical and hierarchical RBAC schemes:

> *C~ch-funNH~* = *a~net~* \* *T~ch-funNH~* / 60

> *C~ch-funH~* = *a~net~* \* *T~ch-funH~* / 60

#### **4.3.4 Establishment of new privileges to existing users and groups**

> The third administrative function related to the distribution
> privileges, is the establishment of new enterprise privileges to
> existing users. For an IBAC scheme the administrative task of creating
> new privileges involves the creation of new ACL entries on the systems
> where the objects and applications reside. From our ACL definition, an
> ACL entry may include a subject identifier and/or group identifier and
> a set of one or more operations for a protected object. The \<object,
> operation\> pair is an expression of privilege, and the subject and
> group identifiers associate the privilege with a user or a set of
> users respectively. In an RBAC scheme users are not directly assigned
> privilege, but rather a privilege is assigned to a role or a group
> corresponding to role and a user is assigned to a role in the role
> graph. As such each user identifier is mapped to a corresponding
> UserRole and each group identifier is mapped to a role. As an
> expression of privilege, each group or subjectID within each system is
> mapped to one role in the non-hierarchical RBAC scheme, and each role
> in the non-hierarchical RBAC scheme is mapped to (*m~piave~* +
> *k~piave~*) roles in the hierarchical RBAC scheme. As such, RBAC
> hierarchies provides administrative efficiency by reducing the overall
> number of entries that would otherwise be necessary to be
> administratively created, without the use of RBAC hierarchies.
>
> The assignment of a privilege to an existing group or user identifier
> under IBAC is equivalent to the assignment of a privilege to a role
> from a qualitative cost perspective. However, in order to create new
> privileges in an IBAC environment, appropriate groups and user
> accounts must first be created if they do not already exist.
>
> By using the net hourly administrative cost, *a~net~*, the qualitative
> cost defined in section 4.2.2 and time components we define the
> annualized cost of assigning new privileges to existing enterprise
> functions for IBAC, *C~create-privibac~*:
>
> *C~create-privibac~* = *a~net~ \* n~grp/yr-exst-fun\ ~*(
> *n~usrs/grp-new\ ~*\* *t~u-role/grp~ + n~new-acct/grp\ ~*\*
> *t~usr-acct~* ) /60

#### **4.3.5 Revocation of Privilege**

We next determine the annual cost associated with the revocation of
privileges for the users that separate from the enterprise, *C~u-sep~*.

By, using *t~revp~* to represent the time too review a users existing
privileges, *n~servave~* to represent the average number of system for
which a user posses privileges, and *a~net~* to represent the hourly
cost to perform administrative functions, we can define *C~u-sepibac~*
as:

*C~u-sepibac~* = *t~revp~* \* *n~u-sep~* \* *n~sysave~* \* *a~net~* / 60

*t~revp~* can be re-defined in terms of its subtasks:

*t~revp~*= *t~rev-acl-ent~* \* *n~acl/u/sys~* + *t~rev-u-role/grp~* \*
*n~grp/u/sys~*

In the non-hierarchical RBAC scheme, each user, *u~i~*, is assigned to
k~ui\ ave~ + m~ui\ ave~ roles within a single system rather then
directly to groups or ACL entries on a system by system basis.

The total annualized time required too review *n~u-sep~* users
privileges in a non-hierarchical scheme, *T~revpNH~* , can be defined
as:

*T~revpNH~*= *n~u-sep~*\* *t~rev-u-role/grp~* \* (k~ui\ ave~ +
m~ui\ ave~)

In the hierarchical RBAC scheme, each user, *u~i~*, is assigned to
k~ui\ ave~ roles within a single system rather then to k~ui\ ave~ +
m~ui\ ave~ roles in a non-hierarchical RBAC scheme. Thus the total
annualized time to review *n~u-sep~* users privileges in a hierarchical
scheme *T~revpH~* can be defined as:

> *T~revpH~* = *n~u-sep~*\* *t~rev-u-role/grp~* \* k~ui~
>
> By, using the hourly administrative cost, *a~net~*, we can define the
> annual cost associated with the change of user responsibility for the
> non-hierarchical and hierarchical RBAC schemes:
>
> *C~u-sepNH~* = *n~u-sep~*\* *a~net~* \* *t~rev-u-role/grp~* \*
> (k~ui\ ave~ + m~ui\ ave~)
>
> *C~u-sepH~* = *n~u-sep~*\* *a~net~* \* *t~rev-u-role/grp~* \*
> k~ui\ ave~
>
> **4.3.6 Removing or modifying obsolete privileges**

As organizational functions and policy evolve over time, existing
privileges must be modified and deleted. This administrative task
involves identifying the objects and operations that are associated with
the obsolete or modified functions and either remove or modify them
within their systems. In particular administrators must either delete
existing ACL instances or modify the operations associated with ACL
entries. In the case of deleting the entire ACL, RBAC offers no
administrative advantage, because the implementation of an RBAC model
has no effect on the number of system objects that must be maintained.
However, because RBAC reduces the overall number of ACL entries, RBAC
reduces the complexity of modifying ACL modes of operation.

> **4.3.7 Lose of user productivity**

When users are newly hired or are introduced to the system for the first
time, the organization realizes a temporary lose of productivity. This
is due to a user's inability to perform computer-related functions while
system privileges are being established for the user. The process of
establishing user privileges often involves the execution of a series of
organizational and administrative procedures. This procedure may include
the identification of organizational functions and privileges to be
performed by the user on the part of management, a review of the
collection of functions and privileges by organizational or corporate
security officials, and the administrative process of actually
establishing system privileges. Lose of user productivity for newly
hired users is expressed as the product of the average hourly cost of a
newly hired user, and the time to perform the process of establishing a
user's system privileges, divided by the percentage of time that those
user's typically perform non-computer related tasks.

Let:

> *C~new-hire~* = the average hourly cost for a new user.
>
> *t~priv-est\ ~*= the average time to perform the procedural and
> administrative process of establishing a newly hired user's system
> privileges.
>
> *t~non-compu~* = the percentage of time that a newly hired user would
> be expected to perform non-computer related activities even if system
> access was available.
>
> We can now define the costs to the enterprise due to the lose of newly
> hired user productivity, *C~l-pibac~* by the following equation:
>
> *C~l-pibac~* = *n~newu~* \* *C~new-hire~* \* *t~priv-est\ ~* /
> *t~non-compu~*

Assuming the time to perform the procedural and administrative process
of establishing a newly hired user's system privileges for RBAC and IBAC
are related the administrative time of establishing a new user's
privileges, we look to the equations of section 4.3.2 to establish a
relative comparison for RBAC and IBAC.

> *C~l-pNH~* = *C~l-pibac~* \* *T~full-funcNH~* / *T~full-funcIBAC~*
>
> *C~l-pH~* = *C~l-pibac~* \* *T~full-funcH~* / *T~full-funcIBAC~*

# 4.3.8 Creating a new function

To qualify the time involved in creating a new enterprise function
within the IBAC scheme we will need to define an additional cost
variable.

> *n~new-fun/yr~* = The average number of new functions created each
> year.

By, using *t~new-func~* to represent the time too create a new
enterprise function, we define annual cost of creating new enterprise
functions *C~new-func~* as:

> *C~new-func~* = *a~net~* \* *n~new-fun/yr~* \* *t~new-func~*

*t~new-funcibac~* can be redefined in terms of its subtasks for IBAC:

> *t~new-funcibac~* = *t~u-role/grp~* \* *n~usrs/grp~* \* *n~sys/grp~* +
> *n~sys/grp~* \* *n~new-acct/grp~* \* *t~usr-acct~*

By applying the following mapping equation defined in section 4.2.3 we
defined the time to create a new enterprise function for RBACNH in terms
of *n~usrs/grp~*.

> *n~usrs/grp~* *= n~usr/roleH~* \* *m~ui\ ave~*
>
> *t~new-funcNH~* = *t~u-role/grp~* \* *n~usrs/grp~*

By applying the following mapping equation defined in section 4.2.3 we
defined the time to create a new enterprise function for RBACH in terms
of *n~usrs/grp~ / m~pi\ ave~*.

> *n~usr/roleH~* *= n~usrs/grp~ / m~pi\ ave~*
>
> *t~new-funcH~* = *t~u-role/grp~* \* *n~usrs/grp~ / m~pi\ ave~*

####### 

# 5.0 Example Enterprise

> ACME international is a large corporation that is experiencing
> moderate growth. ACME has 90,000 users, to include 72,000 employees,
> and 18,000 suppliers, consultants and other partners. In the coming
> year ACME projects the need to increase the overall number of system
> users by 3.5%. In addition ACME expects to loose 6% of its current
> user base due to attrition and re-structuring. To meet its operational
> goal, ACME will need to add 8,550 new users of which 5,400 will be
> added due to attrition and re-structuring. In addition due to
> re-structuring, re-training, and shifting operational needs, ACME will
> need to transfer 5,500 users between job functions, delete an
> estimated 125 obsolete functions and create an estimated 150 new
> functions.
>
> After examining its roles and functional makeup of its 28 departments
> ACME has estimated that a resulting enterprise wide role graph would
> have the following characteristics:

-   k~ui\ ave~ is 1.5

```{=html}
<!-- -->
```
-   m~ui\ ave~ is 5.5

```{=html}
<!-- -->
```
-   m~pi\ ave~ is 4.0

> **5.1 Administrator net cost**
>
> Assume the annual cost for an administrator including overhead is
> \$150,000, the number of working days per year is 234 days, and the
> average number of hours per day that an administrator actually
> performs administrative functions is 6 hour.
>
> *a~net~* = \$107 per hour
>
> **5.2 Assigning privileges to new users**
>
> By assuming the average number of servers for which a users has
> privileges is 7.5, and an average time of 78 minutes for the
> establishment of a users full functionality, the annual cost for
> setting up new privileges is:
>
> *C~set-upibac~* = *a~net~* \* *n~newu~* \* *t~full-func~* / 60

> *C~set-upibac~* = \$107 per hour \* 8,550 users \* 78 min / 60 min =
> \$1,189,305

> *t~full-func~* is redefined in terms of the time to perform its
> subtasks:
>
> *t~full-func~* = *n~sys/grp~* \* *n~grps/user-new~* \*
> *t~u-role/grp~* + *n~sys/usr-new~* (*n~acl/u-new/sys~* \*
> *t~acl-ent~* + *t~usr-acct~*)
>
> *t~usr-acct~* = 2.0 min.
>
> *n~sys/usr-new~* *=* 4.5
>
> *n~sys/grp~* = 3
>
> *n~acl/u-new/sys~ =* 3
>
> *t~acl-ent~ =* 2.0 min.
>
> *n~grps/usr-new~ =* 7
>
> *t~u-role/grp~ =* 2.0 min.
>
> *t~full-func~* = 42 + 27 + 9 = 78 min.
>
> In the IBAC scheme, administrators would need to be expended
> *t~full-func~* minutes for *n~newu~* new users, for a total time of:

> *T~full-funcIBAC~* = *n~newu~* \* *t~full-func~*

> = 666,900 min.

> *C~set-upibac~* = *a~net~* \* *T~full-funcIBAC~* / 60
>
> = \$1,189,305

> *T~full-funcNH~* = *n~newu~* \* (*n~grps/user-new~* \*
> *t~u-role/grp~* + *n~sys/usr-new~* \* *n~acl/u-new/sys~* \*
> *t~acl-ent~* + *t~usr-acct~*)

> = *n~newu~* \* (14 + 27 + 2)

> = 367,650 min.

> *C~set-upNH~* = *a~net~* \* *T~full-funcNH~* / 60
>
> = \$655,643
>
> *T~full-funcH~* = *n~newu~ \** (*k~ui\ ave~ \* t~u-role/grp~ +
> n~sys/usr-new~ \* n~acl/u-new/sys~ \* t~acl-ent~ + t~usr-acct~*)
>
> = *n~newu~ \** (3 + 27 + 2)
>
> = 273,600 min.
>
> *C~set-upH~* = *a~net~* \* *T~full-funcNH~* / 60
>
> = \$ 487,920
>
> ROI (*C~set-up~*) = *C~set-upibac~* - *C~set-upH~* = \$ 701,385

Graph 1 illustrates the relative cost for this example enterprise for
administering the assignment of existing privileges to new users with
respect to *a~net~* \* *t~full-func~* for IBAC and RBAC schemes.

> ![](media/image1.wmf)
>
> For graph 1 components *a~net~*, *t~full-func~* of the cost equation
> *C~set-up\ ~*= *a~net~* \* *n~newu~* \* *t~full-func~* / 60 are
> treated as constants per the values assumed in this example. As values
> for *n~newu~* increase the ROI for the deployment of RBAC becomes more
> attractive. Note that *n~newu~* may pertain to an annualized value or
> a value that increasing over time.
>
> **5.3 Changing user responsibility**
>
> In our example we assume 5,500 users change responsibility per year.

> The annualized time required too administer the change of user
> responsibilities across all systems is the time to review all user
> privileges plus the time to assign new privileges. It should be noted
> that on average the number of privileges that are deleted from a
> user's full functionality as a result in a changing of user
> responsibility is the same as the number of privileges that are added
> to achieve a user's full functionality.

> The annual cost for the enterprise to administer changes of
> responsibility is:
>
> *C~ch-funibac~* = *a~net~* \* *n~chngu~* \* (*t~revp~* +
> *t~full-funcrem~*) / 60

> *t~revp~* is defined in terms of its subtasks:

> *t~revp~*= *t~rev-acl-ent~* \* *n~acl/u/sys~* \* *n~sys/usr~* +
> *t~rev-u-role/grp~* \* *n~sys/grp~*\* *n~grps/usr~*

> Assuming:

> *t~rev-acl-ent~* = 1.5 min.

> *t~rev-u-role/grp~* = 1.5 min.

> *n~acl/u/sys~* = 4.0

> *n~sys/usr~* = 5.5

> *n~grps/usr~* = 9

*t~full-funcrem~* is defined in terms of its subtasks:

> *t~full-funcrem~* = *p~fract~* \* (*n~sys/grp~* \* *n~grps/user-new~*
> \* *t~u-role/grp~* + *n~sys/usr-new~* (*n~acl/usr-new/sys~* \*
> *t~acl-ent~* + *t~usr-acct~*))

Assuming:

> *P~fract~* = .50
>
> *T~ch-funibac~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *n~sys/grp~*\* *n~grps/usr~* +
> *p~fract~* \* (*n~sys/grp~* \* *n~grps/user~* \* *t~u-role/grp~* +
> *n~sys/usr~* (*n~acl/usr/sys~* \* *t~acl-ent~* + *t~usr-acct~*)))
>
> = *n~chngu~* \* ((33 + 40.5) + *p~fract~* \* (42 + 27 + 9))
>
> = 618,750 min. = 10,313 hrs.
>
> *C~ch-funibac~* = \$ 1,103,491

> The annualized time required too administer the change *n~chngu~*
> users responsibilities across all systems for RNACNH is
> *T~ch-funNH~*,::

> *T~ch-funNH~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *n~grps/usr~* ) + *p~fract~* \*
> (*n~grps/user~* \* *t~u-role/grp~* + *n~sys/usr~* \* *n~acl/usr/sys~*
> \* *t~acl-ent~* + *t~usr-acct~*))

> = *n~chngu~* \* ((33 + 13.5) + *p~fract~* \* (14 + 27 + 2))

> = 6,233 hrs.

> *C~ch-funNH~* = \$ 666,931

> The annualized time required too administer the change *n~chngu~*
> users responsibilities across all systems for RNACH is *T~ch-funH~*,:

> *T~ch-funH~* = *n~chngu~* \* (*t~rev-acl-ent~* \* *n~acl/u/sys~* \*
> *n~sys/usr~* + *t~rev-u-role/grp~* \* *k~ui\ ave\ ~*+ *p~fract~* \*
> (*k~ui\ ave\ ~*\* *t~u-role/grp~* + *n~sys/usr~* \* *n~acl/usr/sys~*
> \* *t~acl-ent~* + *t~usr-acct~*))

> = *n~chngu~* \* ((33 + 2.25) + *p~fract~* \* (3 + 27 + 2))

> = 4,698 hrs.

> *C~ch-funH~* = \$ 502,686

> ROI (*C~ch-fun~*) = *C~ch-funibac~* - *C~ch-funH~* = \$ 600,805

Graph 3 illustrates the relative cost for this example enterprise for
the creation of new functions with respect to *a~net~* \*
*t~new-func\ ~*for IBAC and RBAC schemes.

> ![](media/image2.wmf)

> For graph 2 components *a~net~*, *t~full-func~* of the cost equation
> *C~set-up\ ~*= *a~net~* \* *n~newu~* \* *t~full-func~* / 60 are
> treated as constants per the values assumed in this example. As values
> for *n~newu~* increase the ROI for the deployment of RBAC becomes more
> attractive. Note that *n~newu~* may pertain to an annualized value or
> a value that increasing over time.

#### 

#### **5.4 Establishment of new privileges to existing users and groups**

> By using the net hourly administrative cost, *a~net~*, the specified
> in section 5.1 we define the annualized cost of assigning new
> privileges to existing enterprise functions for IBAC,
> *C~create-privibac~*:
>
> *C~create-privibac~* = *a~net~ \* n~grp/yr-exst-fun\ ~*(
> *n~usrs/grp\ ~*\* *t~u-role/grp~ + n~new-acct/new-grp\ ~*\*
> *t~usr-acct~* ) /60
>
> *n~grp/yr-exst-fun\ ~* = 1,200
>
> *n~new-acct/new-grp~* = 12
>
> *n~usrs/grp~* = 45
>
> *C~create-privibac~* = \$107 per hour \* 1,200 (45 \* 2 min. + 12 \*
> 2) / 60
>
> = \$243,960

#### **5.5 Creating a new function**

To qualify the time involved in creating a new enterprise function
within the IBAC scheme we will need to define an additional cost
variable.

> *n~new-fun/yr~* = The average number of new functions created each
> year.

By, using *t~new-func~* to represent the time too create a new
enterprise function, we define annual cost of creating new enterprise
functions *C~new-func~* as:

> *C~new-func~* = *a~net~* \* *n~new-fun/yr~* \* *t~new-func~*
>
> *n~new-fun/yr~* *=* 150

*t~new-funcibac~* can be redefined in terms of its subtasks for IBAC:

> *t~new-funcibac~* = *t~u-role/grp~* \* *n~usrs/grp~* \* *n~sys/grp~* +
> *n~sys/grp~* \* *n~new-acct/new-grp~* \* *t~usr-acct~*
>
> > *n~new-acct/new-grp~* = 12
>
> > *n~usrs/grp~* = 45
>
> *C~new-funcibac~* = *a~net~* \* *n~new-fun/yr~* \* (2 \* 45 \* 3 + 3
> \* 12 \* 2) / 60
>
> = \$91,485
>
> *t~new-funcNH~* = *t~u-role/grp~* \* *n~usrs/grp~*
>
> *C~new-funcNH~* = *a~net~* \* *n~new-fun/yr~* \* 2 \* 45 / 60
>
> = \$24,075
>
> *t~new-funcH~* = *t~u-role/grp~* \* *n~usrs/grp~ / m~pi\ ave~*
>
> *C~new-funcH~* = *a~net~* \* *n~new-fun/yr~* \* 2 \* 45 / 4 / 60
>
> = \$6,019
>
> ROI (*C~new-func~*) = *C~new-funcibac~* - *C~new-funcH~* = \$ 85,466
>
> Graph 4 illustrates the relative cost for this example enterprise for
> administrative of creating new functions. the assignment of existing
> privileges to new users with respect to *a~net~* \* *t~full-func~* for
> IBAC and RBAC schemes.

For graph 4 the components *a~net~*, *t~new-func~* of the cost equation
*C~new-func~* are treated as constants per the values assumed in this
example. As values for *n~new-fun~* increase the ROI for the deployment
of RBAC becomes more attractive. Note that *n~new-fun~* may pertain to
an annualized value or a value that increasing over time.

> ![](media/image3.wmf)
>
> **5.6 Lose of user productivity**
>
> We determine the cost to ACME international due to the lose of newly
> hired user productivity, *C~l-pibac~* by using the equation derived in
> section 4.3.7:
>
> *C~l-pibac~* = *n~newu~* \* *C~new-hire~* \* *t~priv-est\ ~* /
> *t~non-compu~*

We first consider the cost per hour for a newly hired user.

> Let:
>
> *u~cost\ ~*= The average cost for a newly hired user per year.
>
> = \$150,000
>
> The cost for *u~cost\ ~*includes the cost for benefits such as health,
> life, and retirement.
>
> Let:
>
> *d* = the number of working days per year.
>
> = 234 days
>
> The number of working day should take into consideration holidays,
> vacation days, and sick days.
>
> *C~new-hire~* = *u~cost~* / *d*
>
> = \$150,000 per year / 234 days = \$641 per working day
>
> Let:
>
> *t~non-compu~* = the typical percentage of time a new user would
> productively perform non-computer related activities during the period
> *t~priv-est~*.
>
> *t~non-compu~* = 50%
>
> *t~non-compu~* should take into consideration, time spent performing
> other essential activities related to, or in preparation of the users
> assigned tasks, such as attending meetings and filling out forms.
>
> t~priv-est~ = 5 work days
>
> *t~non-compu~* = 50 %
>
> *C~l-pibac~* = 8,550 new users \* \$641 per day \* 5 days \* .50
>
> = \$ 13,701,375

Assuming that the time to perform the procedural process of establishing
newly hired user's privileges for RBAC is linearly related to the time
to perform the procedural process of establishing new user's privileges
under IBAC, we look to the equations of section 4.3.2 to establish a
cost comparison.

> *C~l-pNH~* = *C~l-pibac~* \* *t~full-funcNH~* / *t~full-funcIBAC~*
>
> = \$ 13,701,375 \* 43 min. / 78 min.
>
> = \$ 7,553,322
>
> *C~l-pH~* = *C~l-pibac~* \* *T~full-funcH~* / *T~full-funcIBAC~*
>
> = \$ 13,701,375 \* 32 min. / 78 min
>
> = \$ 5,621,077
>
> ROI (*C~l-p~*) = *C~l-pibac~* - *C~l-pH~* = \$ 8,080,298
>
> Graph 5 illustrates the relative lose of user productivity due to the
> users inability to access computer resources during the establishment
> of user privileges. Louse is calculated in respect to *C~l-pibac~*,
> *C~l-pNH~*, and *C~l-pH~*. where all components are treated as
> constants per this example, with the exception of *n~newu~* which
> varies from 1000 to 5000 in increments of 1000.
>
> Note that values for *n~newu~* may pertain to an annualized value or a
> value that increasing over time.
>
> ![](media/image4.wmf)

**References**

1.  J. Barkley, "Comparing Simple Role Based Access Control Models and
    Access Control Lists, In Proceedings of the Second ACM Workshop on
    Role Based Access Control, November 1997.

2.  David F. Ferraiolo, Dennis M. Gilbert, Nickilyn Lynch, "An
    Examination of Federal and Commercial Access Control Policy Needs,"
    *Proceedings of the 16th NIST-NSA National Computer Security
    Conference*, Baltimore, MD, 20-23 September 1993.

3.  R. Sandu, E.J. Coyne, H.L. Feinstein, and C.E. Youman, "Role Based
    Access Control Models," IEEE Computer, 29(2), February 1996.

4.  M. Nyanchama and S.L. Osborn. Access rights administration in
    role-based security systems. Proceedings of the IFIP WG11.3 working
    conference on database security, 1994.

5.  J. Hoffman. Implementing RBAC on type enforced systems. In
    proceedings, 13^th^ Annual Computer security applications
    conference. IEEE Computer Society Press, 1997.

6.  David F. Ferraiolo and Richard Kuhn, "Role-Based Access Control,"
    *Proceedings of the 15th NIST-NSA National Computer Security
    Conference*, Baltimore, MD, 13-16 October 1992.

7.  David F. Ferraiolo, Janet A. Cugini, D. Richard Kuhn, "Role-Based
    Access Control: Features and Motivations," Proceedings 11th Annual
    Computer Security Applications Conference, New Orleans, LA, December
    1995.

8.  National Computer Security Center, *A Guide to Understanding
    Discretionary Access Control in Trusted Systems*, NCSC-TG-003,
    September 1987.

9.  Virgil Gligor, J. Huskamp, S. Welke, C. Linn, and W. T. Mayfield,
    *Traditional Capability-Based Systems: An Analysis of Their Ability
    to Meet the Trusted Computer Security Evaluation Criteria,* IDA
    Paper P-1935, October 1986.

    > **Appendix A**

> Role-Based and Identity-Based Access Control Models

> The following types are defined for RBAC and IBAC

-   type *user* of individual users

-   type *subject* of subject identifiers

-   type *role* of role identifiers

-   type *operation* of executable program

-   type *object* = InformationContainer

-   type *permission* = 2^(*operation*\ \ *object*)^

> The following mapping functions are defined for RBAC and IBAC:

-   RM(*r:role*)→2*^user^*, the role members mapping, which gives the
    > set of users authorized for the role, *r*.

-   RP(r:role)→2^permissions^, the role permissions mapping, which gives
    > the set of permissions authorized for role r.

-   PO*p*(*p:permission*)→*operation*, the permission to operation
    > mapping, which gives the operation associated with permission,
    > *p*.

-   PO*b*(*p:permission*)→*object*, the permission to object mapping,
    > which gives the object associated with permission, *p*.

-   SU(*s:subject*)→*user*, the subject to user mapping, which gives the
    > user associated with subject *s*.

> The following property is defined for RBAC:

-   Role Membership Inheritance:

> > (∀*i,j: role*)(∀*u: user*) *i* \> *j* ∧ *u* ∈ RM\[*i*\] ⇒ *u* ∈
> > RM\[*j*\]
>
> The following axiom determines if a subject can access an object:

-   access: subject  operation  object →boolean

```{=html}
<!-- -->
```
-   access(*s,op,o*) =

> > 1: if subject *s* can access object *o* using operation *p*
>
> > 0: otherwise
>
> Object access authorization for IBAC:
>
> (∀*s:subject*)(∀*o:object*)(∀*op:operation*)access(*s,op,o*)
>
> ⇒
> (∃*r:role*)(∃*p:permission*)SU(*s*)∈RM(*r*)∧p∈RP(*r*)∧op∈POp(*p*)∧o∈POb(*p*)
>
> With the following mapping function, object access is defined for
> RBAC:

-   AR(*s:subject*)→2*^role^*, the active role mapping, which gives the
    > set of roles in which subject, *s*, is active.

> (∀s:subject)(∀o:object)(∀op:operation)access(s,op,o)
>
> ⇒
> (∃*r:role*)(∃*p:permission*)*r*∈AR(*s*)∧p∈RP(*r*)∧op∈OP(*p*)∧*o*∈PO(*p*)