Policy-Based Access Control (PBAC) is not a formally defined standard but rather describes an an innovative authorization model that combines the advantages of Role-Based Access Control (RBAC) and ABAC concepts and eliminates some of their shortcomings. The closest actual standard for the PBAC model would be Next Generation Access Control (NGAC). NGAC is a relatively new standard authored by the NIST and was created to solve some of the complexities and limitations inherent in the XACML standard while maintaining its flexible and expressive nature.The key concept behind PBAC and NGAC, is that policies are expressed 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 graphically. Access rights to perform for performing operations against on resources or objects are acquired through relationships referred to as associations. This includes the ability to define PBAC allows for defining complex hierarchical relationships with inheritance, which is overly cumbersome difficult to achieve in ABAC. One might consider PBAC as “relational ABAC.” PBAC is best used As such, PBAC can be regarded as "relational ABAC," and is best suited for real-time enforcement of authorization decisions where a well-developed structured role model can be leveraged is available for policy assignment.
PBAC policies are inherently Inherently more efficient than ABAC policies because , PBAC policies base authorization decisions are not based on multiple computed and then combined local decisions. Instead, they are based on the net result of multiple policies based on related to existing relationships existing within a single database, rather than multiple computed and combined local decisions. This aspect feature also allows enables PBAC to enforce dynamic Segregation of Duties (SOD) rules, which are not entirely achievable unattainable with ABAC. A last key feature mentioned is PBAC support for “before Another notable aspect of PBAC is its support for "before the fact audit,” which is the ability to see who has access to a resource " allowing visibility into resource access at any time, and not just during the real-time evaluation of a policy set evaluation.
Figure 1 below illustrates demonstrates a PBAC policy that grants the granting Read, Edit, Print, and Delete permissions to the Doctors’ Doctors' role members, with some constraints similar to ABAC style constraints. These constraints or policy conditions are require that the company cannot be in “Emergency Mode,” the user must be accessing is not in "Emergency Mode," users access information from the “internal” "internal" network, and using utilize strong MFA authentication. The main difference primary distinction between this PBAC policy and ABAC is that the policy is assigned assignment to the Doctor role. This assignment would typically be Typically represented in a relation relational or graph database giving auditors a clear picture of who granted the assignment and a least a partial answer concerning what permissions members of the Doctor have been granted, 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, tangible, and can be recertified periodically. Furthermore, it could also be added to and subject to periodic recertification. Additionally, it can be integrated into a self-service workflow process where , allowing end-users could to request itaccess.
...
...
Figure 1: Information Technology – Next Generation Access Control – Functional Architecture (NGAC-FA)
In an actual a real-world implementation of PBAC, the challenge of where to acquire acquiring the attribute data used in necessary for a rich comprehensive policy is the same as that with ABAC. One possible solution is to split 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” itself – a "Get Permissions" PBAC query. In this model, it is assumed that the application, or Policy Enforcement Point (PEP), has is assumed to have access to some of the attribute data required for the policy decision. The application, or PEP, would query the Policy Decision Point (PDP) PEP queries the PDP, asking if the user is authorized to perform a particular specific action or operation. The PBAC PDP would then return returns a partial answer that would be : "No" if there were no policy assignments either to authorize the action for the user or their roles that authorized this action. However, ; "Yes" if there were are policies that granted granting the user this permission, then the PBAC response would Yes, but with a list of the conditions or constraints under which the action could be permittedis allowed. In this model, and 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, it is the PEP's responsibility to enforce the rest of the decision.
Continuing with our example in Figure 2 below, Dr. Alice attempts to View Bob’s view Bob's X-Ray. The application/PEP asks the PDP if this action should be allowed. The PDP then looks within searches its PBAC policy store and locates finds one assignment that grants granting Doctors this permission and one another assignment where Alice has been is assigned to the Doctors role. In the PBAC assignment for Doctors granting the "View" permission, there are constraint conditions are defined. The PDP returns a partial "Yes" decision to the caller, which will include including the conditions. The application/PEP must then lookup look up the needed required attribute information and make a full complete decision.
Figure 2: Example of a PBAC Get Permissions Decision
Another model for approach to evaluating PBAC decisions is what EmpowerID terms an “Access Check” calls an "Access Check" query. This model is common where the commonly used when policies are not overly complex and will rely on information easily accessible to by the application or by an application gateway acting as the PEP. As shown 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 "View" Bob's X-Ray but, and because this request includes some pre-arranged information, the PDP evaluates this it against its policies. If the PDP finds identifies a PBAC policy assignment applicable to Alice or one of her roles authorizing this permission. In that case, it will first evaluate the additional information to verify ensure that conditions are met and, if they are, then return a Yes . If the conditions are satisfied, the PDP will return a "Yes" answer.
...
Figure 3: Example of a Full PBAC Access Check
...
See Also
Create PBAC Membership Policies
What is Role Based Access Control?
...