The National Institute of Standards and Technology describes ABAC this way:
ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) actions and the environment relevant to a request. Attributes may be considered characteristics of anything that may be defined and to which a value may be assigned. In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of the object, environment conditions, and a formal relationship or access control rule defining the allowable operations for subject-object attribute and environment condition combinations. — Attribute Based Access Control (ABAC)
If you are not used to reading knowledgebases, that may not make a lot of sense. In basic terms, ABAC is a way of assigning access based on the situation of the user and what is available. Instead of just focusing on ‘why’ a user needs access, it looks at things like ‘who’ the user is, ‘what’ special access conditions have been put in place, ‘when’ a resource is available or a user requires access, ‘where’ a user works and otherwise might sign in from, and ‘how’ a user is logging in.
The majority of systems rely on arbitrary roles to identify what permissions and authority a user is allowed to have. This is known as Role-Based Access Control (RBAC). The major drawback of this approach is that each system has its own way of defining roles and enforcing the restrictions based on them. Also, ‘roles’ do not generally provide much information about themselves beyond their name, thus requiring research into each one when wanting to assign that role or when performing an audit. With disparate systems and the difficulty of keeping track of how roles are set up, duplicate, triplicate or centuplicate roles are created to cover different worker situations or because existing, but disused roles have been forgotten. Over time, organizations evolve and so do their IT systems, increasing the complexity of such roles. Quite often, a medium size organization will end up with thousands of roles across their systems and several identities for each user that must then be kept track of.
In the real world, users are actually people who need access to the resources that will allow them to handle their roles in the business. For example, a finance manager in an organization should have access to account and finance data as well as reports. A human resource manager, on the other hand, should have access to information about workers, employment details and the organization structure, but not necessarily account and finance data. This may sound simple enough; just create two roles. But what if the resources required can’t communicate with each other? Now you need duplicate identities for each system that will need to be managed separately. What if certain types of users should be locked out of specific resources even though they belong to one of these groups? Now you need extra roles to account for those situations. Since many systems have their own way of looking at users, each of these concerns doesn’t just add one role; it causes them to multiply, making things even harder to keep track of.
While organizations generally look at access management as something complex, requiring a lot of resources and effort to manage, this is generally due to sticking with the default RBAC manager that comes with each system. User provisioning systems that only use RBAC cannot understand such things as worker designations and data requirements across systems, limiting them even when it comes to automation. While roles certainly have their place, they are not enough. Enter ABAC. In addition to assigning access based on attributes, ABAC solutions generally enforce several rule sets such as mandatory access control, discretionary access control and in many cases risk-adaptable access control.
Business attributes are simple to understand and can easily be managed by normal workers like secretaries, HR personnel and supervisors. In fact, many businesses already have some sort of HR system in place that contains this information. What is needed, then, is a bridge that can look at business attributes and then distribute access based on them as well as any assigned roles.
One solution that bridges the gap between ABAC and RBAC is IDM365—a future-ready product capable of designing and enforcing rules based on attribute and business environment parameters. IDM365 enforces mandatory access control based on employment types and locations. Discretionary access control is provided based on roles known as ‘job functions’ that are profiled based on user employment types. To provide risk-adaptable access control, access permissions can be made mutually exclusive through rules pertaining to segregation of duty. Finally, IDM365 provides an attribute store that can act as a repository and attribute exchange platform for the various business and personal attributes attached to a user.
It is expected that, as time goes on, ABAC will become widely accepted as the authorization model of choice for businesses. A solution which can bridge the gap between RBAC and ABAC is therefore indispensable—a high-value software asset for a business-minded future.