APLRAC: A Pattern Language for Designing and - CiteSeerX

APLRAC: A PATTERN LANGUAGE FOR DESIGNING AND IMPLEMENTING ROLE-BASED ACCESS CONTROL Saluka R. Kodituwakku1, Peter Bertok1, and Liping Zhao2 1 Department of Computer Science RMIT University, Australia {sakoditu,pbertok}@cs.rmit.edu.au 2

Department of Computation, UMIST, UK [email protected]

Abstract The Object-Oriented paradigm approaches the software development by representing real world entities into classes of software objects. Interactions between classes can be captured by patterns. A pattern language is a collection of patterns composed to solve a complex design problem. This paper presents a collection of object-oriented design patterns structured to form a pattern language for Role Based Access Control (RBAC).

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) [8] and role based access control [6, 7, 13] have been developed. 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 [13] in which privileges are associated with roles and roles are associated with users. Some variations of RBAC [6, 7] include the capabilities of establishing relationships between privileges and roles, and between users and roles. Using object-oriented approach, roles can be represented as objects and privileges as access rights on methods. When roles have overlapping responsibilities, inheritance can be used to design a hierarchy of roles in such a way that any role can execute all methods available to its parent classes. This paper shows that the Object-Oriented paradigm is a promising approach to rolebased access control (RBAC). It presents a model that can be used by administrators to administer and regulate user access to information objects in a manner that is consistent with organizational security policies. The paper is organised as follows. Section 2 gives an overview of RBAC. Section 3 describes a set of patterns for designing and implementing RBAC. Section 4 discusses the results and section 5 concludes the paper.

2. Overview of Role-Based Access Control 2.1 Role Based Access Control Policies Role-based access control policies govern access to information on the basis of activities of users [6, 7, 13]. First roles are identified in the system, then privileges to access objects are specified for roles. A user acting in a role is allowed to execute all accesses for which the role

is authorized. Some RBAC implementations allow a user to act in multiple roles at the same time, others restrict the user to one role at a time. Users, Roles, Subjects, Privileges and Objects 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. Objects and Operations 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. For example, within a database management system, operations might include insert, delete and update.

2.3 Administration of Authorization Administrative policies determine who is authorized to modify the allowed accesses. Rolebased policies benefit from a logical independence in specifying user authorizations by breaking this task into two parts, user-role assignment and role-privilege assignment.

3. Pattern Language 3.1 Descriptive Form The description form used here is derived from GOF form and all Patterns are described with the following components. Name, context, problem description, solution, benefits and drawbacks, resultant context, related patterns and known uses are documented together with implementation examples in the form of code fragments in C++.

3.2 The patterns Pattern 1. Role-Based-Access

2. Administrator Object

Purpose Introduces roles to access protected information objects on behalf of users and introduces distinct roles to administer users and roles. Handles user-role assignment and delegates the administrative responsibilities.

3. Role Validator 4. Single Session 5. Privilege-Limited Role 6. Role-Hierarchies

Validates user-specified roles Creates a session with a validated role Implement role classes based on privileges of the corresponding role. Forms role hierarchies and implements the different access privileges of different roles. Role-Based-Access

Administrator Object

Role Validator

RoleHierarchies Privilege-Limited Role

Command

Single Session Hook Method

Figure 1. Structure of the language 5ROH%DVHG$FFHVV

Context Direct access to information objects is technically possible but may lead to misuse of organizational resources. You want to control user access to information objects so users are permitted to invoke only operations explicitly corresponding to their responsibilities.

Problem Organizational applications require flexible and efficient access control model to restrict user access to information object. The question is: how can you assign access rights in controlled but flexible way?

Forces

•

Users access organizational information to perform various operations defined within the organization. The information needs to be shared for leverage. However, misuse of information could disrupt an organization’s operations and have serious financial, legal, human safety, personal privacy and public confidence impact. Therefore, shared information objects need to be protected but organizational applications must provide flexible access to the protected information objects.

•

•

In most of the organizations, users have job titles and associated responsibilities. However, users having job titles with overlapping responsibilities need to be granted permission such a way that they can perform common operations but do not let them to perform operations out of their responsibilities. Application may allow users to request for executing any valid operation. However, access control must ensure that only authorized operation get executes.

Solution Create roles that conform to user responsibilities, and assign it an appropriate set of privileges. In order to create roles and assigned privileges, v Identify job titles and associated job functions (user responsibilities) within the organization. v For each collection of job functions that a user or a group of users can perform, introduce a role and a set of privileges (access rights).

Resultant Context Privileges assigned to roles are derived from responsibilities belonging to the attached job. Users are not permitted to perform any operation that is not part of their responsibilities. Roles and privileges are assigned and managed by administrators, not by users. This pattern provides an access control mechanism based on user responsibilities and organizational characteristics.

Related Patterns

• •

Dealing with Roles [16] provides a whole pattern language discussing roles with more specific implementation details. Roles [17], Roles create one or more role objects that define the permission and access right for different user groups.

Known Uses

• • •

Some web servers use .htaccess and .htgroups files which define groups of users (Roles) that can access certain areas of a web site. Oracle has a Roles feature for defining security privileges. User-role and role-privilege relationships are stored in tables. The PLoP 1998-registration program [18] has two Roles; attendee and administrator.

$GPLQLVWUDWRU2EMHFWV

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 allow playing 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 allowed playing senior role at the same time. In general, senior roles have privileges to access all piece of information granted for its junior roles. However, 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 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. CentralAdminis trator

Abs tractAdm inis trator

+ createAdm inRole() + deleteAdm inRole()

1..*

1..*

+ operation()

ConcreteAdminis tratorB

ConcreteAdminis tratorA

ConcreteAdminis tratorC

+ operation() + as s ignRole() + revokeRole()

+ operation() + as s ignRole()

+ + + +

1..* 1..* 1 1 AdminCom mand + execute() + getUser()

operation() as s ignRole() revokeRole() m odifyRole()

1..* Subject

1 1

As s ignRole

RevokeRole

ModifyRole

+ execute() + getUser() + as s ignRole()

+ execute() + getUser() + revokeRole()

+ execute() + getUser() + m odifyRole()

1..*

+ + + +

addRole() deleteRole() getCurrentRole() roleExis ts ()

Participants CentralAdministrator defines ConcreteAdministrators.

an

interface

to

create,

delete

and

modify

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 a list of roles (role names and their status) that a particular user is permitted. Administrators create subjects for users by invoking Subject’s interface.

Collaborations

• •

ConcreteAdministrator issues a request to command objects to add, delete or modify roles. In turn, the ConcreteCommand (AssignRole, RevokeRole and ModifyRole) objects invoke the Subject to alter its content. The CentralAdministrator handles the person-role assignment and role-privilege assignment for administrator roles.

Resultant Context • • •

•

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.

Related Patterns

• •

Administrator Manager components of OASIS [19] is a refinement of this pattern. This pattern uses the Command pattern to design administrative actions as objects.

Known Uses In OASIS, the administrators are responsible for certain security domains, 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 ConcreteAdministrators of this pattern.

variants

of

the

CentralAdministrator

and

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 Abstract Factory pattern might be used to create different types of Administrator objects. 5ROH9DOLGDWRU

Context The user may access the system with a valid login name and password. Once the user login to the system, he or she is allowed to access information through roles. This pattern validates the user’s permitted roles before letting him or her to perform any operation.

Problem The different organizations have different security policies and there needs to be control of the access to the protected information objects. The question is: how can you ensure the validity of user roles and associated privileges to access the information objects?

Forces

• •

Administrator assigns a subject (a role or a set of roles) to each user. The user has rights to act any of the roles associated with his subject. However, user request need to be validated against his current active role(s) due to the organization’s security policies. If the user is currently acting a particular role, his new request may conflict with the current role. In such a situation, user should not be allowed to act that role or his current active role should be inactivated before the new role is activated.

Solution Create an object that encapsulates the algorithm for organization’s access control policy. This object accepts user request and checks the validity of the role against user’s subject. Validation + validate() + createRole()

Session

1

Subject +1..* + operation() + getRole()

Role

Participants Validation defines interface for validation and creation of roles. This object interacts with the Subject object to validate user-specified role. Subject holds information of roles assigned to a particular user and status (active or inactive) of those roles. Role defines role objects based on the privileges of the corresponding role. Session is an instance of the Session Object pattern describes next.

Collaborations - Validation object accepts user request and validates the user-specified role. - If user has not been assigned the specified role, validation object invalidates the request with an error message. - If user has been assigned the specified role, and he does not have any active role (session), validation object creates an appropriate role object and forwards the request to that object. - If user has been assigned the specified role, and he has a current session with the specific role, he is allowed to use the current session. - If the role conflicts with the currently active role, the request is forwarded to the Session object.

Resultant Context The users may request to create a session with any role, but the validation object allows users to create sessions with only assigned roles. Validation object can be extended to perform other checks. Subject holds only the information of user’s permitted roles and role objects are created only if a user request to activate a role. This reduces considerable memory overhead.

Related Patterns

•

Role Validator is a generalization of the CheckPoint pattern [17].

Known Uses • The login process for Telnet and ftp servers use Validation. • The Catepillar/NCSA Financial Model Framework [18] uses a variant of this pattern to validate passwords, roles and machines. • The PLoP1998 registration program has a Validation, which only allows authorized users to log onto the system and change their user information.

Implementation Validation class can be implemented to read user input (user_id and role_name) and then interact with the Subject to validate the role. CreateRole() method might be implemented to create different role objects. One might uses Abstract-Factory pattern for creation of role objects.

6LQJOH6HVVLRQ

Context Administrators assign a subject to each user based on their responsibilities within the organization context. The user’s subject is one or more authorized roles. The users are allowed to activate, create a session, with only one of those roles.

Problem User may change his active role over time. The question is: how can you create a single session for a user at any given time with appropriate security checks?

Forces

• •

Role Validator object create role objects (sessions) for valid roles when there are no active sessions or user is allowed to use the active session. However, it does not create sessions when user has an active session with another role. User’s subject is a set of related or unrelated roles permitted to the user. The user is allowed act any role associated with his subject. However, organizational security policies may restrict user to create only one session with any of the roles. Therefore, the user has rights to create a new session even he already has an active session. However, the system must ensures that user has only one active role at any given time.

Solution Create an object, which activates the user specific role and disables all other active roles. Session

Subject 1..*

+ getSubject() + createSession()

1 + setRoleStatus() + operation()

Role

Participants Session defines the interface to access users'subjects and to create a session. It maintains references to Subjects. Subject holds information of roles assigned to a particular user and status (active or inactive) of those roles. Role defines role objects based on the privileges of the corresponding role.

Collaborations Validation object requests to create a session with a specific role. Session object checks the current session against the security constraints and user is allowed to use the current session

or changes the status of the roles in the Subject to deactivate the current session and create a new session with the specific role. Session object also destroys the active role object and creates an appropriate role object for the new session.

Resultant Context Sine users have to create a session with one of the permitted roles before accessing any piece of information, they are restricted to play only one role at a time. This pattern allows users to change their role dynamically but they are not allowed to violate security policies.

Related Patterns

•

Session [17] is a refinement of this pattern.

Known Uses

• •

UNIX Telnet and ftp services use a Session for keeping track of requests and restricting user actions Most databases uses a Session for keeping track of user information

Implementation Subject can be implemented to access assigned roles to users and their states. It might be implemented to scan through all assigned roles and to change the states of RoleStatus objects. 3ULYLOHJH/LPLWHG5ROH

Context After the administrator has assigned a subject to users, user create a Session with one of the roles in his subject to execute operations. This pattern achieves role-privileges assignment by restricting method execution.

Problem The system must assess user requests on the basis of privileges belonging to the users’ role. The question is: how can you implement the role object to reflect the role-privileges assignment?

Forces

• •

Once a user is assigned a particular role he can access information by creation a session. However, roles must be assigned privileges to ensure that roles are granted least privileges for information access. Role validation can be easier when roles are implemented with only permitted operations. However, users may be confused when some operations are either not present or disable.

Since administrator pattern creates only subjects for users, roles assigned to the subject should be granted access rights to ensure that roles are not allowed to execute operations they do not have privileges for.

Solution Only let the user to access what they are permitted. Define a role class for each role introduced by the Role Based Access pattern. The class interface should reflect the privileges of the role. Role + RoleInterface() 1..*

AccessMethods 1 + AccessMethodInterface()

Participants Role defines the interface with only permitted operation for the role and maintains a reference to AccessMethod. AccessMethods declares the interface for all operations perform within the organization and implements them.

Collaborations Client request Role object to execute operations. In turn, the Role object forwards it to the corresponding method in AccessMethods object. In turn, AccessMethods execute the requested operation.

Resultant Context

• • •

The role classes are defined with only operations permitted to them. Consequently, users are strictly limited to access only information to perform their job functions. As a result roles need not implement the operations they do not permit. Actual operations are implemented within the AccessMethods class and it is exclusively included in Role objects. Therefore, user access to the information is completely controlled by roles. In general, organizations perform a large number of operations and it is infeasible to define all of them as a single class (AccessMethods). In such a situation, AccessMethods can be decomposed into a number of small objects.

Related Patterns

• •

Limited-View [17] designs application so user can request to perform only legal operations. Proxy pattern provides an indirection to access information. In particular, Protection Proxy pattern protects information from unauthorized access.

Known Uses OMG-CORBA uses the Proxy variant of the Role Privilege Assignment pattern for two purposes. The client-stub guard clients against the concrete implementation of their servers and the ORB. ORB uses the IDL-skeleton to forward requests to concrete remote server components.

5ROH+LHUDUFKLHV

Context In most of the organizations, users have overlapping responsibilities. Therefore, users acting different roles need to perform some common operations.

Problem Natural role hierarchies can be identified from most of the organizations. The problem is: how can you design and implement such role hierarchies?

Forces

• •

Roles must be design such a way that roles in lower down in the hierarchy (senior roles) has all privileges granted to its junior roles but junior roles should not have additional privileges granted for its senior roles. Although senior roles are allowed to access information granted for its junior roles, some of the privileges granted to junior roles may not be granted to a particular senior role(s).

Solution Define all role objects in the hierarchy with a common interface that conform to the most senior role’s privileges. Use Hook Method pattern to define the interface. For each role, implement these methods such a way that only authorized methods get execute. Role

Client

1..*

1

+ RoleInterface()

+ AccessmethodInterface()

SeniorRoleA

SeniorRoleB

+ RoleInterface()

+ RoleInterface()

SeniorRoleB1 + RoleInterface()

AccessMethods

SeniorRoleB2 + RoleInterface()

Participants Role Defines the interface including all methods (operations) permitted to roles in the hierarchy. The authorized methods are implemented to invoke the corresponding method in AccessMethods. Maintains a reference to AccessMethods SeniorRoles (SeniorRoleA, SeniorRoleB, SeniorRoleB1, SeniorRoleB2) Over rides the methods, which are authorized to them but they are not implemented by any of its junior roles.

If any method authorized to its junior role is not authorized to it, override the method with an empty implementation. AccessMethods declares the interface for all operations perform within the organization and implements them. Client always requests Role to execute methods (operations).

Collaborations Role objects forward the valid requests to AccessMethods and invalid requests are denied.

Resultant Context • • •

When a senior role is revoked from a user, he does not have rights to execute operations permitted for junior roles. If user need to act a junior role, it should be reassigned. Users can request to execute unauthorized methods but the implementation of role objects ensures that only authorized operations get execute. Role hierarchies reduce the number of user role assignments. However, it is difficult to handle some restrictions. For example, once a user creates a session with a senior role, all is junior roles are also activated. Therefore, it is hard to restrict users to act only one role at a time.

Related Patterns

• •

The Hook Method pattern is used for implementation. The Strategy pattern can be used to design different access control algorithms.

Known Users Many object-oriented user interface toolkits use this pattern to add graphical embellishments to widgets.

Implementation Since each role must be implemented to reflect its access rights, senior roles need to implement only authorized methods, which are not implemented by any of its junior roles. When senior role is not granted some of the methods granted to its junior roles, they can be overridden with empty implementation.

4 Discussion This work combines and composes design patterns into a pattern language for developing RBAC systems. The six design patterns address the different phases of role and access privileges assignment and maintenance in RBAC. The connections between the patterns are shown in Figure 1. Each oval represents a pattern, and arrows represent the relationships between patterns. The Role Based Access pattern introduces a set of roles and a set of privileges. In the next step, the Role Validator pattern is used to validate roles and create role objects, and the Single Session pattern creates sessions with valid roles that will eventually control access to the protected RBAC objects. The Privilege-Limited Roles and Role-Hierarchies patterns form the

Role Based Access pattern by designing roles and role hierarchies. The Administrator Object pattern completes the Role Based Access pattern by designing administrative roles to handle user-role assignments and to delegate administrative responsibilities. The Privilege-Limited Role, Role-Hierarchies, Role Validator and Single Session patterns together implement the access control mechanism. The ConcreteRole class controls the execution of methods: requests are forwarded to the corresponding methods in AccessMethods class. The AccessMethods class implements the operations on protected RBAC objects. The Validation class validates user-specified role and creates appropriate role objects. Once the Session class creates a session with that role, user requests are forwarded to the role object. Each class lower down in the hierarchy extends the AbstractRole interface according to its privileges and overrides the Operation () method, i.e. the implementations of role classes performs the role-privileges assignment. The CentralAdministrator class implements methods to handle administrators in complex systems. ConcrteAdministrator classes implement the user-role assignment. Some administrative responsibilities are delegated to the ConcreteAdministrator classes that implement user-role assignment subject to restrictions. Applications using access control is usually based on a fixed set of routinely performed operations. The pattern language presented here defines a complete set of such operations and controls access to them by introducing roles. Application of this language has the following benefits and liabilities. • • • •

For each role of a user the Validation object creates a separate role object. When access rights associated with a role are changed, the changes can easily be propagated to these role objects. Access rights are located exclusively within the role classes. Hence any changes to the policy describing access rights will affect the role classes only. The pattern language introduces administrator roles for user-role assignments. The privileges are automatically assigned to roles through the implementation of role classes. Users assigned to a particular senior role are automatically granted all rights of the associated junior roles. Consequently, revoking a senior role automatically revokes all rights belonging to the associated junior roles.

5 Conclusions •

• •

Object oriented design patterns capture many of the features in a RBAC environment. In particular, objects and associated methods can be used to define protected RBAC objects and operations, and method overriding can be used to implement roles and role hierarchies. The pattern language presented can be applied to design and implement RBAC systems, and a change in role policy has a very limited effect on the whole system. The administration of roles and privileges implemented by OO design patterns is easy and flexible.

Acknowledgments We would like to thank our EuroPLoP2001 shepherd Allan O Callaghan who guided us through several iterations of the article and provided many constructive comments.

References [1] C. Alexander, The Timeless Way of Building, Oxford University Press, first edition, 1979. [2] C. Alexander, M. Silverstein, and S. Ishikawa, A Pattern Language. Oxford University Press, first edition, 1977. [3] F. Buschmann, R. Meunier, H. Rohnert, M. Stal and P. Sommerland, A System of Patterns. Addition-Wesley, first edition. 1996. [4] J. Coplien, Software patterns a white paper. SIGS publications, 1996. [5] J. Coplien, and D. Schmidt, Pattern Languages of Program Design, Addition-Wesley, first edition, 1995. [6] 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. [7] 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. [8] Department of Defense, Trusted Computer Security Evaluation Criteria, DoD 5200.28STD, 1985. [9] M. Fowler, Analysis Patterns reusable object modules. Addition-Wesley, first edition, 1997 [10] E. Gamma, R. Helm. R. Johnson, and J. M. Vlissides,, Design patterns elements of reusable object oriented software. Addition-Wesley, second edition, 1994. [11] J. M. Vlissides , J. Coplien, and N. L. Kerth, Pattern Languages of Program Design 2. Addition-Wesley, first edition, 1996. [12] W. Pree,, Design Patterns for Object Oriented Software development. Addition-Wesley, first edition, 1994. [13] 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. [14] D. Riehle, R. C. Martin, F. Buschmann, Pattern languages of program design 3. Addition-Wesley, first edition, 1998. [15] L. Zhao, and T. Foster, Plots: A Pattern Language of Transport Systems- Point and Route. Pattern Language of Program design 3, 1998. [16] M. Flower, Dealing with roles: Collected papers from the PLoP97 and EuroPLoP 97 Conference, Technical Report #wucs-97-34, Dept. of Computer Science, Washington University Department of Computer Science, September 1997. [17] N. Harrison, B. Foote, and H. Rohnert, Pattern Languages of Programs Design 4. Addison Wesley, 2000. [18] J. Yoder and D. Manolescu, The PLoP Registration Framework, 1998. URL: http://www.uiuc.edu/ph/www/j-yoder/Research/PLoP. [19] 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. [20] W. Essmayr, E. Kapsammer, R. R. Wangner, G. Pernul and A. M. Tjoa, Enterprise-wide security administration, Procs. 9th Intl. DEXA Workshop, 1998, 267-272.

[21] K. Brown, Using the Strategy and Command patterns for SQL code generation. URL: http://hometown.aol.com/kgb1001001/Articles/Command/Command Java.htm [22] J. Barkley, Implementing Role Based Access Control Using Object Technology, First ACM Workshop on Role-Based Access Control.