Organization-Based Access Control (OrBAC)
Organization-Based Access Control (OBAC), also known as OrBAC, is an access control model that specifies security policies based on organizational context rather than traditional subject-action-object interactions. In order to manage many security policies at once, the organisation parameterises abstract concepts like roles, activities, and views, which enable policy makers to build rules utilising them. Because OBAC incorporates rights, prohibitions, and obligations that go beyond static permission models, it offers a more flexible and context-aware approach that is particularly helpful for complex domains like healthcare.
OrBAC’s main objective is to close the gap between low-level system enforcement (what the system can do) and high-level, human-readable security rules (what the organisation wishes to accomplish).
Also Read About Principle Of Least Privilege Vs Zero Trust Key Difference
Core Concepts of OrBAC
By adding an abstract layer for policy definition, OrBAC accomplishes policy independence. A particular organisation defines the policy design in its entirety.
The concept uses abstract privileges derived from five major entities to establish security policies:
Organization (Org)
The main entity and the setting for the whole security policy is the organisation (Org). This level of policy definition makes it possible to administer several security policies linked to various entities at once. An organised group of active entities (subjects) performing roles is called an organisation.
Roles (Abstract Subjects)
Abstract subjects, such as users or other organisations, are abstracted into roles. A group of subjects to which the same security regulations apply is represented by a role. For instance, a policy does not apply to the user; rather, it relates to the roles of doctor or auditor.
Activities (Abstract Actions)
Low-level system commands or operations are abstracted by activities (abstract actions). According to the organization’s policy, an activity is a collection of acts that have the same meaning. The same physical action may be classified as a separate activity by different organisations. For instance, the Write to Patient Record activity may correspond to low-level system operations such as POST MESSAGE on a communications service, SAVE FILE on the application server, and SQL UPDATE in the database.
Views (Abstract Objects)
Abstractions of resources or objects, such as files or database tables, are called views. A collection of objects to which the same security rule applies is called a view. For instance, the View of Medical Records may correspond to information kept in a secure cloud container, an XML file, or a particular database table.
Contexts
OrBAC is context-sensitive by nature. Contexts outline the specific conditions (time, place, urgency, etc.) in which privileges are bestowed.
A tuple comprising these primary entities Role, Activity, View, and Context is referred to as an abstract privilege.
Also Read About How ABACs Work & Attribute Based Access Control Components
How does OrBAC work?
The OrBAC model is a two-level framework that distinguishes between the formulation and execution of policies:
The Policy Definition at the Abstract Level:
Here, abstract concepts (Role, View, Activity, Context) are used to write security policies. Importantly, OrBAC expressly covers responsibilities (mandates), recommendations, and prohibitions (denials) in addition to access (permissions).
At the Concrete Level (Policy Enforcement), abstract entities are mapped to the real computer system components. For example, administrators can attach a particular file (Object) to a view or a certain user (Subject) to a role by defining mapping rules. The system checks the policy by translating the concrete elements into their abstract counterparts when a user tries an activity.
Example of OrBAC
- Policy: During working hours, physicians are allowed to see patient files in the hospital organisation.
- Interpretation:
- Subject = Doctor (role)
- Action = View
- Object = Patient file
- Context = Working hours
- If Dr. Ramesh (subject) tries to view a patient’s file at 11 AM → Access Granted.
- If Dr. Ramesh tries at midnight, → Access Denied.
Depending on whether the subject is used in the role, the object is used in the view, the action is regarded as part of the activity, and the context is deemed true, a general axiom governs how abstract permissions are converted into concrete permissions (Is-permitted) for subjects, objects, and actions.
Advantages of OrBAC
OrBAC is thought to be adaptable and scalable, making it ideal for situations involving intricate, hierarchical rules or huge enterprises:
Policy Independence: Rather than focussing on system details, the security policy is stated in terms of organisational ideas (roles, activities, and views). This implies that only the low-level mapping rules need to be altered if the underlying system changes (for example, moving from a file server to a cloud database); the high-level security policy stays the same.
Context-Sensitivity: Like ABAC, OrBAC incorporates context (such as location and time) as a component of the abstract privilege, allowing it to be supported natively.
Clarity and Auditability: Policies are simpler for auditors, regulators, and non-technical management to comprehend and validate since they mirror the organization’s formal structure.
Support for Non-Permission Rules: Clearly illustrates Obligations (mandates) and Prohibitions (denials), which are required to adhere to rules such as Separation of Duties.
Also Read About Rule-Based Access Control RuBAC Advantages And Use Cases
Organization-Based Access Control in Practice (Label-Based Model)
To control access to particular data records and resources, some systems use a label-based implementation of Organization-Based Access Control (OBAC).
Defined labels, which stand for pertinent business distinctions (such as geographical regions or business units), are essential to its implementation.
- Mapping: These labels are applied to organizations and data records, and they are applied to users and resources.
- Access Rule: A data record can only be accessed by a user or resource if it includes all of the labels linked to at least one of the user’s designated organizations (i.e., the labels of the organisation must be a subset of the labels of the record).
- Enforcement: On particular data objects, this label enforcement serves as a filter. Organizations are given users, and by default, there is a “All Access” organisation whose members have unfettered access to all records, regardless of their labels.
To control complexity and reduce performance effect, this system needs to be carefully configured, which includes choosing the right organisations and labels and strategically determining which data objects need OBAC enforcement.