What is Policy Based Access Control?

Policy-Based Access Control (PBAC) is an innovative authorization model that combines the advantages of Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), effectively addressing some of their inherent limitations. By integrating these approaches, PBAC enables organizations to establish more flexible, efficient, and manageable access control policies. At its core, PBAC focuses on expressing policies through assignment relationships, which can be visually represented and easily manipulated. This model facilitates a comprehensive depiction of access rights, ultimately enhancing security and simplifying resource administration across diverse organizational settings.

The cornerstone of PBAC is the expression of policies as assignment relationships that can be graphically visualized and manipulated. Access rights for performing operations on resources or objects are acquired through associations. PBAC allows for defining complex hierarchical relationships with inheritance, which is difficult to achieve in ABAC. As such, PBAC can be regarded as "relational ABAC," and is best suited for real-time enforcement of authorization decisions where a well-structured role model is available for policy assignment.

Inherently more efficient than ABAC policies, PBAC policies base authorization decisions on the net result of multiple policies related to existing relationships within a single database, rather than multiple computed and combined local decisions. This feature also enables PBAC to enforce dynamic Segregation of Duties (SOD) rules, unattainable with ABAC. Another notable aspect of PBAC is its support for "before the fact audit," allowing visibility into resource access at any time, not just during real-time policy set evaluation.

Figure 1 below demonstrates a PBAC policy granting Read, Edit, Print, and Delete permissions to Doctors' role members, with constraints similar to ABAC. These policy conditions require that the company is not in "Emergency Mode," users access information from the "internal" network, and utilize strong MFA authentication. The primary distinction between this PBAC policy and ABAC is the assignment to the Doctor role. Typically represented in a relational or graph database, this assignment offers auditors clarity on who granted it and, to some extent, the permissions granted to Doctor role members. The assignment is tangible, visible, and subject to periodic recertification. Additionally, it can be integrated into a self-service workflow process, allowing end-users to request access.

Figure 1: Information Technology – Next Generation Access Control – Functional Architecture (NGAC-FA)

In a real-world implementation of PBAC, acquiring the attribute data necessary for a comprehensive policy is a challenge similar to that faced in ABAC. A potential solution involves dividing the responsibility for making the final decision between the PBAC Policy Decision Point (PDP) and the application itself – a "Get Permissions" PBAC query. In this model, the application, or Policy Enforcement Point (PEP), is assumed to have access to some of the attribute data required for the policy decision. The PEP queries the PDP, asking if the user is authorized to perform a specific action or operation. The PBAC PDP then returns a partial answer: "No" if no policy assignments authorize the action for the user or their roles; "Yes" if there are policies granting the user permission, but with a list of conditions or constraints under which the action is allowed. In this model, it is the PEP's responsibility to enforce the remainder of the decision, assuming it has access to the data necessary to evaluate the condition constraints.

Continuing with our example in Figure 2 below, Dr. Alice attempts to view Bob's X-Ray. The application/PEP asks the PDP if this action should be allowed. The PDP searches its PBAC policy store and finds one assignment granting Doctors this permission and another assignment where Alice is assigned to the Doctors role. In the PBAC assignment for Doctors granting the "View" permission, constraint conditions are defined. The PDP returns a partial "Yes" decision to the caller, including the conditions. The application/PEP must then look up the required attribute information and make a complete decision.

Figure 2: Example of a PBAC Get Permissions Decision

Another approach to evaluating PBAC decisions is what EmpowerID calls an "Access Check" query. This model is commonly used when policies are not overly complex and rely on information easily accessible by the application or an application gateway acting as the PEP. As illustrated in Figure 3 below, the application or PEP has all the necessary information required for policy evaluation and sends it to the PDP as part of the query. The application/PEP then asks the PDP if Alice can "View" Bob's X-Ray, and because this request includes some pre-arranged information, the PDP evaluates it against its policies. If the PDP identifies a PBAC policy assignment applicable to Alice or one of her roles authorizing this permission, it will first evaluate the additional information to ensure that conditions are met. If the conditions are satisfied, the PDP will return a "Yes" answer.

Figure 3: Example of a Full PBAC Access Check

EmpowerID Admin Guide v24.R1

What is Policy Based Access Control?

See Also