At the highest level, identity management systems are typically composed of three major elements: users, systems/applications, and policies. Policies define how the users interact with the different systems and applications.
Most identity and access management (IAM) products provide a variety of methods for implementing the policies to control access to organizational resources, with varying terminology being used to describe these methods. However, all forms of access control can ultimately be mapped back to one of four classic models: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-based Access Control (RBAC), and Attribute-based Access Control (ABAC).
DAC and MAC
While this post focuses on the RBAC and ABAC models, I want to briefly describe the first two for the sake of completeness.
- Discretionary Access Control (DAC) – controls access based on the requestor and on access rules stating what the requestors are or are not allowed to do. For example, an administrator can manually give another user access to an application at his or her discretion.
- Mandatory Access Control (MAC) – controls access based on comparing security labels with security clearances (e.g. Confidential, Secret, Top Secret) and is typically utilized in protecting classified information in military systems. RapidIdentity has the capability to implement and support all four models, but is primarily focused on RBAC and ABAC.
So, What is Role-Based Access Control?
RBAC controls access based on the roles that users have within the system and on rules stating what access is allowed for what users in given roles. Typically, with modern IAM solutions, a Role is roughly equivalent to a Group in the directory system and is simply a logical grouping of one or more users that have some common affiliations, such as a same department, grade, age, physical location, or user type.
For example, with RBAC, a user in the accounts payable clerk position would automatically get added as a member (i.e. dynamic membership) to the AP Role, granting him or her access to AP functions in the accounting system.
Defining Attribute-Based Access Control
ABAC can control access based on three different attribute types: user attributes, attributes associated with the application or system to be accessed, and current environmental conditions.
An example of ABAC would be allowing only users who are type=employees and have department=HR to access the HR/Payroll system and only during business hours within the same timezone as the company.
ABAC is not only the most flexible and powerful of the four access control models, but is also the most complex. In fact, technically ABAC is capable of enforcing DAC, MAC, and RBAC.
At its core, ABAC enables fine-grained access control, which allows for more input variables into an access control decision. Any available attribute in the directory can be used by itself or in combination with another to define the right filter for controlling access to a resource.
Knowing When to Use RBAC vs ABAC
Now that we better understand the major differences between the two models, we can explore best practices for which to use and when. While RBAC and ABAC can be very complex subjects, here are four simple concepts you can refer to not only as you start your IAM implementation, but on an ongoing basis as your organization and needs change:
1. RBAC is for coarse-grain access control and ABAC is for fine-grain access controls.
When you can make access control decisions with broad strokes, use RBAC. For example, giving all teachers access to Google or all contractors access to email. When you need more granularity than this or need to make a decisions under certain conditions, use ABAC. For example, giving teachers access to Google if they are at School X and teach Grade Y.
2. RBAC before ABAC.
A general rule of thumb is that you should try to use RBAC before ABAC because at their core, the controls are just searches or filters. The bigger and more complex the search, the more processing power and time it takes. And, the more users and applications an organization has, the greater processing impact the searches/filters will have because of the increase in search space.
3. Less is More.
If you are creating a lot of very complex RBAC and/or ABAC filters, you are probably doing something wrong. A little bit of planning in advance can help you structure your directory data in a way that mitigates the need to develop complex filters/queries. However, every now and then, you will definitely have to get creative to establish the right level of access control, but this should be the exception and not the rule.
4. Divide and Conquer.
You can always use RBAC and ABAC together in a hierarchal approach. For example, using RBAC to control who can see what modules and then using ABAC to control access to what they see (or can do) inside of a module. This is similar to a WAN and LAN-based firewalls where the WAN does the coarse-grain filtering and then LAN-based does the finer-grain inspections.
Just remember, during your implementation of IAM tools, access control is a set of policies that ensures users have the correct access to the correct systems, resources, and applications. So, whether you use RBAC or ABAC, a good IAM solution should help you define what users can do with applications by providing multiple mechanisms to ensure the right people, get the right access, to the right things—at the right time.
Comments