THE ADMINISTRATOR OBJECT
PATTERN FOR ROLE-BASED ACCESS
CONTROL
S. R. KODITUWAKKU
Department of Statistics and Computer Science University of Peradeniya, Sri Lanka
Abstract
The Object-Oriented paradigm approaches the software development by representing real world entities into classes of software objects. Object oriented design patterns facilitate small scale and large scale design reuse. This paper presents an object oriented design pattern, Administrator Object, to address the User-Role assignment problem in Role Based Access Control (RBAC). Two alternative solutions are proposed. The pattern is presented according to the Gang of Four template.
1. Introduction
Access control is one of the core issues in system security, and several access control models, such as discretionary access control (DAC), mandatory access control (MAC) [1] and role based access control [2, 3, 4] have been proposed. Role-based access control (RBAC) is based on the application area’s organizational characteristics such as structure of data models and security policies. RBAC is a family of reference models [4] in which privileges are associated with roles and roles are associated with users. Some variations of RBAC [2, 3] include the capabilities of establishing relationships between privileges and roles, and between users and roles.
Role-based access control policies govern access to information on the basis of activities of users. First roles are identified within the system and then the privileges to access information objects are specified for roles. User acting in a role is allowed to execute only operations authorized to the role. Some RBAC implementations allow one user to act in multiple roles at the same time while others restrict the user to one role at a time. In a RBAC environment, a user is a person working with the system, a role is a collection of job functions (job title) that a user or set of users can perform within the context of an organization. A subject represents an active user process and each subject is a mapping of a user to one or possibly many roles. A unique user identifier determines the user associated with the subject. The application environment defines the association between roles and privileges.
The set of objects covered by the RBAC system includes all of the objects accessible by RBAC operations. An operation represents a particular unit of control that can be referenced by an individual role that is subject to constraints within the RBAC system. An operation can be used to capture security relevant details or constraints that can not be determined by a simple mode of access. These details can be in the method or in the granularity of access. The type of operation and the objects that RBAC manages are dependent on the type of the system in which it is implemented.
Administrative policies determine who is authorized to modify the allowed accesses. Role-based policies benefit from a logical independence in specifying user authorizations by breaking this task into two parts, user-role assignment and role-privilege assignment.
Name, Context, Problem, Solution, Consequences, Related Patterns and Known Uses components. Since two alternative solutions to the problem are proposed, two sets of Solutions, Consequences, Related Patterns and Known Uses are presented.
2. The Administrator Object Pattern Name:Administrator Object
Context
In RBAC environment, user-role assignment and role-privileges assignment are the major administrative tasks. Each user has a unique subject that describes the user’s permitted roles and user must activate roles associated with his subject to access information. This pattern creates subjects for users and delegates administrative responsibilities.
Problem
The question is: how can you manage user-role assignments and role-privileges assignments?
Forces
A single user may play multiple roles but he may be restricted to play only one role at any given time.
Roles may have overlapping access rights due to the overlapping responsibilities of job titles. In such a situation, one role (senior role) may have privileges to access all pieces of information authorized for one or more other roles (junior roles) but inverse is not true. A user playing a senior role must be allowed to play all associated junior roles. However, when the user is playing a particular junior role, he may or may not be allowed to play senior role at the same time.
Sometimes some of the junior role’s privileges can be private to that role. For example, in software development domain, senior roles may not be allowed to see programmer’s incomplete codes.
A group of users can play the same role but some roles can only be taken by a limited number of users at any given time. For instant, there should be only one manager in a branch office of a bank.
One or more administrators can centrally handle users and roles but this is infeasible or inefficient for more complex applications such as distributed applications.
Solution 1
Create a distinct set of roles (administrator roles) with different privileges to manage users and roles. Create a separate role (Central administrator) to manage those administrator roles. Each administrator is given options to handle user-role assignment based on their administrative privileges. Design the administrator actions as objects by using the Command pattern [6]. The solution structure is depicted in Figure 1.
Participants
CentralAdministrator defines an interface to create, delete and modify ConcreteAdministrators.
AbstractAdministrator defines an interface for user-role assignment.
ConcreateAdministrators extend and implement the AbstractAdministrator interface based on authorized administrative privileges.
AdminCommand declares an interface for performing administrative actions.
AssignRole, RevokeRole and ModifyRole define bindings between Subject and administrative actions. Implements execute() to invoke the corresponding operation(s) on Subject.
Subject is alist of roles (role names and their status) that a particular user is permitted.
Administrators create subjects for users by invoking Subject’s interface.
Collaborations
The CentralAdministrator handles the person-role assignment and role-privilege assignment for administrator roles.
Figure 1 – Solution structure of the pattern
Consequences
Administrator roles are designed with only operations permitted to them. Consequently, administrators are restricted to perform only permitted operations.
The CentralAdministrator can assign administrator roles and privileges by creating ConcreteAdministrator roles.
Role assignment and removal are the major operations performed by ConcreteAdministrators. In complex applications, administrators may be restricted to assign roles but not to remove or assign and remove roles to and from a particular set of users. Since each ConcreteAdministrator is given options to perform only permitted operations, this pattern prevents misuse of administrative privileges.
Subject of a particular user can be chosen from a list of Subjects, and then would see a list of assigned roles, along with the information about those roles. Roles can easily be selected for deletion and modification.
Role defines the interface to restrict the method execution.
Resultant Context
Application of this pattern solves the user-role assignment problem.
Related Patterns
Administrator Manager Components of OASIS[7] is a refinement of this pattern.
This pattern uses the Commandpattern to design administrative actions as objects.
Known Uses
In OASIS,the administrators are responsible for certain security domains and they are allowed to access and manage the security information of these particular domains. The Meta administrators are responsible for specifying domains, defining security concepts. The Meta administrators and administrators are variants of the
CentralAdministrator and ConcreteAdministrators of this pattern.
Implementation
Since a user may have multiple roles, the Subject class may be implemented to hold a list of roles and their status. Administrator can be implemented to add, revoke and modify these roles.
ConcreteAdministrator can be implemented with permitted operations. The methods assignRole (), revokeRole () and modifyRole () can be implemented to send requests to Admincommand object to assign, revoke or modify roles.
Operation () method can be implemented to provide options to perform only permitted operations and to revoke method according to the selection.
The Factory Methodpattern could be used to create different types of Concrete Administrator objects.
Solution 2
Create a distinct set of roles with different privileges to manage users and roles. Design a hierarchy of administrator roles so that the Central administrator is a composite administrator. Alternative structure of the pattern is depicted in Figure 2.
Figure 2– Alternative solution structure of the pattern
Participants
AdminRole defines the interface for central administrator roles. It also defines the interface for handling junior administrator roles. AdminRole implements the default behaviour for all administrator roles, as appropriate. It needs a reference to a user object.
JuniorAdminRole defines the behaviour for junior administrator roles.
User represents the users who access the system.
Role defines the interface to restrict the method execution by users.
Subject is alist of roles (role names and their status) that a particular user is permitted.
1..*
1..*
1..*
1..*
1..*
1..*
1
Role
+accessControlInterface()
AdminRole
+assignRole()
+revokeRole()
+modifyRole()
+addAdminRole()
+deleteAdminRole()
getAdminRole()
JuniorAdminRole
+assignRole()
+revokeRole()
+modifyRole()
AdminRole
+assignRole()
+revokeRole()
+modifyRole()
+addAdminRole()
+deleteAdminRole()
+getAdminRole()
User
+operation()
Subject
+addRole()
+deleteRole()
+getCurrentRole()
+roleEists()
1..*
Collaborations
AdminRole creates and deletes AdminRoles, and invokes JuniorAdminRole to assign, revoke or modify general roles to user objects.
Consequences
Since JuniorAdminRole is under the control of AdminRole, it can be restricted to handle only a particular set of users, roles or privileges. For example, a junior administrator may not be permitted to revoke roles assigned by another junior administrator or may only be permitted to assign a specific set of roles.
JuniorAdminRoles can also be used to administer users and roles in local domains, in which case Administrator can centrally administer local administrative roles.
Administrator can be implemented to create JuniorAdminRoles with different privileges.
Resultant Context
Application of this pattern solves the user-role assignment problem.
Related Patterns
Administrator Manager Component of OASIS [7] is a refinement of this pattern.
This pattern uses the Hook Method pattern to implement administrative actions.
This pattern uses the Composite pattern [6] to design the administrative roles.
Known Uses
In OASIS,the administrators are responsible for certain security domains and they are allowed to access and manage the security information of these particular domains. The Meta administrators are responsible for specifying domains, defining security concepts. The Meta administrators and administrators are variants of the AdminRole and JuniorAdminRoles of this pattern.
Implementation
Since a user may have multiple roles, the User class may be implemented to hold a list of roles and their status. AdminRole can be implemented to add, revoke and modify these roles.
AdminRole can be implemented to administrate both JuniorAdminRoles and other, common roles. JuniorAdminRoles are implemented to administrate common roles based on responsibilities. The methods assignRole (), revoke Role () and modifyRole () can be implemented to access User objects, and then assign, revoke or modify roles by manipulating the list of roles embedded in User objects. However, they should use different algorithms to administrate users and roles. Template Method or Hook Method patterns can be used to implement this functionality.
References
[1] Department of Defense, Trusted Computer Security Evaluation Criteria, DoD 5200.28STD, 1985.
[2] D. F. Ferraiolo and D. R. Kuhn, Role-Based Access Controls, Proceedings of the 15th NIST-NSA National Computer Security Conference, Baltimore, Maryland, October 1316, 1992.
[3] D. F. Ferraiolo, J. A. Cugini, and D. Richard Kuhn, Role-Based Access Control (RBAC): Features and Motivations, 11th Annual Computer Security Applications Proceedings, 1995.
[4] R. S.Sandhu., J. C. Edward, L. F. Hal, and E. Y. Charles, “Role-Based Access Control Models”, IEEE Computer, Vol. 29, February 96, pp 38-47.
[5] Wolfgang Pree, Object oriented design patterns, SOFSEM'97: Theory and Practice of Informatics, Lecture Notes in Computer Science, 1997, Volume 1338/1997, 266-274, DOI: 10.1007/3-540-63774-5_110
[6] E. Gamma, R. Helm. R. Johnson, and J. M. Vlissides,, Design patterns elements of reusable object oriented software. Addition-Wesley, second edition, 1994.
[7] E. B. Fernandez, M. M. Larrondo-Petri and E. Gudes, A method-based authorization model for object-oriented databases, Proc. Of the OOPSLA 1993 Workshop on Security in Object-Oriented Systems, 70-79.
[8] N. Harrison, B. Foote, and H. Rohnert, Pattern Languages of Programs Design 4. Addison Wesley, 2000.
[9] J. Yoder and D. Manolescu, the PLoP Registration Framework, 1998. URL: http://www.uiuc.edu/ph/www/j-yoder/Research/PLoP. [10] Eduardo B. Fernandez, Günther Pernul and Maria M. Larrondo-Petrie, Patterns and Pattern Diagrams for Access Control, Lecture
Notes in Computer Science, 2008, Volume 5185/2008, 38-47, DOI: 10.1007/978-3-540-85735-8_5
