Connect with us

Hi, what are you looking for?

Web

Using Roles for Access Control is not RBAC

I hear this kind of statement all the time:  ‘We use Roles/Groups for access control in our systems and applications so we’re RBAC’.

My response is an emphatic:  ‘No – using roles for access control is not Role-Based Access Control!’

The first is an anti-pattern, the second a best practice.  Let me explain.

RBAC is not a generic term.  It refers to a specification, ANSI INCITS 359, with explicit instructions to implement.  There are many posts that offer detailed explanation – including:

http://symas.com/ansi-rbac-intro/

To be considered RBAC compliant an access management system, at a minimum, supports the following entities: Users, Roles, Permissions (mapping between objects and operations) and, most important – Sessions.

Sessions are the context for which role activation occurs.  Just because a role has been assigned, does not mean it should be included into a particular access control decision.

This is in keeping with the principle of least privilege:  Only give the user the authority they need to complete their job at any particular point in time – and no more.

Doing this satisfies a multitude of requirements and we’ll talk about some in future posts.

So unless your access control system supports the session contextual object – stop calling it RBAC.

But there’s much more to it than that.  RBAC specification defines the interfaces necessary for CRUD and interrogation operations.  One of the most important:

userPermissions(User)

This returns all permissions authorized for a user via their role assignments.  And another:

authorizedPermissionUsers(Permission)

Crucial during audits – which users have access to a particular system resource?  If you cannot answer this question your system lacks integrity.  Many access management systems cannot accomplish these basic operations.

RBAC also defines the interface used during runtime policy enforcement operations.  For example:

sessionPermissions(Session)

This returns all permissions authorized for a user via their role activations.  Used by apps to cache entitlements during runtime.  Without the Session entity it cannot be done.   If yours cannot do this – stop calling it RBAC.

Finally there is this:

Placing roles within the access control decision paints you into a corner.  This operation usually looks something like:

isUserInRole(RoleName)  <— this is ok for coarse-grain but not fine-grained authZ

What if the roles change?  Every change requires (some variation of) a recompile and redeployment of the application.  Worse, you will need to create too many of them which pollutes your system and complicates the administration processes.

There is a better way – use a permission semantic:

checkAccess(Session, Permission)

This allows the policy enforcement point to be decoupled from the policy decision point.  If the roles needed to access that resource change, the application doesn’t.

If your access management system does not do these things – stop calling it RBAC!

Written By

Systems architect, security guy, open-source advocate and avid cyclist.

Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You May Also Like

Tech

In today’s digital era, where the Internet plays a vital role in our lives, it’s important to put security and privacy first. With the...

Tech

Tailgating is a smart use of social engineering by intruders to get around traditional security systems. It involves people using rare, natural opportunities to...

Computer

It may seem with data security breaches that it’s less a matter of if than when. Account security is vital, yet hackers continue to...

Computer

One in four businesses is likely to experience a data breach, with the average cyberattack costing businesses up to $3.62 million in 2017, according to...