Overview Of RBAC

1 Introduction

ampson[8] introduced some basic ideas about discretionary access control(DAC) but has an

inherent weakness that information can be copied from one object to another. It is difficult for DAC to enforce a safety policy and protect against some security attacks. Mandatory access control (MAC) was invented in order to overcome the shortcomings of DAC and to enforce lattice-based confidentiality policies in the face of Trojan Horse attacks. Sandhu et al[7] presented now standardized Role based access control (RBAC), which was considered as a promising alternative to resolve the shortcomings of both DAC and MAC.

L

RBAC as model provides some merits and hence has contributed to its widely use. It can easily mirror an organization’s structure and encourage well-structured access control policies. It provides a powerful mechanism for reducing the complexity, cost and potential errors of assigning users permissions within the organization. It naturally supports delegation of access permissions. The most common method of implementing access control in a computer system is through access control lists (ACL). Despite the widely use and adoption of the American National Standard Institute (ANSI) on Role-Based Access Control (RBAC) in the commercial arena, it still has some associated limitations that needs to be confronted and resolved.

2 Short comings of RBAC

n this section, I will discuss some notable short comings of RBAC. The identified short comings

of RBAC are collectively group into two groups namely: vagueness and limited expressiveness. The subsections below provides a thoroughly overlook of these short comings.

I

Vagueness

RBAC standard is vague to some margin on the following points :

● [Notion of Role:] Role in ANSI RBAC[11] is established as a job function within the context of an organisation with some associated semantics regarding authority and responsibility conferred on the user assigned to the role ([11], p. 233). Role in RBAC is not definitely established what it represents and poses a lot of questions. Within an organisational context, is a role just a job function formally? or should a role be understood functionally?. Is a role simply an identifier for a particular type of ascribed status? The name of a set (of role members? Permissions?).

● [Hierarchy issues in RBAC:] Hierarchical RBAC adds requirements for supporting role hierarchies[11]. Demonstratively, Hierarchical RBAC component defined mathematically a partial order of seniority relation between roles which seems to be inappropriate when issues like update of roles is taken into consideration. RBAC

1

his report provides a technical overview of RBAC(Role-Based Access Control) in the sense of its short comings and the potential extensions that can be made to enhance expressiveness and richness of RBAC's. Despite the widely use and adoption of the

American National Standard Institute (ANSI) on RBAC in the commercial arena, it still has some associated problematic (limitations) that needs to be confronted and resolved. The report sorts not to provide an alternative to RBAC but to bring to bear the enhancements that has been made. It is also to provide a supplementary short and concise overlook of RBAC.

T

Author : Frank Appiah

Date : 26/10/10

Title : Overview of RBAC

Version : 1.0

©2010 All Rights Reserved.

failure to address this issue poses a lot questions and puts a burden on the development of an effective administrative RBAC model. This exposes the vagueness of ANSI RBAC as a standard. According to ANSI RBAC, partial order of seniority between roles means that senior roles acquire the permissions of junior roles and junior roles

acquire the user membership of the senior roles. This poses the following questions:1. Is this unconstrained upward inheritance

which violates least privilege?2. Is role activation transitive?: When there

is no session then role activation does not exit at all which even greatly affects the notion of role activation (transitivity). With Single Role Activation (SRA), only one role activation in a session which makes Role Activation (RA) transitivity not applicable.

3. What is the correct semantics of SoD (Separation of Duties) with inheritance?The standard is unclear about the issues and these are left as an implementation issue with no one solution.

Limited Expressiveness

NSI RBAC as a standard failed to address the expressiveness and richness of the model to

definitely establish how access control for some different context aside the organisational picture painted in the standard should be confronted. Below are some of the few points to back the point of limited expressiveness in RBAC:

A

● [No Usage Control:] In this global era, digital objects are all around us and it is important to allow privilege access with consumable functionality to avoid abuse and help protect the works of others. For example, a payment made with your credit card to buy a ticket to watch a movie can be used only once at the cinema or a SaaS

provider can provide software for other companies who have purchased a consumable number of access that is addressed either by decreasing their access counter by 1 or increasing the cost by a certain amount until the maximum is reached which they have pay for. Controlling usage of sensitive information requires protection of digital information that may be important to organisations and nations. Relatively, Content Providers' interest belongs here also; to maximize ROI(Return-on-Investment) to run the company. RBAC as a standard did not take into account how this kind of usage control can be catered for in the scenario described above. Usage access control does not fall into RBAC's notion of job function and organisational picture painted to us. RBAC's failure to address this type of access control has introduced a limited expressive power into the model and its been a standard is questionable, and needs an extension possibly.

● [Negative authorisation:] RBAC failed to express how negative authorisation should be carried out and the ANSI RBAC claims to satisfy the least privilege without addressing how this concern poses a lot of questions that it needs to be answered.

● [Limited Status Control:] The ANSI RBAC model in a distributed sense fails to scale because of the bottleneck introduced in the model. The standard RBAC model assumed a more relatively static access environment which will be administered by human users, with a complete knowledge of users, job functions, qualifications and responsibilities, and this tends not be available in a dynamic distributed sense like ubiquitous system: distributed sensor system for weather forecasting. Barker[3] for example pointed out that the model is also concerned with a one-type ascribed status, an assignment of user to a role. According to Barker, the elements of RBAC makes it suitable for use in the centralised case are not necessarily so relevant in a certain distributed computing

2


Date : 26/10/10


Version : 1.0


OV

ER

VIE

W O

F RB

AC

context([3], p. 1:3).● [Time and Triggered(Event-based)

access:] Temporal authorisation enables Security Administrators to specify that a user's permission to access resource is to hold for a restricted time interval and automatically expires as soon as the maximum time point in the interval is elapsed[6]. RBAC overlooked all the above merits and failed to definitely establish how this is to be catered for in different temporal authorisation context that certain resources would and should be accessed. For example, the UK Visa Border Agency grants visas to persons for a specify time interval specified in date and resources that are accessible by visa requester expires after that interval. Without temporal authorisation, ANSI RBAC is only feasible for fixed and always accessible resources which tends not be possible for all scenarios in real life. Clearly, lack of temporal authorisation greatly reduced the expressiveness of standard RBAC model. RBAC does not allow Security Administrators to express proactive specifications because of the lack of temporal constraints. In a distributed context, entities requesting information from a resource may not be known and also user authorisation may change dynamically on the basis of occurrence of wider range of events other than the role and permission assignments used in RBAC[9]. RBAC is limited to express policies for a dynamic and distributed environment. This contributes to its limited expressive power.

● [No Spatial Control:] In the area of pervasive and ubiquitous computing, location information will be necessary to access certain kind of information. With the growing of wireless network and mobile device like mobile phones, PDA's etc. Spatial representation in RBAC is another head-on battle that the implementer is the loser in this war in the cyberspace.

3 Potential extensions of RBAC

or the shortcomings of the ANSI RBAC model short listed in Section 2, I will discuss the

potential ways in which the ANSI RBAC model has soundly been extended to address the shortcomings:

F

Addressing vagueness in RBAC

● [Notion of Role:] According Sandhu, Roles in RBAC are (1) a set of users and (2) a set of permissions. This is definition is a bit more clearer because it at least keeps one of the most important key of interest at any point in time, set of permissions. The notion of role can be extended to include that a role is sometimes argued to be a set of privileges whiles a group as a set of users.

● [Addressing hierarchy issues in RBAC:] The ANSI RBAC standard should distinctly clarify the difference between base relations and derived relations by allowing only one of user assignment and assigned users be treated as a base relations which is allowed to be updated by administrative functions. An auxiliary derived function can be used to specify other RBAC specifications. The Reference Model can maintain a relation that contains the role dominance relationships that have been added and update this relation when there is hierarchical changes in roles. The standard can take up the notion of private roles in RBAC role hierarchies. Secondly, inheritable and non inheritable permissions should be taken into account to help resolve which permissions are deem for inheritance by transitivity or not. Different organizational structure demands different solution to RBAC's role hierarchies but downwards delegation of powers either by grant or transfer via RBAC hierarchy based on task would be desirable.

3


Date : 26/10/10


Version : 1.0


Potential extensions to address limited expressiveness

[No Usage Control:] In UCONABC[1], The UCON model considers this temporal and consumed attributes as the mutable attributes of subjects or objects. The UCON model has unified traditional access control models and temporal access models with its ABC (Authorizations, Obligations and Conditions) core models.In TUCON[2], a further work on both temporal and consumable authorisation was modelled to address the issue of privilege consuming usage of digital objects in the global context. It extends the traditional usage control models with a temporal constraint. In terms of usage of a digital object three attributes are required for authorisation in TUCON policy representation:(1) Time Interval (2) Valid Period (3) Usage times[2]Time Interval: It includes the starting and the ending time.Valid Period: An access to a resource is allowed during the valid period of usage.Usage Times: It is the maximum time an access to the object is prohibited and revocation is carried out automatically by the system.TUCON carries out revocation on when (1) the time interval of authorisation has expired and (2) the usage times is zero during the ongoing usage of digital objects.TUCON can introduce temporal usage constraints into RBAC to address the issue of usage control in general. It would allow RBAC to also express time-based authorisations. A times authorisation is a 6-tuple. For example, an assertion( 6, James, Sun, read, +, Bob) means that Bob authorizes 6 times privilege read on the book Sun to James.

[Limited Status Control:] In S. Barker et al[3], a distributed access control model based on status was modelled to address the issue of the one-type ascribed status and static access policies introduced as a bottleneck because of the centralised environment. The modelled status-based access control for distributed access control is called SBAC. It has a notion of an action status and an ascribed status([3], page 1). The action status is

captured through a history of events in relation to the user (requester). This history enables changing access policy requirements to be naturally resolved in a distributed environment([3], p. 1). Barker points out an idea to status levels that are assigned to agents that request access to system resources (henceforth these agents are referred to as requester agents).These status levels change dynamically in response to the actions the requester agent performs[3]. Clearly SBAC can be introduced into the RBAC standard as an extension and to confront the problems that the standard failed to address. SBAC is a formal, well defined model and provides a basis for proving access control properties that satisfies SBAC policy specification. It supports meta-policy specification and provides sanctioning in the form of automated penalization by action demotion.

[Time and Triggered(Event-based) access:] In TRBACN[6] an approach based on ura and pra specification can be use to model and introduce a temporal constraint into RBAC as an extension. TRBACN claims that to specify a time interval for which ura or rpa predicate holds, a conjunction of linear constraints of time variable, T is used. Illustratively, if a User, U is assigned to a role, R from a point in time 20091212 (YYYMMDD) until some point in the future 20091218 then TRBACN

will specify this using ura predicate with the T conjunction as:ura(u, r, T) <-- 20091212<= T, T <= 20091218.Conversely to represent that a role, r has all the permissions P on a resource, books from 20091112 to some point 20091201 in the future can be represented by rpa predicate as:rpa(r, P, books, T) <-- 20091112<=T, T<=20091201.RBAC's role hierarchy is represented with a senior-to and d-s relation. A role R1 in the senior-to relation with role R2 represented as senior-to(R1,R2) means that R2 inherits all the permissions of R1. A static policy specification is rarely common which lead TRBACN to resolve this problem. In TRBACN , user-role assignment and permission-role assignments are revoked by physical deletion of the appropriate

4


Date : 26/10/10


Version : 1.0

©2010 All Rights Reserved.O

VE

RV

IEW

OF R

BA

C

definitions of ura(U, R, T) and rpa(R, P, O, T) from an instance of TRBACN theory.For audit purposes, it is quite necessary for some actions by certain privilege users to be tracked like revocation of roles in TRBACN. TRBACN used the terminated(A,T)1 predicate to keep history of the revocation of ura or rpa assignments. ([7], p.184)For example, James assignment to a role R is revoked on 20091113 then the ura(James,R,T)

clause defined is removed physically and the assertion terminated(ura(James,R),20091113) is added. On the other hand, a read permission on an object, o1 assigned to a role, r1 is revoked on 20091218 will be added as an assertion terminated(rpa(r1,read,o1),20091218).Clearly, TRBACN seems as the right recipe to solve temporal problems in the standard RBAC because of its clarity and simplicity as compared to other temporal models.

In DEBAC[9], a formal policy representation was modelled to address the issues of dynamic and distributed information systems using term rewrite systems. DEBAC is based fundamentally on the notion of events which makes it more suitable for autonomous changing context.In DEBAC, Bertolissi et al[9] defined an access to a resource as:

DEBAC supports the notion of role hierarchy in RBAC as a hierarchy of categorisation in which the privileges of a category can be inherited by another category via category hierarchy. DEBAC accommodates the notion of RBAC separation of duties constraint as categories assigned to a user cannot be mutually exclusive. DEBAC claims sound as a good enhancement to the ANSI RBAC model to address dynamic and distributed requirements of

1 In terminated(A,T), A is the ura or rpa assignments and T is the time of revocation of the ura or rpa assignment.

some computational context.

4 Conclusion

n this report, I explored Role Based Access Control to the extent of its limitations but more

importantly the enhancements made to rectify these limitations.

IAccess control or authorization, in its broadest sense - has existed as a concept for as long as humans have had assets worth protecting. In today’s information technology, authorization is concerned with the ways in which users can access resources in the computer system, or informally speaking, with "who can do what?", “when to do what?” and “why you did what?”.

5 References[1] Park, J. AND Sandhu, R. 2004. The UCONABC

Usage Control Model.[2] B. Zhao, R. Sandhu, X. Zhang AND X. Qin 2007.Towards a Time-Based Usage Control Model.[3] Barker, S. ,Majek J. Sergot AND Duminda Wijesekera 2008. Status-Based Access Control.[4] S. H. Park,Y. J. Han AND T. M. ChungS.-H. 2006. Context-Role Based Access Control.[5] S. Barker : Distributed Access Control: A Logic-Based Approach. V. Gorodetsky et al. (Eds.) MMM-ACNS 2003, LNCS 2776, pp. 217–228, 2003.c Springer-Verlag Berlin Heidelberg 2003[6] S. Barker: TRBACN: A Temporal Authorization Model. V.I. Gorodetski et al. (Eds.): MMM-ACNS 2001, LNCS 2052, pp. 178– 188, 2001.[7] Sandhu, R.: Role Hierarchies and Constraints for Lattice-Based Access Controls.In: European Symposium on Research in Security and Privacy (1996)[8] Lampson, B.W.: Protection. 5th Princeton Symposium on Information Science and Systems, 1971. Reprinted in ACM Operating Systems Review, 8(1), 18-24 (1974)[9] Clara Bertolissi, Maribel Fernandez, and Steve Barker. Dynamic Event-Based Access Control as Term Rewriting* 2007.

5


Date : 26/10/10


Version : 1.0


OV

ER

VIE

W O

F R

BA

C

“A user u Є U is permitted to perform an action a Є A on a resource r Є R that is located at site s Є S if and only if u is assigned to a category c Є C to which an access on r has been assigned.”

[10] Clara Bertolissi AND Maribel Fernández 2008. Time and Location based services with Access Control.[11] Sandhu, R. and Ferraiolo, D. and Kuhn, R.: The NIST Model for Role-Based Access Control: Towards a Unified Standard. Proc. 4th ACM Workshop on Role-Based Access Control (2000) 47–61[12] Sandhu, R., Park, J.: Usage Control: A Vision for Next Generation Access Control. In: Models and Architectures for Computer Networks Security. The Second International Workshopon Mathematical Methods (2003).[13] Indrakshi Ray, Mahendra Kumar, and Lijun Yu: LRBAC: A Location-Aware Role-Based Access Control Model A. Bagchi and V. Atluri (Eds.): ICISS 2006, LNCS 4332, pp. 147–161, 2006.

ABOUT THE AUTHOR

6


Date : 26/10/10


Version : 1.0


He holds MSc in Advanced Software Engineering from King's College London and BSc in Computer Engineering from KNUST. He specialises in Access Control and Privacy Policies, Distributed Systems, Software Architecture and Software Technology.

Investor Relations

Overview Of RBAC