In the first part, we described the purpose and concepts of ABAC (attribute-based access control) and looked at two early iterations. In this part, we’ll explore further iterations of MyABAC, the authorization system we built.
Iteration 3: Making new policies easy to author (PEP + PDP + PAP)
In the last iteration, MyABAC has a PDP and an evaluation strategy, but the strategy is based on directly executing code as policy files. The PAP is responsible for the way these policies are managed by operators. There are certain logical combinations in policies and rules so that the corresponding conditions are satisfied. XACML’s own XML-based language is complex, so we chose to write our own YAML-based language that allowed for easy readability and a powerful conditional declaration called MPL (MyABAC Policy Language). The PDP has a compiler (MPL Compiler) to compile policy files edited by the PAP into a policy that it can use. This way, the policy can only be changed through PAP.
MPL makes the policy file clear and simple. The first figure below is the XACML policy file, and the second is the MyABAC policy file.
Iteration 4: Making an exact decision with more attributes (PEP + PDP + PAP + PIP)
With PDP for evaluation, the results of PEP execution and the PAP management strategy, MyABAC might look complete, but putting it into production shows that real-world scenarios require more than just attributes obtained from the request.
Going back to the library management system as an example. How would you know which specific floor an administrator is responsible for? The general request typically only has one number per given administrator. To obtain more information, you need to make the corresponding request in the system. The services or products that can provide more information to support the PDP are called PIP. They’re not an internal component of MyABAC, but an external third-party component. These services may be an HTTP Restful-based interface, a GraphQL interface, etc. But in order for PDP to call these PIPs correctly, PIP must follow the protocol established by PDP, so that PDP can reasonably transmit the information necessary for PIP to obtain the desired information (e.g. administrator floor number). All this is encapsulated in the PDP’s PIP Client component. This way, the Decision Maker not only has the attributes from the extractor in the PEP, but can also get more attribute values through the PIP. Furthermore, each change in attribute value will be fed back to the PDP, so that we can achieve fine-grained access control through dynamic participation.
We can also separate the PAP from MyABAC to manage the policies of multiple systems. For example, we may deploy multiple MyABACs to protect different services, so that we have different rules for each system but the same centralized PAP to manage their policy files.
Iteration 5: In the future
Through the previous iterations, we created a relatively complete ABAC MVP (Minimum Viable Product). Due to the additional workload added to the original request, including PEP to PDP requests, PDP to PIP requests, etc. multiple strategies need to be checked, making performance something that MyABAC cannot ignore. For future iterations, we’ll use lazy loading and caching to optimize MyABAC’s performance. We’ve also introduced concepts from ABAC and XACML based on demand and scenarios that people were using for MyABAC, introducing more concepts to continuously improve the product. For further improvements, we hope to integrate with Open Policy Agent (OPA), a policy engine that gives the author powerful capabilities.
Conclusion
ABAC has a broader concept and more complex implementation than RBAC. If Role is regarded as ABAC’s only attribute, then RBAC is a special case of ABAC. Choosing between ABAC and RBAC should be based on business requirements. The emergence of MyABAC completely separates the authentication part of the system from the business logic, allowing system designers and developers to pay more attention to specific business implementation. As a completely self-managed product, it can be deployed in each system as a sidecar, or even in a set of systems in different layers, such as BFF layer, API layer or database layer. But it also increases the complexity of system deployment, and we have to make reasonable choices and trade-offs.
At present, we’ve already used MyABAC in multiple systems, and some new functions have been introduced based on user feedback, such as support for Obligation.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
