RBAC Model Taxonomy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
 
## Core RBAC



- Consists of `users`, `roles`, and `permissions`, which are `operations` applied to `objects`.
- Permissions are associated with roles. 
- Users are members of roles. 



- Permissions are assigned to roles
- Simplifying the understanding and management of permissions. 	
- Access requirements to resources are performed at the same level 
of abstractions as typical business processes in an enterprise:
  - role: teller, loan officer, doctor, nurse ...
  - operation: withdraw cash, deposit cash, write prescription, draw blood test



- Reflect higher-level organizational policy	
- Mutually exclusive roles
- Cardinality: maximum numbers with respect to role	
- Pre-requisite:
  - can	assign	role	only if	already	assigned	prerequisite	role
  - Not hierarchical 



- Properties and mappings in RBAC can be divided into static 
and dynamic components. 
- Dynamic components of RBAC includes role activation and subject access. 
  - Dynamic mapping of subject to user
  - Dynamic mapping of user to active role set. 



- Privileges are system-specific and permissions are mapped into privileges. 
- Uses and roles can have common meaning across multiple systems. 

:::{image} ../fig/csc603/09-core-rbac/privilege-association.png
:alt: User-roles and role-privilege associations
:class: bg-primary mb-1
:height: 500px
:align: center
:::

- The relationship between roles and permissions depends on the scope on which 
RBAC is implemented. 
  - RBAC implemented within an operating system: integration with users/groups/operations 
  and resources of the computer system. 
  - For distributed systems: RBAC needs to be implemented at the LDAP/server level to support 
  SSO/Shibboleth Authentication. 

:::{image} ../fig/csc603/09-core-rbac/global-local-mapping.png
:alt: Mapping global users and roles to local user accounts, groups, and privileges
:class: bg-primary mb-1
:height: 500px
:align: center
:::

- First step for enterprise-level RBAC
  - Create and maintain direct associations between RBAC users and local user IDs. 
  - Local resources are protected via local users IDs and groups. 
- Operations and resources are created as abstractions.   

:::{image} ../fig/csc603/09-core-rbac/system-level-mapping.png
:alt: Mapping abstract permissions
:class: bg-primary mb-1
:height: 500px
:align: center
:::


 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
 

## Separation of Duty and RBAC Constraints


- Separation of Duty (SoD) is a fundamental principle in security systems. 
- Critical operations are divided among two or more people, so that no single
individual can compromise security. 



- Two broad categories: static and dynamic
  - Distinguish by the time at which the role constraints are applied. 
  - Static SoD places constraints at the time users are authorized for roles. 
  - Dynamic SoD constraints are applied when users are using the system. 



- Enforce assignment of users to roles. 
  - If a user is assigned to one role, they cannot be member of another role. 
  - In the presence of a hierarchy, inherited roles are also considered when enforcing constraints. 
  - For example, a billing clerk role cannot also be a account receivable clerk role. 

:::{image} ../fig/csc603/09-core-rbac/static-sod.png
:alt: Example Stanford model
:class: bg-primary mb-1
:height: 400px
:align: center
:::




- Users maybe authorized for roles with conflict, but limitations are imposed when the user is logged on to 
the system. 
  - Timely revocation of trust. 
  - Can still create policy concerns. 
  - Need extensive system support. 




- Most RBAC systems available today support role hierarchies
  - Property 1: Two roles $R_i$ and $R_j$ can be mutually exclusive only if neither
  one inherits the other, either directly or indirectly. 
  - Property 2: If there are two roles $R_i$ and $R_j$ that are mutually exclusive, 
  then there can be no third role that inherits both of them. As with property 1, this 
  property must be handled properly by role management tools to allow administrators 
  to set up role hierarchies that do not violate SoD constraints. 
  - Property 3: If static SoD holds, then DSD is maintained. Clearly, if a user 
  is only authorized for one of two roles, then he or she can never be 
  active in both. 
  - Property 4: If there are any two roles $R_i$ and $R_j$ that are mutually 
  exclusive, then there can be no `root` or `superuser` role active on the 
  system. 
- Mutual exclusion is used to enforce SoD policies. 
  - Exclusion specified by sets (membership in one set preclude membership in others)
  - Exclusion specified by role-pair (potentially computationally intensive)
- Assigning roles to users
  - Roles must be assigned in such away that no user can violate SoD rules through 
  a combination of roles. 
    - No single user posesses all privileges needed to accomplish a task controled 
    under SoD. 
    - Govem a set of roles and relationships, what is the minimal number of users 
    required to ensure SoD?



- Incorporate the notion of time in specifying access control requirements
  - To limit resource usage in workflow environment
  - To limit role availability and activation capability
- Taxonomy
  - Temporal constraints on roles
  - Temporal constraints on user-role assignments
  - Temporal constraints on role-permission assignments
- Time-related concepts
  - Periodicity
  - Duration
- Constraints
  - Role-enabling and disabling constraints (e.g. enable role doctor-on-call for specific doctors)
  - Role-activation and deactivation constraints (e.g. duration available for download)
  - Role-permission assignments constraints (e.g., hire John Smith as contractor between Sep and Dec)
- Supporting requirements must also be enabled to support temporal constraints.