What is Policy Based Access Control?
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.
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.
Figure 1 below illustrates a PBAC policy that grants the Read, Edit, Print, and Delete permissions to the Doctors’ role members with some ABAC style constraints. These constraints or policy conditions are that the company cannot be in “Emergency Mode,” the user must be accessing information from the “internal” network, and using strong MFA authentication. 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 what permissions members of the Doctor have 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 Policy Enforcement Point (PEP), has access to some of the attribute data required for the policy decision. The application, or PEP, would query the Policy Decision Point (PDP) asking if the user is 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 either to the user or their roles that authorized this action. However, if there were policies that granted 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 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 2 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 attribute information and make a full decision.
Figure 2: Example of a PBAC Get Permissions Decision
Another model for evaluating PBAC decisions is what EmpowerID terms 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. If 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
See Also
Create PBAC Membership Policies
What is Role Based Access Control?
What is Attribute Based Access Control?
EmpowerID Hybrid Access Control (RBAC, ABAC, and PBAC)
What are EmpowerID Operations?