Roles-based access control (RBAC) has earned a place in the access control architectures at many organization. Companies have many questions about how to effectively use roles, including “How can I integrate role-based systems with my applications? How can I build a process around roles? How can I manage roles on a day-to-day basis? And by the way, how does this work?” It is difficult to distinguish between the different options on the market – they all claim equivalent functionality. Our goal for this post is to provide a simple view of how all the pieces fit together, what you do with them, and how each piece helps provide and/or support role-based access.

Role Lifecycle in a real-world enterprise

Roles make access control policy management easier. The concept is simple: perform access control based on a role assigned to one or more users. Users are grouped by job functions so a single role can define access for all users who perform a function – simplifying access control policy development, management, and deployment. The security manager does not need to set permissions for every user, but can simply provide access to necessary functions to a single shared role.

Like many simple concepts, what is easy to understand can be difficult to achieve in the real world. We begin our discussion of real-world usage of roles and role-based access control (RBAC) by looking at practices and pitfalls for using roles in your company.

Role definition

For a basic definition we will start with roles as a construct for managing the application of security policy in the separation between users and the system’s resources. A role is a way to group similar users. On the resource side resources are accessed via a set of permissions – such as Create, Read, Update, and Delete – which are assigned to roles which need them.

This simple definition is the way roles are commonly used: as a tool for management convenience. If you have many users and a great many applications – each with many features and functions – it quickly becomes untenable to manage them individually. Roles provide an abstraction layer to ease administration.

Roles and groups are often lumped together, but there is an important difference. Users are added to Groups – such as the Finance Group – to club them together. Roles go one step further – the association is bi-directional: users are members of roles, which are then associated with permissions. Permissions allow a user, through a role, to take action (such as Create, Read, Update, or Delete) on an application and/or resources.

Enforcing access control policy with roles

What roles should you create? What are your companies’ rules for which users get access to which application features? Most firms start with their security policies, if they are documented. But this is where things get interesting: some firms don’t have documented policies – or at least not at the right level to unambiguously specify technical access control policy. Others have information security policies which are tens or even hundreds of pages long. But as a rule those are not really read by IT practitioners, and sometimes not even by their authors. Information security policies are full of moldy old chestnuts like “principle of least privilege” – which sounds great, but what does it mean in practice? How do you actually use that? Another classic is “Separation of Duties” – which means privileged users should not have unfettered access, so you divide capabilities across several people. Again the concept makes sense, but there is no clear roadmap to take advantage of it.

One of the main values of RBAC is that it lets you enforce a specific set of policies for a specific set of users. Only a user acting in the role of Department X can access Department X’s resources. In addition, RBAC can enforce a hierarchy of roles. A user with the Department X manager role can add or disable users in the Department X worker bee roles.

Our recommendation is clear: start simple. It is very effective to start with a small set of rules, perhaps 20-30. Do not feel obliged to create more roles initially — instead ensure that your initial small set of roles is integrated end-to-end, to users on the front end, and to permissions and resources on the back end.

Roles open up ways to enforce important access control policies – including separation of duties. For example your security policy might state that users in a Finance role cannot also be in an IT role. Role-Based Access Control gives you a way to enforce that policy.

Implementation

Building on our simple definition, a permission checker could perform this role check:

Subject currentUser = SecurityService.getSubject();

if (currentUser.hasRole("CallCenter")) {
 //show the Call Center screen
} else {
  //access denied
}

In this simple example an application does not make an access control decision per user, but instead based on the user’s role.

Most application servers contain some form of RBAC support, and it is often better to rely on server configuration than to hard-code permission checks. For example:

<web-app>
<security-role>
        <role-name>CallCenter</role-name>
   </security-role>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Call Center pages</web-resource-name>
            <url-pattern>/CCFunctions/*</url-pattern>
       </web-resource-collection>
        <auth-constraint>
            <role-name>CallCenter</role-name>
       </auth-constraint>
   </security-constraint>

Notice that both code and configuration examples map the role the permission set to the resource (screen and URL). This accomplishes a key RBAC concept: the programmer does not need specific knowledge about any user – they are abstracted from user accounts, and only deal with permissions and roles.

Making this work in the real world raises the question of integration: Where do you deploy the roles that govern access? Do you do it in code, configuration, or a purpose-built tool?

Integration

RBAC systems raise both first-mile and last-mile integration considerations. For the first mile what you do is straightforward: role assignment is tied to user accounts. Each user has one or more assigned roles. Most enterprises use Active Directory, LDAP, and other systems to store and manage users, so role mapping conveniently takes place in collaboration with the user directory.

The second integration point (the last mile) is defined by an application’s ‘container’. The container is the place where you manage resources: it could be a registry, repository, server configuration, database, or any of various other places. Linking permissions to roles may be performed through configuration management, or in code, or in purpose-built tools such as access management products. The amount of work you have varies by container type, as does who performs it. With some solutions it is as simple as checking a box, while others require coding.

Using roles in real-world systems

This introduction has provided a simple illustration of roles. Our simple system shows both the power of roles and their value as a central control point for access control. Taking advantage of roles requires a plan of action, so here are some key considerations to get started:

• Identify and establish authoritative source(s) for roles: where and how to define and manage the user-to-role mapping
• Identify and establish authoritative source(s) for permissions: where and how to define and manage resource permissions
• Link roles to permissions: the RBAC system must have a way to bind roles and permissions. This can be static in a access management system or a directory, or dynamic at runtime
• Role assignment: Granting roles to users should be integrated into identity provisioning processes
• Permission assignment: Configuration management should include a step to provision new applications and services with access rights for each interface
• Make access control decisions in code and configuration, and services
• Use roles to conduct access reviews: large organizations adopt roles to simplify access review during audit

Our next post will build on our simple definition of roles, drilling down into role engineering, management, and design issues.