Corporate approaches to identity and access management (IAM) have evolved as technology has advanced. The advances provide enforcement of fine-grained authorization decisions and also support enterprise-level control of authorization that allows business leaders to understand and review the decisions. For example, access control lists (ACLs) that focus on individual users have been replaced, in many cases, by approaches that focus on specific user roles or attributes as well as systems that rely on policies to determine users’ access rights.
There are currently four major approaches to IAM, each with its own strengths and limitations:
An Access Control List (ACL) provides authorization for specific resources using a list that matches users and access rights. The ACL approach is used to control basic functionality, such as logins as well as controlling access to specific items in a database.
Control - An ACL grants access rights based solely on the user’s identity and does not include any other attributes in the decision.
Administration - Especially in large organizations, authorization can be cumbersome and difficult to manage. For example, when a user needs many specific access rights, which are granted one-by-one and there is a change in their responsibilities, or if resources are added or removed.
Scenario - A group of nurses, who only had access to the data of patients in their department, is now granted access to the ICU. Each nurse now needs more access rights including patient data. Assigning these rights is very time-consuming and is subject to human error.
Role-based access control (RBAC) systems work by defining fine-grained roles, each with a unique set of access rights, and then assigning each user to a specific role. A change to a role’s rights automatically and safely change the rights of each user with that role. If a user changes their role, their rights are changed accordingly.
Control - RBAC provides authorization only based on the user’s role and does not include any other relevant attributes in the decision. Access rights are fixed and can only change by assigning the user to a new role or by redefining that role, affecting others as well. Moreover, RBAC cannot meet the more complex authorization needs of IT environments that are integrated with third-party infrastructures.
Administration - The need for more granular access control in larger organizations leads to an increase of specified roles but as Joe Campbell from One Identity writes, “I’ve seen it over and over again, with time users accumulate roles but never have outdated roles taken away.”
Scenario - Over the course of a few years, a group of QA engineers transfers from project to project. Their access rights to the first project are maintained, even though that role is now outdated.
Attribute-based access control (ABAC) systems use attributes (such as user location or role) to create an even more finely-grained access system. Once a policy is defined, authorization is performed automatically at runtime, with no need to define specific users or groups.
Control - Attributes are determined at a local level, not universally, as is usually required by an enterprise (e.g., EU administrators might have different access rights than US administrators).
Administration - Increased flexibility leads to increased complexity. This might not be appropriate for a small organization that does not use third-party infrastructure.
Scenario - Access to a resource might not be controlled uniformly – in one organization of the enterprise, access might be controlled by user credentials, and in another organization, via a digital certificate. This lack of uniformity can cause duplication, confusion, and ultimately weaknesses in access control.
Policy-based access control (PBAC) is a dynamic system that grants access based on logical rules which can be altered in real-time, automatically changing user access if needed. PBAC is an evolution and natural extension of all other access control methods. PBAC fully supports roles and attributes and, because it can support multiple authorization protocols and languages, it is the best solution for enterprise systems.
Control - The flexible nature of PBAC means that different administrators could inadvertently create rules that contradict other rules.
Administration - Implementation can be a major effort since the tools available in the market to manage PBAC are still not mature.
Scenario -
An IT Security Manager sets a policy for employees that says, "Access to the CRM application will only be granted to authorized employees who attempt access from within the company's internal network."
The VP of R&D, who has admin rights over access to the CRM system and wants support personnel in the field to be able to access the system, then creates an additional and conflicting rule that says, "Access to the CRM application will be granted to authorized employees who attempt access via a VPN."
The contradiction in the scenario is simply whether an authorized employee can access the CRM both within the company’s internal network or also when in the field via a virtual VPN, and can be easily avoided if the available tools to manage PBAC are sufficiently developed. Or taken even further, a policy based system would allow for the creation of a policy that changes the specified employee’s access in real-time depending on the location – either inside or outside the company’s internal network.
Each of the approaches discussed here have their own strengths and limitations.
The larger the system, the greater the need for more finely-grained access rules, but the greater the risk of complication. While the trade-offs involved in choosing an IAM approach as well as designing and maintaining a specific system will not disappear, it is clear that PBAC systems provide the most comprehensive solution. With the right tools to manage PBAC, many of the limitations can be mitigated, opening the door to the many advantages of Policy-Based Access Control.
