Week 7 - RBAC and ABAC Flashcards
RBAC
Role Based Access Control
RBAC model governs the access of a user to information through the roles to which the user is assigned
RBAC three primary entities
users, roles, permissions
Users are assigned roles, which have permissions consisting of operations and objects
Permissions consist of
Operations and objects
User-Role Relation
This type of relation is created due to assignment of users to roles
For example, usually a user is assigned only a single role while a role could be assigned to multiple users ….
Role-Permission Relation
This is the second primary relation in RBAC. Typically a role is assigned multiple permissions. Also a permission could be assigned to multiple roles. Hence theoretically, Role-Permission assignment relation is a many-to-many relation.
Permission in RBAC
one can see that that a permission entity itself is composed of a combination of operations on objects
Operate-CustomerAcct Permission
Oper-Object (Read, CustomerAcct)
Oper-Object (AddTrans, CustomerAcct)
Oper-Object (DeleteTrans, CustomerAcct)
Role Hierarchy
Roles can be organized as a hierarchy instead of a flat data.
By organizing the roles as a hierarchy, a role higher in the hierarchy can automatically inherit all permissions of the roles beneath it.
RBAC Model Relations
User-Role (, )
Role-Perm (, )
Inherited-Role (, )
RBAC Create Command
Create-User (Lee)
Create-Role (LoanOfficer)
Create-Permission (Operate-LoanAcct)
RBAC Add Role Command
Add-UserRole (Mike, Teller)
Drop-UserRole (Mike, Teller)
Would result in the following relation added to RBAC model
User-Role (Mike, Teller)
RBAC to add/drop role hierarchies
Add-InheritedRole (Customer-Rep, Teller)
Will result in
Inherited-Role (Customer-Rep, Teller)
RBAC add role permission
Add-RolePerm (Teller, Read-LoanAcct)
Drop-RolePerm(Customer-Rep, Operate-LoanAcct)
will result in
Role-Perm (Teller, Read-LoanAcct)
RBAC Advantages
Eliminates the need to assign permissions directly to the user
If a user’s job description or position changes, it is enough that the user is deleted from certain roles and assigned new roles that is appropriate to his/her new position.
If the permissions required for a given role changes, it is enough that permissions are added to or deleted from the corresponding role.
RBAC Disadvantages
In some instances, there may be too many roles defined to enable users to do some one-time or emergency operations with the result it results in a situation called role proliferation.
When there are too many roles, the administrators may not update the permission set properly with the result some users may have more permissions than what is needed to perform their role.
In some instances, when a user changes job, the role assignments may not be properly changed.
Attribute-based Access Control (ABAC)
In an ABAC model, as the name denotes, the access rights for a user or subject is based on the current values of attributes associated with subject, object and optionally environment as well.
ABAC model variables
there are logical expressions called rules built using the combination of attributes of a subject, object and environment.
The outcome of evaluating these logical expressions using the values of attributes current at the time decides whether the subject’s access request can be allowed or not.
ABAC Subject Attribute Examples
Assigned Identity (e.g., SSNO, Driver’s License number, Passport No)
Role (e.g., Accountant)
Age
Organization affiliation
Rank
Security Clearance etc
ABAC Object Attribute Examples
Based on the type of project (e.g., Capital Project, Maintenance Project)
Based on the type of application (e.g., Purchase-Order Application, Budgeting Application)
Security Classification (Top Secret, Secret etc)
Owning Department (e.g., Manufacturing, Marketing etc)
ABAC Environmental Attribute Examples
Time of the Day
Day of the Week
Threat Level
Network Segment (e.g., DMZ)
Components of a logical expression
Entity, Attribute, Value
Ex. Entity = Subject, Attribute = Role, Value = Teller
Distinguishing features of ABAC
The permissions are dynamic
The permissions have to be computed
Most widely deployed means of defining ABAC model
platform-neutral XML-based language called XACML.
XACML Specification primary sub-specifications
Structural and Syntax rules for encoding policies and rules – XACML Policy Language Structure
A functional architecture that presents the data flow for the entire authorization process.
XACML Policy Language Structure
An ABAC Model definition using XACML contains at the topmost level a definition of a single PolicySet.
A PolicySet in turn consists of one or more Policy elements.
A Policy element in turn consists of one or more Rules.
XACML Policy Set components
Target, the set of policies it contains and can also contain other policy sets (nested)
XACML Policy components
This contains a Target and a set of one or more Rules. A Target defines the scope of resources (objects) over which the policy applies
XACML Rules components
The Rules also contain a Target. In addition they contain a Effect and Conditions components. The semantics for Target is same as in PolicySet and Policy. Effect denotes whether it is a positive or negative permission. Conditions denote further restrictions on Target.
PDP
Policy Decision Point
The PDP is thus the core of the access decision engine performing key operations such as: parsing XACML Access Request, retrieving policies, obtaining additional attributes through PIP, evaluating policies and encoding the access decision response
- The PDP requests any additional Subject, Resource and Environment attribute values from the Context Handler.
- The PDP requests the PAP (or the repository where PAP has stored the policies for PDP access) for policies matching the request’s Target.
- The PDP evaluates the related (applicable) policies and returns the authorization decision, encoded as an XACML Response Context to the Context Handler.
PEP
Policy Enforcement Point
The PEP enforces the authorization decision (either allow or deny) and also fulfills the obligations (if any). In some instances the PEP is tightly integrated with the application to enable fine-grained authorization.
- The Access Requester sends an access request to PEP
- The PEP sends the access request to the Context Handler in its native request format optionally including attributes of the Subjects, Resource, and Environment..
PIP
Policy Information Point
- The PIP obtains the requested attributes from Subjects, Resource & Environment.
PAP
Policy Administration Point
- The PAP writes policies and policy sets and makes them available to PDP
- The PAP (or the policy repository manager) returns the requested policies.
CH
Context Handler
The Context Handler translates the XACML Response Context to the native response format of the PEP. The Context Handler returns the response to the PEP.
- The Context Handler constructs an XACML Request Context, optionally adds attributes, and sends it to PDP
- The Context Handler requests the attributes from PIP.
- The Context Handler forwards those attributes (and optionally the relevant Resource content) to PDP.
Memorize XACML Policy Language Structure
Policy Set contains Target, Policy, and PolicySet (nested)
Police contains Target and Rule
Rule contains Target, Effect (permit, deny), Conditions (Rule is satisfied if)
