Attribute-based Access Control (ABAC ) has been with us for many years; it embodies a wide range of systems that control access to protected resources based on attributes of the requesting party. As the field has developed there are three characteristics that are most desirable in an ABAC system:
- it should externalise decision making i.e. not require applications to maintain their own access control logic
- it should be adaptive i.e. decisions are made in real-time
- it should be policy-based i.e. access permissions should be determined based on after evaluation of policies
- it should be more than just control i.e. user access should “manage” user’s access control.
Most access control environments today are role-based. Users are granted access to applications based on their position within an organisation. For instance, department managers within a company might get access to the HR system for their department. When a new department manager joins the organisation they can be automatically provisioned to the HR system based on their role. Most organisation use Active Directory groups to managed roles within an organisation. If you’re in the “Fire Warden” group you get access to the fire alarm system. One of the problems with role-based systems is the access control decisions are coarse-grained, you’re either a department manager or you’re not. RBAC systems are also quite static, group memberships will typically be updated once a day or, worse still, require manual intervention to add and remove members. Whenever access control depends upon a person to make an entry in a control list, inefficiencies result and errors occur.
Attribute-based systems have several advantages: decisions are externalised to dedicated infrastructure that preforms the policy evaluation. Decisions are more fine-grained: if a user is a department manager an APAM system can also check a user’s department code and so decide, for instance, whether or not to give them access to the Financial Management system. It can check whether or not they are using their registered smartphone; it can determine the time of day, in order to make decisions that reduce the risk associated with an access request. Such systems are usually managed via a set of policies that allow business units to determine, for instance, whether or not they want to allow access from a smartphone, and if they do, to elevate the authorisation level by using a two-factor mechanism. The benefits are obvious: no longer are we dependent upon someone in IT to update an Active Directory group, and more sophisticated decisions are possible. APAM systems are also real-time. As soon as HR updates a person’s position, their permissions are modified. The very next access request will be evaluated against the same policy set but the new attributes will return a different decision.
So what’s holding us back from deploying APAM systems? Firstly, there’s the “if it’s not broken don’t fix it” syndrome that encourages us to put up with less than optimal systems. Another detractor is the requirement for a mature identity management system, since access to attributes is needed. There is also a need to manage policies but often business groups are unwilling to take on the policy management task.
It’s incumbent on C-level management to grapple with these issues. They must set the strategy and implement the requisite change management. If they do, not only will they be reducing the risk profile associated with their access control system, they’ll open up new opportunities. It will be possible to more easily extend business system access to their business partners, and customers, for whom it is unsustainable to populate Active Directory groups.
APAM has much to offer, we just need is a willingness to embrace it.
This article has originally appeared in KuppingerCole Analysts' View newsletter.