A Formal Model for Flat Role-Based Access Control - CiteSeerX

Download PDF
16 downloads 15162 Views 80KB Size Report
Comment
opments of this model include the support of the separation of duty constraints. ..... would be working on the information front desk (customer service) before ...
A Formal Model for Flat Role-Based Access Control Etienne J. Khayat

Ali E. Abdallah

Centre for Applied Formal Methods, London South Bank University, 103 Borough Road, London SE1 0AA, UK. [email protected]

Centre for Applied Formal Methods, London South Bank University, 103 Borough Road, London SE1 0AA, UK. [email protected]

Abstract Role-Based Access Control (RBAC) is very useful for providing a high level description of access control. It enables a better understanding of the security problems in an institution because it bridges the gap between their technical aspects and their managerial descriptions. Several models have been devised to describe RBAC. However, the definitions of some of the concepts of RBAC, such as subject, role and permission, were open to many interpretations. Also, the devised models for RBAC, did not detail the analysis of the access operations in RBAC. In this paper, we formalize each of the basic concepts of RBAC for their definitions to be clear and precise. Based on these definitions, a formal state-based model for Flat Role Based Access Control (FRBAC) is constructed, and described in the specification notation Z. This approach permits the close examination of the states in the system. Consequently, it helps to analyse in depth the access operations of RBAC. The model is also refined by supporting the concepts of active roles and private permissions. In the future, the model can be enhanced by extending it to model the delegation and revocation of roles. Other developments of this model include the support of the separation of duty constraints. Keywords Role-Based Access Control, Authorisation, Security, Formal Methods, Z Specification. INTRODUCTION Access control is a mechanism by which a principal can get authorisation to access resources in the system. The principal requests, from a reference monitor, to perform an operation on an object (also known as resource). Based on the principal’s access rights, the access is granted or denied by the reference monitor. A general model for access control is shown in Figure 1. In traditional access control, access rights are assigned to the principals themselves. A table, known as the Access Control List (ACL), maps the principals to the objects they are authorised to access. The Access Control List also specifies the operations by which the principals access the required resources. Today, many organisations implement Role-Based Access Control, known as RBAC. Contrary to the traditional access control, RBAC does not assign the access rights to principals (confusingly referred to sometimes as subjects). Instead, RBAC assigns access rights to the roles that these principals perform in their institutions.

The policy designer or system administrator associated each subject in the organisation with the role that best describe his/her job functions. Consequently, the subjects get access to the objects through their association with the roles in the organisation. There are several models for RBAC, the most basic of which is called Flat RBAC. As its name indicates, the flat RBAC is based on a flat structure of subjects, roles and objects. It does not support any hierarchy of roles or constraints. The features that make Role-Based Access Control (RBAC) attractive to use in enterprises are numerous. Firstly, RBAC organizes subjects and roles in a way that naturally fits the structures of institutions [1]. By associating the access rights to the functions that principals perform in their institutions, RBAC gives security officers a high level view of access control in the organization they serve. It also provides them with tighter control in the application of the security policies. Secondly, RBAC is concise in the way it handles access rights. By associating subjects to roles, it requires assigning access rights to the roles rather than to every subject. This requires less time in managing access rights, because the ratio of the number roles to the number of subjects in an organization is certainly very low (3-4% according to [2]). Moreover, it reduces the amount of work and the probability of error that are incurred when a principal changes roles or a new subject joins the institution. Thirdly, RBAC guarantees consistency of access rights throughout the enterprise. When associating a principal with a certain role, it is guaranteed that this subject will have exactly the same access rights as all the other subjects associated with the same role. Moreover, two subjects that exercise similar job functions in two different branches of an institution, will have identically the same access rights. In this paper, we will first present a formal state-based model in Z for a modified version of the flat role-based access control model [3, 4]. Z is a formal specification notation based on set theory and first order predicate logic [5, 6, 7]. It is especially suitable to model state-based systems, which is the case in this paper. The observation of the states of the system enables to easily know the current access rights of a particular subject. In the last part of the paper, the model will be extended by adding the models for the active roles and private permissions. This paper begins by surveying the work in the literature, related to the terminology and models of RBAC. It then gives precise definitions for the key security terms used in

Principal

Do Operation

Source

Request

Reference Monitor Guard

Object

Resource

Figure 1. A model for access control.

access control such as subject, object, role and permission. A formal model for the flat RBAC is constructed by showing the relations between subjects and roles, and implementing the operation of granting access to objects. Finally, the model is refined to include the concepts of active roles and private permissions. RELATED WORK Terminology Following a survey of role-based access control literature, it was clear that the assumptions made prior to devising RBAC models were not explicit. Moreover, the definitions for fundamental security terms like user, subject and role, were not precise, so they were susceptible to multiple interpretations in different models [1, 2, 3, 4, 8, 9, 10, 11, 12, 13, 14, 15, 16]. The word “principal” has many different meanings and is the source of much confusion [17]. For example, a principal was considered by some researchers a userid [17] and by others, a public key [18, 19]. Most of the surveyed documents [3, 9, 10, 11, 12, 20] considered the user to be a human being or a person. Some authors used the notion of a user to denote an “autonomous agent such as robots, computers or computer networks” [3, 12, 13]. In [21], the user was defined as the “object that accesses the information in the computer system” and in [16], it was considered to be the “real world user of the computing system”. The definitions for the user given above, are not identical. Nevertheless, a different interpretation of the definition of a user was adopted in different papers by the same authors, without a clear statement of any involved assumptions. The concept of a subject is usually informally stated in most of the RBAC models available in the literature. On one hand, a subject was referred to by [11] as “an active entity in the system, operating on behalf of individual users”. On the other hand, [3] considered it as “a session or a unit of access control”. A third approach considered a subject as an “object representing the user” [13]. Other definitions viewed a subject as an “active user process” [9] or an “individual user” [22]. It is clear that no single generic definition can be stated when observing the above definitions. Each of the given definitions is mainly confined to a special model of access control. An early definition of a role was given by [23] as a “collection of rights and duties”. After this period, the debates about the nature of the role could not lead to a single definition [24]. For this, two definitions were presented: a “named collection of users, permissions, and possibly other roles”;

and a “named collection of permissions, and possibly other roles” [24]. These definitions were influenced by the access control mechanisms in operating systems, which were based on the concepts of users and groups. Another definition in that direction of thought is that a role is “a collection of users on one side and a collection of permissions on the other side” [3]. The latest definition in that direction was given by [22], which considered a role to be “a grouping mechanism that is used to categorize subjects based on various properties”. Because role based access control tries to reflect the organization’s structure, the above definitions prove to be incomplete. The definition of [23] does not reflect a clear link to the actual position of the subject in the company structure. Moreover, the other definitions do not give any indication of what job function the principal or subject exerts in the institution. They define the role from the computer system’s view (users and groups) rather than the structure of the enterprise (jobs and positions). Another type of definition for the role stressed on reflecting the company structure and the function exerted by that role. The authors of [13] defined the role to be a “specification of management actions which represent the behaviour or dynamic aspects of a position”. Many papers have presented the role to be a “job function” [9, 10, 11, 12, 20, 16]. In a case study of RBAC in the banking sector, the authors of [2] presented a comprehensive and general definition for the role, which was a “combination of official position and job functions”. The opinions about the nature of an object were less conflicting. An object was defined by [3] as a “data object as well as resource object represented by the data in the system”. The author of [11] considered the object to be a “passive entity within the system that is protected from unauthorized use”. The most generic and precise definition was given by [22] as “any resource in the system”. As for the definition of an operation, it was considered to be the “method of access to objects” [9, 11, 16]. An objectoriented approach for the operation was given by [16] as “the method of the objects”. Although no explicit definition for the task was found in the literature, there was a kind of consensus on the definition of a permission. Most of the authors considered it as an approval or an authorization to access system objects [3, 10, 12, 20, 16, 21, 13]. One implicit definition of a permission as “a binary relation between operations and objects”, was stated by [11]. Models Based on some of the definitions introduced previously, the papers in [3, 4, 9] have built four consecutive Role-Based Access Control models. The first model, known as RBAC0 , included the basic features. They are similar to the features of the traditional group-based access control [4]. The next two models were built based on RBAC0 , but were independent of each others; RBAC1 supported hierarchy of roles and; RBAC2 supported constraints such as mutual exclusion of roles and

separation of duties [3, 13]. The symmetric model, RBAC3 , was the last model, it was extended to involve all the features of the previous three models [4]. The only state-based approach for modelling role based access control was given in [25]. Unfortunately, the paper did not detail the system’s change of states upon the occurrence of the different operations involved in a role-based access control model. Also, it was very brief in its analysis and presentation of the model. FORMAL DEFINITIONS The definitions of essential concepts of RBAC, summarized earlier on, are inconsistent in their meanings. Hence, they are open to different interpretations. Also, they are not generic enough to have a global definition that can be translated in other areas of computer security, such as trust management and authentication. In the following paragraphs, broader yet precise definitions of a principal, subject, user, object, role, operation, task and permission will be presented. They will be generalized in order to match their definitions in the other areas of computer security. The devised definitions will be used to build the flat RBAC model in this paper, which will be known as FRBAC. Principal We adopt the definition given by [26], which states that on the policy level, a principal is an entity that can be granted access, or can make statements affecting access control decision . The term “principal” represents a username associated with a subject. The set of all principals will be referred to as PRINCIPAL. Subject A subject usually refers to a human being. As such, subjects can have multiple usernames. We consider the subject to be a name that is associated with a collection of principals [26]. For example, if a subject called John acts as a system administrator in a company, then he might have two user identifications (principals): one related to his status of employee (e.g. John239); and another one related to the administrator’s job he performs (such as admin). A subject is linked to its principals in an unforgeable manner, such as authentication. The set of all subjects is called SUBJECT. Formally, a subject is associated to a set of principals through the function Subjectassociation: Subjectassociation : SUBJECT → P PRINCIPAL User A user is an informal term that is used to denote a subject. Object We consider an object to be any resource in the system that can be assigned access rights. In operating systems, an object can be a file or a directory. In a banking application, an object can be a the record of a customer’s account in the bank’s database [2]. An object can also be a physical or a

stand-alone device such as a printer, a web cam or a monitor. The set of all the names of the resources that can be assigned access rights is denoted by OBJECT. Role A role summarises an occupation, a position or a principal’s description of job functions [4]. A role is formalized as a name. Let ROLE be the set of all possible role names in a system. Operation An operation is a term used to describe an action. The meaning of the action depends on the context it is used in. In operating systems, the operation write refers to the action of writing to a file or a directory. In the educational sector, the operation submit denotes the action of submitting an assignment [27]. Formally, an operation is a transformation that takes a set of inputs and a system state, and gives a set of outputs and a system state. The term OPERATION refers to the set of all possible operation names. Task A task is a combination of an operation and a collection of objects. In operating systems, a task of reading a file called grades, performs the operation read on the object grades. In a bank [2], a task of a money transfer from account A to account B, is the operation "transfer", performed on the objects A, B and the amount to be transferred, which is part of the data of account A. The set of all possible tasks is denoted by TASK. TASK : OPERATION × P OBJECT. In the literature [12, 13, 14, 15, 28], there is a distinction between two types of tasks: authorizations or authorities (referred to as rights in some times) and duties (also known as obligations). Authorizations are the tasks (or rights) a subject or a role can perform, while obligations (duties) are the ones that the subject or role has to perform. For the scope of this paper, the issue of distinguishing between authorizations and obligations will not be tackled. Both authorizations and obligations will be referred to as tasks. Permission Roles are authorized, through permissions, to perform tasks. Devising a specific definition for the permission depends on the context where this definition will be used [4]. The NIST model in [4] mentions that "terms like privilege, authorization and access right are used in the literature to denote a permission". Although there are other definitions in the literature, we find that the definition of a general permission as the authorization to perform a task is expressive and general enough. PERMISSION : ROLE → 7 P TASK.

Principals

Roles

Tasks Permissions

Figure 2. Associations of principals, roles and tasks.

FORMAL MODEL In this part, the terminology mentioned in the previous section will be used to build the formal model, FRBAC, for the flat RBAC. Association of Principals to Roles Whenever a principal needs to access a resource, it has to get the access through a role. For this reason, principals get associated with roles that describe the organizational job functions of their subjects. Principals are associated with roles through many-to-many relationships [9], represented by the two-headed arrows in Figure 2. It means that each role will have a list of principals associated with it and each principal can be associated to many roles. The function Roleallocation returns the list of roles to which every principal is associated: Roleallocation : PRINCIPAL → P ROLE.

Capturing the Abstract State of the FRBAC Model Instead of being granted directly to subjects, the access rights in role-based access control are given to the roles that these subjects perform in an institution. This results in the roles being permitted to perform tasks and, in consequence, access the authorized resources. The roles that are part of the implemented FRBAC in an institution should be part of the roles defined by this institution. Also, the subjects of this FRBAC are the human users that are authorised by this institution to have access to the system, such as the institution’s employees or external users dealing with this it. The principals in this FRBAC are part of the set of usernames defined by the system administrator of this institution, in order for the subjects to log in and use the computer system. The objects in this FRBAC would be any resource used in this institution that can be assigned access rights. As for the operations, they refer to all the access related actions that are are defined by the functional requirements of the work in this institution. The tasks in this model are part of the combination of each of the actions with all their target objects in this institution. The permissions implemented in the FRBAC system are part of the total authorisations that allow the tasks in this institution to be executed. The relationships between all the concepts of RBAC, just mentioned, are summarised in the following schema, which shows the model for FRBAC.

FRBAC Roles : P ROLE Principals : P PRINCIPAL Roleallocation : PRINCIPAL → P ROLE Subjects : P SUBJECT Subjectassociation : SUBJECT → P PRINCIPAL Subjectrole : SUBJECT → P ROLE Objects : P OBJECT Operations : P OPERATION Tasks : P(OPERATIONS × P OBJECTS) Permissions : ROLE → P TASK dom Roleallocation = Principals ran Roleallocation ⊆ Roles dom Subjectassociation = Subjects ran Subjectassociation ⊆ Principals dom Subjectrole = Subjects ran Subjectrole ⊆ Roles dom Permissions = Roles ran Permissions ⊆ Tasks ∪Tasks ⊆ Operations × P Objects To perform an operation on an object, a principal must be associated, through the function Roleallocation, with a role that is authorised to access this object. This role must have the required operation and the target object in the list of its authorised tasks (in the function Permissions). This process is summarised in the schema called AccessObject. The decision about granting or denying access to an object, is reflected in an output report of AccessObject. The possible output reports are listed in REPORT: REPORT ::= OK | Access Denied AccessObject ΞFRBAC r? : Roles p? : Principals op? : Operations o? : P Objects rep! : REPORT r? ∈ / Roleallocation(p?) ∨ hop?, o?i ∈ / Permissions(r?) ⇒ rep! = Access Denied r? ∈ Roleallocation(p?) ∧ hop?, o?i ∈ Permissions(r?) ⇒ rep! = OK To illustrate the initialisation of the FRBAC model, let’s consider the example of the attendance list of a course taught in a particular university. The attendance list is published on the website of the university. The lecturer of this course can view and modify the content of the attendance list, but the students can only view it. Any user not being a student or a lecturer is considered a public user. He/she cannot view

nor modify this attendance list when browsing this university’s webpage. This example is illustrated in the schema InitialFRBAC. InitialFRBAC Roles0 = {Lecturer, Public, Student} Principals0 = {anne23, anonymous, john14, } Roleallocation0 = {(anne23, Student), (anonymous, Public), (john14, Lecturer)} Subjects0 = {Anne Johnson, John Brown, Unknown} Subjectassociation0 = {(Anne Johnson, anne23), (John Brown, john14), (Unknown, anonymous)} Subjectrole0 = {(Anne Johnson, Student), (John Brown, Lecturer), (Unknown, Public)} Objects0 = {Attendance List} Operations0 = {View, Modify} Tasks0 = {(View, Attendance List), (Modify, Attendance List)} Permissions0 = { (Student, {(View, Attendance List)}), (Lecturer, {(View, Attendance List), (Modify, Attendance List)})}

For the initialisation of FRBAC to be correct, the roles Lecturer, Public and Student should valid roles, i.e. defined in the access control system of this university. Moreover, the principals anne23, anonymous, and john14 should be usernames managed by the system administrator in this university. Clearly, the object Attendance List should be an actual attendance list on the website of this university. The operations to be performed on it (tasks) should be defined in the list of tasks produced by the functional specification of the university’s website.

Allocation and Removal of Roles The association of principals to roles is the duty of the system administrator [9]. RBAC reduces the amount of system maintenance that the administrator has to perform. This is due to the fact that the description of roles and job functions in an institution don’t change so often. Also, since access rights are associated with the roles, the administrator have no more to maintain access control lists for every subject, like it was the case in traditional access control mechanisms. When a principal p is to be allocated a role r, this role must not be already associated with this principal (r ∈ / Roleallocation(p)). If this condition is fulfilled, this role’s name is added to the list of role names that are associated with p (Roleallocation(p)). The operation AddtoPrincipalRole formalizes the allocation of a role to a principal.

AddtoPrincipalRole ∆FRBAC r? : Roles p? : Principals r? ∈ / Roleallocation(p?) ⇒ Roleallocation(p?)0 = Roleallocation(p?) ∪ {r?} When the system administrator needs to prevent the principal p from exerting role r. Then, he/she removes r from the list of associated roles with p. The operation RemovePrincipalRole formalizes the deletion of a role from a principal’s list of associated roles. RemovePrincipalRole ∆FRBAC r? : Roles p? : Principals r? ∈ Roleallocation(p?) ⇒ Roleallocation(p?)0 = Roleallocation(p?) \ {r?} CASE STUDY: SIMPLE OPERATION IN A BANK The following example serves to test the applicability of the derived RBAC model (FRPAC) in the banking sector. Due to the obvious reasons of confidentiality and security, it is difficult to find a concrete case study covering the operations and the data manipulated in a bank. For this, we adopt the example of the European Bank presented in [2]. This case study provides a real-life session in the banking sector, we have fitted it to the devised FRBAC model. Description of the Operation The scenario presented is that of a client, who visits his/her bank to discuss his/her financial situation with a financial advisor. What usually happens is that the client and the financial advisor go into a private meeting room (not necessarily the financial advisor’s office) which is equipped with a personal computer. The financial advisor authenticates him/herself to the computer using his smart card and password1 . Next, he/she launches an application that presents him/her with a window to enter the customer’s details, such as the customer’s account number. This application is linked to a server where all the required information is located. In this bank, this application is called Private Customer Instruments Applications (Figure 3). It takes as inputs (arguments): the employee number of the financial advisor, known in this example as UserID, and read during authentication; and the application’s own identification, known as ApplicationID. The application presents these inputs to the access control system. This will enable the application to know the access rights for this particular financial advisor, in the scope/domain of the application itself. The access rights of the financial advisor are grouped in a security profile and returned to the application. 1 This

particular method of authentication was used in this bank. It is not necessarily used in other banks or institutions.

If this security profile contains an access right to view the customer’s financial details, the application shows the details on the screen. Otherwise, it denies this financial advisor the required access. The whole access request is summarized in Figure 3. Each of the arrows represents a step, which, with many others, complete the requested access. Each of these steps is represented by the form of a function, whose name is indicative enough of its use. The arguments of each of these functions are shown between parenthesis. It is worth noting that the Private Customer Instruments Application also supplies the Access control system with the department number of the financial advisor, shown in Figure 3 as Org. Unit. This was particularly important in this bank in order to determine whether the access rights of this financial advisor are bound to this particular branch of the bank, or expands to other branches. This is not accounted for in FRBAC because we feel that if the system roles were created in a way that they relate to their domain of application, there will be no need to take the department, or organisational unit into account. The creation of new roles is part the administrative RBAC models and falls outside the scope of FRBAC [3, 9]. Financial Advisor

Personal Computer

Private Customer Instruments Application

system administrators know what roles they are assigning to which principals. So, operations like, Show Content and Extract Interest Value etc. would be referred to by specific numbers, known internally only to highly-ranked bank employees. AccessObject ΞFRBAC Financial Advisor? : Roles ID 1? : Principals Show Content? : Operations Account1? : Objects rep! : REPORT Financial Advisor? ∈ / Roleallocation(ID 1?) ∨ hShow Content?, Account 1?i ∈ / Permissions(Financial Advisor?) ⇒ rep! = Access Denied Financial Advisor? ∈ Roleallocation(ID 1?) ∧ hShow Content?, Account 1?i ∈ Permissions(Financial Advisor?) ⇒ rep! = OK

Access Control System

REFINEMENT OF THE MODEL

Identity/Authenticate (UserID, Password)

Authentication_Confirmation

Launch(Application) Security_Profile_Request (UserID, ApplicationID, Org. Unit)

Security_Profile_Delivered (SecurityProfile) Access_Granted(ApplicationID, AccessRights)

Figure 3. Access operation in a bank.

Adaptation of FRBAC In this example, the subject is the bank employee who is serving this customer. His/her role is a financial advisor, and will be known as Financial Advisor. The userid of this financial advisor is a principal, and is assumed to be ID 1. The customer’s account (Account 1), to which this access is required, is an object. The requested operation is to view the account’s content, and it is referred to as Show Content. In this case, the task is the combination of the operation Show Content and the object Account 1. The model for the access operation of FRBAC, applied in this example is shown below. This schema differs from the exact real-life scenario in that all textual names in the policy that refer to RBAC concepts, are actually replaced in the automated system by identification numbers or IDs. Usually, roles are not mentioned in the automated system by their names, but by their IDs. In most cases, it is desirable not to let even

Incorporating Active Roles Many authors in the RBAC literature, such as [9], state that a principal needs to be active in a role in order to be able to perform the tasks permitted to this role. For example, an employee might be assigned multiple roles in a company, but sometimes, he/she might be allowed to perform only some of them, the "allowed" roles are the actives roles for this employee. For a principal p to be given access to an object, two conditions must be fulfilled: • The principal p must be associated with a role, r, that has access to the required object (r ∈ Roleallocation(p)). • The role, r, must be activated for the principal p. For this, we will define a function Activeroles to give the set of current active roles for a specific principal: Activeroles : PRINCIPAL → 7 P ROLE. This first refinement of the FRBAC model is reflected in the schema FRBAC 1: FRBAC 1 FRBAC Activeroles : PRINCIPAL → 7 P ROLE ∀ p : Principals • Activeroles(p) ⊆ Roleallocation(p) To the access conditions listed above, some institutions add a restriction that limits the number of roles in which a principal is active. This is known as the constraint of cardinality of roles. Another constraint is when a principal is not allowed to assume simultaneously two specific roles that are considered to have conflicting interests to the organisation [4]. This is called the principal of separation of duties [1, 3, 9]. To

clarify this principal, consider the case of a money transfer transaction in a bank. Most banks prohibit a principal from taking part, at the same time, in the following two roles: the role that authorizes the transfer operation and the one that executes it. In the way FRBAC 1 is modelled, it will be easy to account for these constraints. For example, if an institution needs to limit the cardinality of principal’s roles to two, then the policy designer can enforce the cardinal the Activeroles of principals to be equal to two. The schema of AccessObject is also changed to account for the refinement of including the activation of roles . AccessObject ΞFRBAC 1 r? : Roles p? : Principals op? : Operations o? : P Objects rep! : REPORT r? ∈ / Roleallocation(p?) ∨ r? ∈ / Activeroles(p?) ∨ hop?, o?i ∈ / Permissions(r?) ⇒ rep! = Access Denied r? ∈ Activeroles(p?) ∧ hop?, o?i ∈ Permissions(r?) ⇒ rep! = OK Refined Case Study In their daily operations, many banks adopt a policy of rotating some employees between different sections of the bank, to assume different job functions. For example, an employee would be working on the information front desk (customer service) before noon, then he/she takes a cashier’s position in the afternoon. This policy is adopted in order to achieve better work efficiency and account for increasing work load during the peak periods of the day. So, when an employee leaves the function he/she has been occupying for some period, the role that he/she was executing is deactivated for him/her. The next function he/she is to execute sees him/her being activated the role associated with it. Suppose that a bank employee works as a cashier before noon, and exerts the functions of a customer service agent in the afternoon. He/she would be associated with both the roles of Cashier and Customer Service Agent, with the role of Cashier active before noon and the role of Customer Service Agent deactivated. When he/she switches functions in the afternoon, the role of Cashier gets deactivated, and the role of Customer Service Agent becomes active for him/her. In the bank’s example of this paper, the condition that the financial advisor is to be associated with a role that has the permission to perform the operation Show Content on the object Account 1 is no more sufficient for granting him/her access. The additional condition is that this financial advisor has to be active in the role of Financial Advisor. The model of the operation of accessing resources, AccessObject is updated to include this condition in the case of a bank.

AccessObject ΞFRBAC 1 Financial Advisor? : Roles ID 1? : Principals Show Content? : Operations Account1? : Objects rep! : REPORT Financial Advisor? ∈ / Roleallocation(ID 1?) ∨ Financial Advisor? ∈ / Activeroles(ID 1?) ∨ hShow Content?, Account 1?i ∈ / Permissions(Financial Advisor?) ⇒ rep! = Access Denied Financial Advisor? ∈ Activeroles(ID 1?) ∧ hShow Content?, Account 1?i ∈ Permissions(Financial Advisor?) ⇒ rep! = OK Incorporating Private Permissions In RBAC, any principal or subject associated with a role r will be granted permissions to perform the authorised operations on all the target objects of the permitted tasks of r. Although access decisions are associated with roles, there are some access decisions that have some dependency on the specific principal who is to perform them. For example, consider the role Lecturer Computer Science in a university, which points to the lecturers in the computer science department. What happens is that the role Lecturer Computer Science will have permissions to edit online lectures, change posted grades etc. But these permissions do not differentiate between the lectures that each of the lecturers teach. A lecturer of the software engineering course will have an authorisation to edit online lectures of the formal modelling course. It is important to prevent lecturers from the computer science department, associated with a same role, from performing some operations on the lectures other than the ones they teach. Another case occurs in a networked operating system. Suppose that all principals associated with a role r1 are permitted to perform print jobs, cancel print jobs and view print jobs on a printer pt. Although all these principals are associated with the role r1, the tasks of cancelling a print job should be confined to the principal who actually initiated this printing job (i.e. the principal who is printing the document). From these examples, we realise that the permissions to perform some tasks should depend on both the role and the principal that is requesting to perform them. The principal should be permitted to perform tasks on objects that relate to him/her and should be prevented from performing these tasks on objects not related to his/her work. We call such permissions Private Permissions, and refer to them as PPERMISSION: PPERMISSION : ROLE × PRINCIPAL → 7 P TASK. Another application of private permissions is their use in role hierarchies, where they relate to private roles [3, 4]. Private roles are used by principals to store access rights that are

prevented from being inherited by their senior principals. FRBAC’s second refinement, that is the inclusion of private permissions, is shown in the schema FRBAC 2. FRBAC 2 FRBAC PPermissions : ROLE × PRINCIPAL → 7 P TASK ∀ p : Principals, r : Roles • PPermissions(r, p) ∩ Permissions(r) = ∅ dom PPermissions ⊆ Roles × Principals ran PPermissions ⊆ Tasks

[5] [6]

[7]

[8] CONCLUSION In this paper, the key components of Role-Based Access Control were formalised in order to be sharp, precise and prevent their multiple interpretations. These new definitions were used to build a formal model for the flat RBAC, which was called FRBAC. We have adopted a state-based approach to the model, and precisely represented the access operations involved in RBAC. We represented the model using the well known formal notation, Z. Formal methods in general and Z, in particular, prove to be an important tool in the current research aimed at modelling the security features of computer systems [29]. We have supplied a case study in the banking sector where we have applied FRABC. In addition to that, we have extended FRBAC to include the concepts of active roles and private permissions. A future extension of the FRBAC is the adoption of the delegation and revocation of roles. Delegation of roles is increasingly used by organizations in such a way that any useful flat RBAC model should support it. A development for the model in this paper would be the inclusion of role hierarchies in FRBAC. This amendment will provide a better reflection of the structures of companies in the formal models. Another development would be to elaborate on the support of the important constraints of dynamic and static separation of duties. REFERENCES [1] D. Ferraiolo and J. Barkley, “Specifying and Managing Role-Based Access Control Within a Corporate Intranet,” in Proc. of the 2nd ACM workshop on Role-Based Access Control, George Mason University, Fairfax, Virginia, USA, June 1997, pp. 77–82. [2] A. Schaad, J. Moffett, and J. Jacob, “The Role-Based Access Control System of a European Bank: A Case Study and Discussion,” in Proc. of the 6th ACM Symposium on Access Control Models and Technologies, Litton-TASC, Chantilly, Virginia, USA, May 2001, pp. 3–9. [3] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman, “Role-Based Access Control Models,” IEEE Computer, vol. 29, no. 2, pp. 38–47, Nov. 1996. [4] R. Sandhu, D. Ferraiolo, and R. Kuhn, “The NIST Model for Role-Based Access Control: Towards A

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17] [18]

Unified Standard,” in Proc. of the 5th ACM workshop on Role-Based Access Control, Technical University of Berlin, Berlin, Germany, June 2000, pp. 47–63. I. Hayes, Specification Case Studies, 2nd ed. Prentice Hall, 1993. L. Bottaci and J. Jones, Formal Specification Using Z: A Modeling Approach. International Thomson Computer Press, 1995. J. Bowen, Formal Specification & Documentation Using Z: A Case Study Approach. International Thomson Computer Press, 1996. T. Jaeger and J. Tidswell, “Rebuttal to the NIST RBAC Model Proposal,” in Proc. of the 5th ACM workshop on Role-Based Access Control , Berlin, Germany, June 2000, pp. 65–66. D. Ferraiolo, J. Cugini, and R. Kuhn, “Role-Based Access Control (RBAC): Features and Motivations,” in Proc. of the 11th Annual Computer Security Applications Conference, New Orleans, LA, USA, Dec. 1995, pp. 241–248. E. Barka and R. Sandhu, “A Role-Based Delegation Model and Some Extensions,” in Proc. of the 23rd NIST-NCSC National Information Systems Security Conference, Baltimore, USA, Oct. 2000, pp. 101–114. W. A. Jansen, “A Revised Model for Role Based Access Control,” National Institute of Standards and Technology (NIST), USA, NIST-IR 6192, July 1998. E. Barka and R. Sandhu, “Framework for Role-Based Delegation Models,” in Proc. of the 16th IEEE Annual Computer Security Applications Conference, New Orleans, Louisiana, USA, Dec. 2000, pp. 168–175. E. Lupu, D. Marriott, M. Sloman, and N. Yialelis, “A Policy Based Role Framework for Access Control,” in Proc. of the 1st ACM/NIST Workshop on Role Based Access Control, National Institute of Standards and Technology, Gaithersburg, Maryland, USA, Dec. 1995, pp. II15–II24. S. Na and S. Cheon, “Role Delegation in Role-Based Access Control,” in Proc. of the 5th ACM workshop on Role-Based Access Control, Technical University of Berlin, Berlin, Germany, June 2000, pp. 39–44. N. Yialelis and M. Sloman, “A Security Framework Supporting Domain Based Access Control in Distributed Systems,” in IEEE Proc. of the Internet Society Symposium on Network and Distributed System Security, vol. 2, San Diego, CA, USA, Feb. 1996, pp. 26–39. M. Hitchens and V. Varadharajan, “Design and Specification of Role Based Access Control Policies,” in Proc. of IEE-Software, vol. 147, no. 4, Aug. 2000, pp. 117–129. D. Gollmann, Computer Security. John Wiley & Sons, 1999. R. Rivest and B. Lamspon. (1996, Apr.) SDSI - A Simple Distributed Security Infrastructure.

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

Massachusetts Institute of Technology. Cambridge, USA. [Online]. Available: http://theory.lcs.mit.edu/˜rivest/sdsi10.html C. Ellison, B. Franz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen, “SPKI Certificate Theory,” Internet draft RFC 2693, IETF SPKI Working Group, Sept. 1999. L. Zhang, G. J. Ahn, and B. T. Chu, “A Rule-Based Framework for Role-Based Delegation,” in Proc. of the 6th ACM Symposium on Access Control Models and Technologies, Litton-TASC, Chantilly, Virginia, USA, May 2001, pp. 153–162. W. B. Shim and S. Park, “Implementing Web Access Control System for the Multiple Web Servers in the Same Domain Using RBAC Concept,” in Proc. of the 8th IEEE International Conference on Parallel and Distributed Systems, KyongJu City, Korea, June 2001, pp. 768–773. M. Moyer and M. Ahamad, “Generalized Role-Based Access Control,” in Proc. of the 21st IEEE International Conference on Distributed Computing Systems, Meza, Arizona, USA, Apr. 2001, pp. 391–398. B. Biddle and E. Thomas, Role Theory: Concepts and Research. New York: Robert E. Krieger Publishing Company, 1979. R. Sandhu, “Roles Versus Groups,” in Proc. of the 1st ACM Workshop on Role Based Access Control, National Institute of Standards and Technology, Gaithersburg, Maryland, USA, Dec. 1995, pp. I25–I26. B. Steinmuller and J. Safarik, “Extending Role-Based Access Control Model with States,” in Proc. of the IEEE International Conference on Trends in Communications, vol. 2, Bratislava, Slovakia, July 2001, pp. 398–399. B. Lampson, M. Abadi, M. Burrows, and E. Wobber, “Authentication in Distributed Systems: Theory and Practice.” ACM Transactions on Computer Systems, vol. 10, no. 4, pp. 265–310, Nov. 1992. T. Jaeger, T. Michailidis, and R. Rada, “Access Control in a Virtual University,” in Proc. of the 8th International IEEE Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, California , USA, June 1999, pp. 135–140. A. Schaad and J. Moffett, “Delegation of Obligations,” in Proc. of the 3rd International Workshop on Policies for Distributed Systems and Networks, Technical University of Berlin, Berlin, Germany, June 2002, pp. 25–35. A. Abdallah, P. Ryan, and S. Schneider, Eds., Formal Aspects of Security, ser. Lecture Notes in Computer Science. London, UK: Springer-Verlag, 2003, vol. 2629.