There is no need to choose between RBAC and ABAC.  A case can be made for each individually and certainly a case can be made for RBAC (role based access control) and ABAC (attribute based access control) working together.

RBAC is definable, the user is a member of a role or isn't.  If the user is part of the dental chair warehouse worker role, then they are granted access to resources that role needs.  This role membership handles the user's coarse grained access...what files and folders they can access, in what applications do they have user accounts, what group memberships they have.

Most access can be granted at this level, RBAC can be applied to almost every identity action from role based provisioning to role based authentication to role based authorization to role based administrative policies.

These role memberships are all definable and, most importantly, auditable.  Your audit and security reports will show what roles a user has and, conversely, what users are in each role.  You will have an audit trail of every action these users do via their roles and what each of these roles can do.

EmpowerID grants these role memberships during the provisioning lifecycle process.  As a user is provisioned, the roles are granted dynamically based on attributes in any connected system (HR database, Active Directory, ERP system, union membership database).  This dynamic role membership is maintained during a user's lifecycle as their job title, department or anything else changes, so does their role memberships. 

Users can also request access to roles or request access to a resource that puts them into a role.  Self service role management is powerful if the correct controls are in place, with workflows and approval routing mechanisms.  Temporary roles can also be administered in this way, where a user requests access to a customer folder for 3 days.  And, like all role memberships, it is auditable.  You will know who had what access and when.

But, as we started in this discussion, there is a world where roles are not fine grained enough.  You don't want to have a situation where you create a role for every single possible permutation of access needed.  Role bloat like this would be unmanageable and unauditable.  You would end up with more roles than users.

So, what do you do for the finer grained authorization that you need?  Combine RBAC and ABAC.  A user is a member of a role based on access provisioning policies.  But, at runtime when accessing a resource, you can further define that access by ABAC, checking on an attribute that you know about the user in real time.

Let's use that example of the dental chair warehouse worker.  This worker needs access to a particularly sensitive section of your ERP system to order a gold plated footrest on the top of the line dental chair.  But, your security team insists that the warehouse worker should only be able to access ERP during his shift.

Most warehouse workers exchange shifts, take extra hours and vary their workweeks constantly.  You cannot just make a swingshift warehouse worker role and know that it's accurate for every worker every time.  So RBAC handles the coarse grained permission that our user is a dental chair warehouse worker.  When the worker goes to access the gold plated footrest in ERP, EmpowerID checks that the user's role gives him access, then at runtime, checks the time management system to see if the user is on shift right now.  If so, boom, access.  If not, boom, security alert.

If you tried to manage an example like this with just RBAC, you would have a role bloat issue leading to user and help desk revolt.  If you tried to manage this with just ABAC, you would have an auditor and network performance issue, leading to executive management and user revolt.

A hybrid of RBAC and ABAC streamlines this, gives you the ability to manage most permissions with a coarse grained role and the rest with a fine grained attribute.  EmpowerID is built from the ground up to handle these two concepts together and seamlessly.