- RBAC defines what *roles* users can assume in a *session* and what *permissions* are given to those roles. - A *Policy* defines what roles can be activated for a given user ![[attachments/Pasted image 20230616135237.png]] ### RBAC details - $U =$ set of users, $R =$ set of roles, $P =$ set of permissions, and $S =$ set of sessions - Policy defined by the following relations - $PA ⊆ R \times P$ (Permission Assignment) → What can each role do - $UA ⊆ U \times R$ (User role Assignment) → What roles can users take on - At execution time - User: $S$ → $U$, each session has a user - Roles: $S$ → $2^R$, some subset of roles is activated - Session $s$ roles: $roles(s) ⊆ \{ r ∣ (user(s),r) ∈ UA\}$ - Session $s$ permissions$= ∪ \{p ∣ (p,r) ∈ PA\} \forall r ∈ roles(s).r$ ### RBAC hierarchy The simple structure where each user has roles, which contain permissions can be called as **RBAC0**. The next version, or **RBAC1** allows role hierarchies. Example: A primary care doctor is also a doctor, and all doctors are healthcare professionals. ### RBAC Implementation There are three services involved in this implementation. - [[Authentication methods|Authentication]] service authenticates users. - **Role activation service** allows the process running on behalf of the authenticated users to activate allowed/requested roles. - **Authorization service** grants or denies access based on currently active roles. #### Roles v/s groups - Roles → Sets of users who perform a certain function. Roles have an associated set of permissions. - Groups → Sets of users but the membership says nothing about the permissions. - Roles can be activated or deactivated, groups cannot. - Permissions for a role are known from a policy file but there is no single place that defines a group’s permissions (except, perhaps, the [[Access control matrix|ACM]]). ### Benefits of RBAC Policy files can be smaller and more concise with RBAC. - Suppose that, - $U$ = number of roles - $R$ = number of roles - $O$ = number of objects - Without RBAC, the ACM is a sparse matrix of size $(U.O)$ - If all permissions are assigned through RBAC then we use the previously discussed Permission Assignment ($PA$) and the User role Assignment ($UA$). So the size of the policy file is the sum of the size of $PA$ and $UA$. $\therefore$ Policy file size for RBAC = $UA + PA = U.R + R.O = R.(U+O)$ - For small $R$, the size is almost equal to $(U+O)$. $R.(U+O) \lt U.O$