Policy-Based Access Control (PBAC) is not a formally defined standard but rather describes an authorization model that combines 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.
“NGAC diverges from traditional approaches to access control in defining a generic architecture that is separate from any particular policy or type of policy. NGAC is not an extension of, or adaption of, any existing access control mechanism, but instead is a redefinition of access control in terms of a fundamental and reusable set of data abstractions and functions. NGAC provides a unifying framework capable without extension of supporting not only current many access control approaches, but also novel types of policy that have been conceived but never implemented due to the lack of a suitable enforcement mechanism.” [5]
The key concept behind PBAC and NGAC, is that policies are expressed as assignment relationships that can be visualized and manipulated graphically. Access rights to perform operations against resources or objects are acquired through relationships referred to as associations. This includes the ability to define complex hierarchical relationships with inheritance, which is overly cumbersome in ABAC. One might consider PBAC as “relational ABAC.” PBAC is best used for real-time enforcement of authorization decisions where a well-developed role model can be leveraged for policy assignment.
PBAC policies are inherently more efficient than ABAC policies because 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 relationships existing within a single database. This aspect also allows PBAC to enforce dynamic Segregation of Duties (SOD) rules, which are not entirely achievable with ABAC. A last key feature mentioned is PBAC support for “before the fact audit,” which is the ability to see who has access to a resource at any time, and not just during the real-time evaluation of a policy set.
PBAC and NGAC are similar and, for this paper and examining our model, we will use the more common term PBAC. In Figure 29 below, we have a PBAC policy that grants the Read, Edit, Print, and Delete permissions to the Doctors’ role members but with some ABAC style constraints. Our constraints or policy conditions are that the company cannot be in ‘Emergency Mode,’ the user must be accessing from the ‘internal’ network, and with strong MFA authentication (LoA/MFA ‘≥ 2’). The main difference between this PBAC policy and ABAC is that the policy is assigned to the Doctor role. This assignment would typically be represented in a relation or graph database giving auditors a clear picture of who granted the assignment and a least a partial answer concerning which permissions the Doctor role members have themselves been granted. The assignment is visible, tangible, and can be recertified periodically. Furthermore, it could also be added to a self-service workflow process where end-users could request it.
What is PBAC?
Figure 1: Information Technology – Next Generation Access Control – Functional Architecture (NGAC-FA)
In an actual real-world implementation of PBAC, the challenge of where to acquire the attribute data used in a rich policy is the same as that with ABAC. One possible solution is to split responsibility for making the final decision between the PBAC PDP and the application itself—a “Get Permissions” PBAC query. In this model, it is assumed that the application, or PEP, has access to some of the attribute data required for the policy decision. The application, or PEP, would query the PDP asking if the user were authorized to perform a particular action or operation. The PBAC PDP would then return a partial answer that would be No if there were no policy assignments to the user or their roles that authorized this action, would be No. However, if there were policies that granted the user this permission, then the PBAC response would be Yes, but with a list of the conditions or constraints under which the action would be permitted. In this model, and 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 30, below, Dr. Alice attempts to View Bob’s X-Ray. The application/PEP asks the PDP if this should be allowed. The PDP then looks within its PBAC policy store and locates one assignment that grants Doctors this permission and one where Alice has been assigned to the Doctors role. In the PBAC assignment for Doctors granting the View permission, there are constraint conditions defined. The PDP returns a partial Yes decision to the caller, which will include conditions. The application/PEP must then lookup the needed coded or scripted attribute information and make a full decision.
Figure 2: Example of a PBAC Get Permissions Decision
Another model for evaluating PBAC decisions is what we term an “Access Check” query. This model is common where the policies are not overly complex and will rely on information easily accessible to the application or by an application gateway acting as the PEP. As shown 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 but, because this request includes some pre-arranged information, the PDP evaluates this against its policies. Suppose the PDP finds 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 that conditions are met and, if they are, then return a Yes answer.
Figure 3: Example of a Full PBAC Access Check