The biggest benefit to attribute based access control (ABAC) is its flexibility.  You basically are assigning permissions to anyone who meets a certain criteria.  Dynamically.  As soon as you change a person's job, location, employment status, any attribute in any system you want, you are changing their permissions.

Ignoring application based permissions and roles for a moment because if you are reading this you have most likely seen the light in managing permissions in a centralized manner, there are three other main ways to manage permissions.  Users, groups and roles.  To manage permissions user by user would require, literally, a cast of thousands so we can ignore that one as well.

Active Directory security groups are used for permissions quite often.  File systems, SharePoint and some one off applications use AD groups.  Groups are something your users understand; it's just like a distribution group.  But there are limitations.  Not all applications can understand AD groups.  Maintaining group memberships is labor intensive (unless you use EmpowerID Group Manager!).

But one of the biggest issues is nested groups.  If your application is consuming group membership to manage permissions, it has to reach out to AD every time it tries to determine if your user has access and figure out the resultant permissions.  If you nest too deeply, this can take minutes each time (based on a client anecdote, up to 5 minutes).  EmpowerID solves this by inventorying group memberships and storing resultant permissions in the metadirectory but that's a blog post for another day.

Role based access control is more powerful than groups as you can map roles to any connected system or application.  Roles can be dynamic, allowing you to have the immediacy of attribute based access control.  This means that if someone changes departments, their role changes immediately as well.  These new roles can then be mapped to all applications and resources to reach well beyond the scope of AD groups.

But then you sometimes still end up with the square peg round hole syndrome.  You cannot have a role for every single permutation of permissions needed or you might as well go with assigning permissions by user.  Role bloat can be just as bad.  EmpowerID's polyarchical role structure helps solve that by allowing you to assign permissions based on multiple trees (business role and location for example), keeping the number of roles down.

You can still end up with one-offs and that is where ABAC comes to the rescue.  With EmpowerID's metadirectory, you can assign permissions based on attributes in any one of the connected systems (HR, AD, line of business apps, CRM).  Access rights are constantly inventoried so you don't have to hit each application every time someone tries to use that access, speeding up the time to grant access for the user.

When ABAC works best is when it is utilized in conjunction with RBAC.  For example, you have a sales role for account managers in the national accounts segment.  You want to give access to a sales contest reporting tool but only want it available to account managers that are at over 100% of quota. 

You certainly aren't going to create a "national account manager exceeding plan" role but you will have one for "national account manager".  Have EmpowerID check against your commission database to allow access for National Account Manager (role) who are greater than 100% to quota (attribute) and you have RBAC and ABAC synchronicity.

In summary, ABAC and RBAC are both better than group permissions.  There are times to use RBAC exclusively and ABAC exclusively.  But then there are also times to use them together and solve the square peg access problem.

Take a look at our whitepaper on RBAC/ABAC hybrid best practices and schedule a demo of EmpowerID to manage your permissions.