Role-Based Control Access Models

1. Role-Based Control Access Models Pavicevic Aleksandar CS 585 – Computer Security

2. History • In the 1970s, computer systems featured multiple applications and served multiple users, leading to heightened awareness of data security issues. • Differnet kinds of access control have been used • One of them is role-based access control (RBAC)

3. RBAC • A role is a semantic construct forming the basis of access controlpolicy. • With RBAC, system administrators create roles according tothe job functions performed in a company or organization, grant permissions(access authorization) to those roles, and then assign users to those roles on the basis of their specific job responsibilities and qualification

4. Roles • A role can represent specific task competency (physician, pharmacist) • A role can embody the authority and responsibility • Authority and responsibility are distinct fromcompetency, however. Aperson may be competent to manage several departments, but has the authority and responsibility for only the department it actually manages • Roles define both the specific individuals allowed to access resourcesand the extent to which resources are accessed

5. Roles(cont’d) • The particular combination of users and permissions brought togetherby a role tend to change over time. • The permissions associated with a role,on the other hand, are more stable; they tend to change less often thanthe people who fill the job function that role represents. • Basing security administration on roles rather than on permissions is simpler - users can be easilyreassigned to different roles as needs change. • Similarly,as a company acquires new applications and systems, roles can have newpermissions granted and existing permissions revoked.

6. Why RBAC? • Renewed interest in RBAC has focused on general supportat the application level. • Traditionally, specific applicationshave had to encode RBAC internally, with existingoperating systems and environments offering little application-level MAC support • Started to change, but the challenge is to identify sufficiently flexible but“easy-to-use” “application-independent” facilities to supportmany applications with minimal customization • No agreement yet as to what is RBAC – still open to interpretation

7. Relations • Sophisticated variations of RBAC include thecapability to establish relations between roles, betweenpermissions and roles, and between users and roles • Roles can also acquire inheritance relations, whereby one roleinherits permissions assigned to a different role. Theserole-role relations can enforce security policies, includingseparation of duties and delegation of authority.

8. With RBAC, role-permission relationships can be predefined,which makes it simple to assign users to the predefinedroles • The NIST study(National Institute of Standards and Technology) indicates that permissionsassigned to rolestend to change relatively slowly

9. Access control policy is embodied in RBAC componentssuch as role-permission, user-role, and role-role relationships. • These components collectively determine whethera particular user is allowed access to a certain piece of system data. • Because the access control policy canchange over the system life cycle, RBACoffers a key benefit through the ability to modify access controlto meet changing organizational needs

10. Although the RBAC concept is policy neutral, it directlysupports three well-known security principles: • Least privilege: Only those permissions required forthe tasks performed by the user in the role are assigned to the role. • Separation ofduties: Invocation of mutually exclusiveroles can be required to complete a sensitive task • Data abstraction: Instead of the read, write, executepermissions typically provided by the operating system, abstract permissions, such as credit and debitfor an account object, can be established

11. Note that: • RBAC cannot enforce the way these principlesare applied. Theoretically, a system administratorcould configure RBAC to violate these principles. Thedegree to which data abstraction is supported will bedetermined by the implementation details • RBAC is not an universal solution for all access control issues, but other forms of access control can belayered on top of RBAC to deal with situations that RBAC can’t solve by itself

12. Groups/Roles • Many access control systems provide groupsof users as the access control unit. • A major differencebetween groups and roles is that groups are typicallytreated as a collection of users but not as a collection ofpermissions. A role, serving as an intermediary, is both acollection of users and a collection of permissions

13. For a system to have a real RBAC in use: • it should be roughlyas easyto determine role membership as role permissions • control of role membership and role permissions should berelatively centralized in a few users • Many mechanisms claiming to be role based have neither of these characteristics

14. RBAC-DAC or MAC? • The answer to this question depends on howthe terms are defined and on the nature and configurationof permissions, roles, and users in an RBAC system • Mandatory means that individual usershave no choice regarding which permissions or users are assigned to a role • Discretionary signifies that individual users make these decisions • RBAC is policy neutral by itself • Individual RBAC configurationscan support a mandatory policy, while others can support a discretionary policy.

15. Example Model

16. Figure (a) shows the model relationships and Figure (b) portrays their essentialcharacteristics. • RBAC0 as the base model at the bottom,is the minimum requirement for an RBAC system. • Advanced models RBAC1 and RBAC2 include RBAC0, butRBAC1 adds role hierarchies (situations where roles caninherit permissions from other roles), whereas RBAC2 adds constraints (which impose restrictions on acceptable configurations of the different components of RBAC). • RBAC1and RBAC2 are incomparable to one another. The consolidatedmodel, RBAC3 includes RBAC1 and RBAC2, and, by transitivity, RBAC0

17. Base Model – RBAC0 • In Figure (b), the base model RBAC0 consists of everythingexcept role hierarchies and constraints. Four entitiesare shown: users (U), roles (R), permissions (P), and sessions (S). • For simplicity in the model, user isa human being. A role is a named job function within theorganization that describes the authority and responsibilityconferred on a member of the role.

18. Base Model – RBAC0 (cont’d) • Apermission is an approval of a particularmode of access to one or more objects in the system (authorization, access right, privilege) • Permissionsare always positive and confer on their holder the abilityto perform an action in the system. • Some access control literature discusses negative permissions, which deny rather than confer access. Access denial is considered to be a constraint rather than a negative permission.

19. Base Model – RBAC0 (cont’d) • Figure (b) shows user assignment (UA) and permissionassignment (PA) relations; both are many-to-many andboth are key to RBAC. • A user can belong to many roles,and a role can have many users. Similarly, a role can havemany permissions, and the same permission can beassigned to many roles. Ultimately, the user exercises permissions. • The role’s position is to let a user exercise a permission • This provides greater control over access configuration and review than a direct relationship between users and permissions.

20. Base Model – RBAC0 (cont’d) • Users establish sessions during which theymay activate a subset of the roles they belong to. Each sessionmaps one user to possibly many roles • The permissionsavailable to the user are the union of permissionsfrom all roles activated in that session.Each session is associatedwith a single user • This associationremains constant for a session’s duration

21. Base Model – RBAC0 (cont’d) • Each role would likely be assigned at least one permission, and each use at least one role(not required by the model) • Sessions are under the control of individual users. Asfar as the model is concerned, a user can create a sessionand choose to activate some subset of his roles

22. Role hierarchies – RBAC1 • RBAC1 introduces roIe hierarchies (RH) • Role hierarchies are commonly implemented in systems that provide roles. • Hierarchies are a natural means for structuring roles toreflect an organization’s lines of authority and responsibility • Mathematically, hierarchies are partial orders. Apartial order is a reflexive, transitive, and anti-symmetricrelation (RAT)

23. Role hierarchies – RBAC1 (cont’d) • A user can establish a session with any combination ofroles junior to the user’s own roles. • The permissionsin a session are those directly assigned to the session’sroles plus those assigned to junior roles

24. Role hierarchies – RBAC1 (cont’d) – Limited Inheritence • Sometimes it is useful to limit the scope of inheritance • This is done by assigning a private role to an existing role in the system • Private roles are achieved in some systems by blockingupward inheritance of certain permissions, but this techniqueprevents the hierarchy from accurately depicting permissiondistribution. • It is better to introduce privateroles and keep the hierarchical role relationship intact.

25. Role hierarchies – RBAC1 (cont’d) – Private Subhierarchy - Model

26. Role hierarchies – RBAC1 (cont’d) – Private Subhierarchy • Role T1’ in Figure (b) is aprivate role for members of task T1. Suppose the subprojectof Figure (a) comprising roles S3, T3, T4, and P3requires a private sub-hierarchy within which private permissionsof the project are shared without inheritance byS • The entire sub-hierarchy is replicated as shown in Figure (b). The permissions inheritable by S are assigned to S3, T3, T4, and P3, while the private onesare assigned to S3 ‘, T3 ‘, T4 ‘, and P3 ‘, allowing theirinheritance within the subproject only • As before, membersof the subproject team are directly assigned to S3 ’, T3 ’, T4’, or P3 ’ .

27. Constraints model-RBAC2 • Constraints are an important aspect of RBAC and aresometimes argued to be the principal motivation behindRBAC • A common example is that of mutually disjointorganizational roles - the same individualis not permitted to belong to both roles, becausethis creates a possibility for committing fraud - separation of duties

28. Constraints model-RBAC2(cont’d) • Constraints are a powerful mechanism for laying outhigher level organizational policy. Once certain roles aredeclared mutually exclusive, there’s less concern aboutassigning individual users to roles

29. Constraints model-RBAC2(cont’d) • As long as RBAC‘S management is centralized in a singlesystem administrator, constraints are simply a convenience,because the same effect could be achieved bycautionon the part of the system administrator • If RBAC management is decentralized, however, constraints becomea mechanism by which senior system administrators canrestrict users’ ability to exercise administrative privileges

30. Constraints model-RBAC2(cont’d) • Constraints can apply to the UAand PA relations and the user and roles functions for sessions • When applied, constraints are predicates that return a value of “acceptable” or “not acceptable.” • Constraints are better viewed according totheir kind and nature

31. Constraints model-RBAC2(cont’d) – Mutually exclusive roles • The most common RBACconstraint is mutually exclusive roles • This supports separation of duties, which is furtherensured by a mutual exclusion constraint on permission assignment. • The dual constraint on permission assignment can provideadditional assurance for separation of duties.It requires that the same permission is assignedto at most one role in a mutually exclusive set

32. Constraints model-RBAC2(cont’d) – Mutually exclusive roles • Various combinations of roles can beprohibited. For example, a user might belong to both aprogrammer role and a tester role on different projects,but within the same project this would be unacceptable.

33. Constraints model-RBAC2(cont’d) – Cardinality • Another user assignment constraint is amaximum number of members in a role. Only one personcan fill the role of department chair • Similarly, the numberof roles an individual user can belong to could also belimited • These are cardinality constraints, which can beapplied to permission assignment to controlthe distribution of powerful permissions. • Minimum cardinality constraints may be difficultto implement • Eg. if a role requires a minimumnumber of members, it would be difficult for thesystem to know if one of the members “disappeared” and to respond appropriately

34. Constraints model-RBAC2(cont’d) – Prerequisite roles • The concept of prerequisite roles is based on competency and appropriateness, where auser can be assigned to role A only if the user already is assigned to role B • Only users who are already assigned to the project role can be assigned to the testing role in that project

35. Constraints model-RBAC2(cont’d) – Other considerations • User assignment constraints are effective only if suitable external discipline is maintainedin assigning user identifiers to human beings - if thesame individual is assigned two or more user identifiers,separation and cardinality controls break down • The situation with permission constraintsis similar - if the same operation is sanctioned bytwo different permissions, the RBAC system cannot effectivelyenforce cardinality and separation constraints

36. Constraints model-RBAC2(cont’d) – Other considerations • Constraints also apply to sessions and to the user androles functions associated with a session. A user maybelong to two roles but cannot be active in both at the sametime • Other session constraints limit the number of sessions auser can have active at the same time - the number of sessions to which a permission is assigned can be limited

37. Consolidated model-RBAC3 • RBAC3 provides both role hierarchies and constraints,as it combines RBAC1 and RBAC2. Combining both concepts raises several issues

38. Consolidated model-RBAC3(cont’d) – Constraints on role hierarchies • Constraints can apply to the role hierarchy itself • The role hierarchy mustbe a partial order • Additional constraints can limit the number, if any, ofsenior or junior roles that a given role may have • Two ormore roles can also be constrained to have no common senior (or junior) role.

39. Consolidated model-RBAC3(cont’d) – Interactions • Interesting interactions arise between constraints and hierarchies. • Suppose that two roles (with a common senior role) are declared mutually exclusive. The senior role violatesthis mutual exclusion constraint • Such a violation by asenior role may or may not be acceptable. The modelshould therefore accommodate both possibilities

40. Consolidated model-RBAC3(cont’d) – Private roles • Two private roles(whose roles have a common senior role) can be declared mutually exclusive, and because these have no commonsenior role, there’s no conflict • In general, private roles willnot share common seniors with other roles – they canbe mutually exclusive without causing conflict

41. Issues in role administration • So far it is assumed that all RBAC componentsare directly controlled by a single system administrator • In large systems the number of roles canexceed hundreds or thousands. Managing these roles andtheir interrelationships is a difficult task - oftenhighly centralized and delegated to a small team of securityadministrators • Because RBAC‘s key advantage is thatit simplifies permission administration, the next step is tosee how RBAC might be used to manage itself • The use of RBAC to aid in managing RBAC could be adecisive factor in it‘s overall success

42. Issues in role administration (cont’d)– managment model

43. Issues in role administration • Manyresearch problems must be solved if RBAC’s potentialis to be fulfilled • One is to develop a systematicapproach to RBAC configuration design and analysis • Another problem is the lack of information about constraints withrespect to RBAC • Also lacking is a formal notation forstating and enforcing constraints, along with some measureof enforcement difficulty • Many of the open issues and problems are intertwinedand require an integrated approach to be resolved