RBAC
RBAC
In Role-Based Access Control, roles are an intermediate layer between users and the permissions to
execute certain operations.
Operations can be well-formed transactions with built-in integrity checks that actually mediate the
access to protected objects or resources. Then, users are assigned roles and are made authorised to
execute the operations linked to their active role.
Separation of Duties (SoD) refers to policies that stop single users from becoming too powerful.
Examples for SoD are:
@) rules stating that more than one user must be involved to complete some transaction,
@) rules stating that a user permitted to perform one set of transactions is not permitted to perform
some other set of transactions,
@) the separation between front office and back office in financial trading firms is an example, or
@) rules stating that policy administrators may not assign permissions to themselves.
Static SoD rules are considered during user-role assignment, dynamic SoD must be enforced when a role
is activated.
• Flat RBAC: users are assigned to roles and roles to permissions to operations; users get permissions to
execute procedures via role membership; user-role reviews are supported.
• Symmetric RBAC: adds support for permission-role reviews, which may be difficult to achieve in large
distributed systems.
Many commercial systems support some flavor of role-based access control, without necessarily
adhering to the formal specifications of RBAC published in the research literature. RBAC is an elegant
and intuitive concept, but may become quite messy in deployment as well.
Practitioners note that RBAC works as long as every user has only one role, or that “the enormous effort
required for designing the role structure and populating role data” constitutes an inhibitor for RBAC.
___________________________
Please click on the 'Follow' button 💛 on my Facebook page, to receive a Facebook notification when I
publish another live video!
___________________________
🙊🙉🙈
In Role-Based Access Control, roles are an intermediate layer between users and the permissions to
execute certain operations.
Operations can be well-formed transactions with built-in integrity checks that actually mediate the
access to protected objects or resources. Then, users are assigned roles and are made authorised to
execute the operations linked to their active role.
Separation of Duties (SoD) refers to policies that stop single users from becoming too powerful.
Examples for SoD are:
@) rules stating that more than one user must be involved to complete some transaction,
@) rules stating that a user permitted to perform one set of transactions is not permitted to perform
some other set of transactions,
@) the separation between front office and back office in financial trading firms is an example, or
@) rules stating that policy administrators may not assign permissions to themselves.
Static SoD rules are considered during user-role assignment, dynamic SoD must be enforced when a role
is activated.
• Flat RBAC: users are assigned to roles and roles to permissions to operations; users get permissions to
execute procedures via role membership; user-role reviews are supported.
• Symmetric RBAC: adds support for permission-role reviews, which may be difficult to achieve in large
distributed systems.
Many commercial systems support some flavor of role-based access control, without necessarily
adhering to the formal specifications of RBAC published in the research literature. RBAC is an elegant
and intuitive concept, but may become quite messy in deployment as well.
Practitioners note that RBAC works as long as every user has only one role, or that “the enormous effort
required for designing the role structure and populating role data” constitutes an inhibitor for RBAC.
___________________________
Please click on the 'Follow' button 💛 on my Facebook page, to receive a Facebook notification when I
publish another live video!
___________________________
🙊🙉🙈