To understand the concept of the access control mechanism, consider an organization’s network and resources as a building. It has only one entry gate protected by a security guard. To enter the building, visitors must prove their identity to the security guard. Those who fail to prove their identity are denied entry to the building. The security guard here plays the role of access control.
Access control lays the groundwork of an organization’s security infrastructure. Two popular models for access control are:
- Role-based access control (RBAC)
- Attribute-based access control (ABAC)
Table Of Contents
What is Role-Based Access Control (RBAC)?
What is Attribute-based Access Control (ABAC)?
RBAC vs. ABAC: A Comparison
When to use RBAC or ABAC?
Access Control via GroupID
What is Role-Based Access Control (RBAC)?
Role-based access control (RBAC) grants access based on the role of a person in an organization. In RBAC, ‘role’ refers to the level of access that a person has within a network. Roles are defined by the administrator in keeping with certain characteristics, such as:
- Seniority level
- Job role
You can assign different permissions to each role. Based on these roles, people (users) can access files and data on the network. This minimizes unauthorized access to sensitive information and applications.
Organizations go for RBAC since the policies do not need to change every time an employee leaves or switches jobs. All an administrator needs to do is remove the employee from that role or change their role group, saving time and resources.
Examples of RBAC
Following are two examples for RBAC:
- Let’s examine the permissions for a ‘writer’ role and a ‘reader’ role. A user with the writer can read, write, edit, and delete an article. However, a reader can only read the article but cannot write, edit, or delete it.
- In a company, a Chief Technology Officer can access all the company’s server. A software engineer can access some of these application servers. A remote employee has rights to access the servers they are actively working on.
Azure Role-Based Access Control (Azure RBAC)
Many organizations opt for cloud-based services for storage and networking. Hence, access management for cloud resources is a critical function. Azure RBAC manages access to Azure resources based on the defined Azure roles and role assignments.
With Azure RBAC, you can:
- Allow a user to manage virtual networks and set another user for managing virtual machines in a subscription.
- Allow a Database Administrator to manage SQL databases.
- Allow a user to handle all the resources in a resource group, such as website, virtual machines, and subnets.
- Allow an application to access all resources in a resource group.
Security Roles in Active Directory
Default security groups are automatically created in Active Directory. They serve the following purposes:
- Control access to resources.
- Help delegate administrative roles. Each default group (role) is assigned a set of user rights that all its members inherit.
Some of the security roles / groups are as follows:
- Backup Operators: Members of this group can restore and replace files on a computer irrespective of the permissions required to access those files.
- Remote Desktop Users: Members have permissions to connect to an RD Session Host server remotely.
- Domain Admins: Domain Admins are allowed to administer the domain. They are assigned default ownership of any object created in the directory. Administrators can also update the membership of all administrative groups and can control access to all domain controllers in a domain.
- Enterprise Admins: Enterprise Admins is a universal group that exists only in the root domain of an AD forest. Group members can make forest-wide changes, such as add child domains.
- Schema Admins: Schema Admins can modify Active Directory schema. They have complete administrative access to the schema.
Security Roles in SharePoint
Just like Active Directory, SharePoint has also predefined roles that grant access levels and permissions to users. Each role has a unique set of permissions that a user with that role adopts.
Following are some of the roles defined in SharePoint:
- End Users: End users are basically regular users that can work in content creation through list items and document libraries. They are not assigned permissions to configure and manage sites.
- Power Users: Power users are slightly higher than end users since they have permissions to interact with certain site components, like lists, web pages, libraries, etc.
- Site Owners: As the name suggests, Site owners have control over SharePoint security infrastructure. Along with having the same permissions as those of Power Users, they also have control over the entire site, that includes sub-site creation, design, permission management, etc.
- Site Collection Admins: Site collection administrators control multiple sites within a site collection.
- SharePoint Farm Admins: They are the top-level administrators that have complete control over SharePoint, such as maintenance, storage, web apps, site collections, etc.
Read More: Best Practices to Manage SharePoint Access via Active Directory Groups
Security Roles in Exchange
Microsoft Exchange follows an RBAC permission model. You can assign permissions to users based on their management roles.
Some built-in management roles in Exchange are as follows:
- Recipient Management: Members of this groups can create or update Exchange Server recipients within the Exchange Server organization.
- Helpdesk: Helpdesk users can view and update user attributes through Outlook on the web, which include modifying users’ addresses, phone numbers, and display names.
- Server Management: Members can configure server-specific configuration of transport, client access, and mailbox features, such as transport queues and Send connectors, certificates, database copies, client access protocols, and virtual directories.
- Organization Management: Members from Organization Management have a top-level access in the Exchange Server organization, which means that they can perform almost all the tasks for an Exchange object.
- Hygiene Management: Users with the Hygiene Management role configure anti-spam and anti-malware features in Exchange.
What is Attribute-based Access Control (ABAC)?
Attribute-based access control (ABAC) is an authentication and authorization model that grants access based on user attributes instead of roles. In ABAC, access permissions are assigned based on the following:
- User Attributes: Job title, seniority level, department, job role, etc.
- Resource Attributes: Type of file, owner of the file, sensitivity level of the file, etc.
- Environment: Network, geolocation, time of the day, date, etc.
ABAC evaluates the user attributes and develops access-based policies to define which combination of attributes are required to perform an action on a resource. This is how it works:
- When a user requests for access to a resource, ABAC will scan the user attributes to check if they meet the defined policies.
- If the attributes do not match, the request will be denied.
ABAC is slightly more complex as compared to RBAC. It controls access and security on a more fine-grained basis, reducing risks of unauthorized access.
Example of ABAC
Following are two examples for ABAC:
- A person with HR role has access to employee payroll information. ABAC can place further restrictions, such as allowing a certain time when that information can be accessed or allowing access to the information for certain branches instead of the entire company.
- You do not want the entire sales team to view the potential leads data of the entire company. You can implement ABAC to allow the sales representatives of the United States region only to view the data.
Azure Attribute-based Access Control (Azure ABAC)
Azure ABAC allows access based on role definitions and role assignments, just like Azure RBAC. The difference here is that Azure ABAC adds role assignment conditions in the context of certain actions. Role assignments conditions are like an additional check that you can implement to fine grain your access control. For example, you can add a condition that requires an object to have a specific tag to read the object.
Azure ABAC has the following benefits:
- Provides more precision in access control.
- Can work with attributes that have specific business meaning.
- Requires lesser roles to be assigned.
RBAC vs. ABAC: A Comparison
ABAC can be considered an extension to RBAC. Both these access control methods target the same goals. The tables below show the pros and cons of RBAC vs ABAC.
|PROS of RBAC||CONS of RBAC|
|It works best for small to medium-sized companies.||In case of large-sized companies, you need more roles. Adding role after role can lead to “role explosion”. Managing them can be cumbersome for administrators.|
|Following the organizational hierarchy, you can create access hierarchies where a manager or team lead can get all the permissions of their direct reports automatically.||In case of role explosion, translating responsibilities of a user into a role can be time-consuming and complicated.|
|Costs required to implement RBAC are relatively low.||Customizing user permissions is not quite flexible. Each customization will require the creation of a new role.|
|PROS of ABAC||CONS of ABAC|
|Makes data access dynamic due to its multidimensional approach.||Its implementation can be complex and time-consuming.|
|Can work for organizations with large user base. For new users, admins need to assign appropriate attributes instead of modifying rules.||If you face an error during ABAC implementation, recovering from it may be difficult due to its complex structure.|
|Updating user attributes for adding or removing permissions is much easier than defining new roles.||Requires more resources, time, and tools that can add to the overall costs.|
RBAC vs ABAC: Which One to Choose?
Depending on your organization’s structure, budget, size, and security requirements, you need to make a choice to answer the question of: RBAC vs ABAC: Which One to Choose? In some scenarios, ABAC turns out to be the winner and in others, it’s better to use RBAC.
To make the decision of RBAC vs ABAC easier, following is the breakdown of cases where RBAC or ABAC can be used.
Choose RBAC (Role based Access Control) when you:
- Have a small or medium-sized organization.
- Have well-defined groups in your network.
- Are short on budget, resources, and/or time.
- Do not expect a huge influx of new users in your organization.
Choose ABAC (Attribute based Access Control) when you:
- Have enough budget and resources.
- Have a large organization that continues to expand.
- Have workforce distributed geographically.
- Want a customizable and flexible access control policy.
- Want a long-term access control policy that can keep the security tight.
Access Control via GroupID
GroupID by Imanami is an Identity and Access Management (IAM) solution that follows the RBAC model for access management. You will find the following predefined roles in an identity store in GroupID:
- Administrator: This role has permissions on all functions that can be performed within an identity store using GroupID.
- Helpdesk: Helpdesk users can update directory information for other users. They can also reset identity store account passwords and unlock identity store accounts on behalf of other users.
- User: This role can be assigned to regular users, enabling them to create new groups, manage their groups, manage their directory profiles, and manage their identity store passwords.
A priority number, between 1 and 99, is assigned to each role. 1 indicates the highest priority and 99 indicates the lowest priority. Role priority is unique for each role in an identity store and is used to resolve conflicts when a user has more than one role.
Role Policies in GroupID
In GroupID, you can even create new roles and assign permissions to them. Permissions allow user roles to perform certain actions using GroupID, such as:
- Create and manage groups
- Manage user profiles
- Manage scheduled jobs, and more
In addition to permissions, policies also determine what role members can do in GroupID and apply certain restrictions.
Policies refine and strengthen role-based access. In GroupID, you can define the following policies for each role:
Group Ownership Enforcement policy:
Prevents role members from creating a group without a primary owner. It also places restrictions on the number of additional owners that a group can have.
Group Name Prefixes policy:
Enforces role members to add a prefix to a group name while creating a group.
New Object policy:
Role members are allowed to create new objects in a specific OU in the directory rather than any OU in the directory.
Limits role members to search objects in a specific OU in the directory instead of the entire directory.
Enforces role members to authenticate with specific authentication types (Security Questions, Email, Authenticator, SMS, Linked Account, PhoneID, YubiKey and Windows Hello) to sign into GroupID.
Specifies password rules and validation checks that apply when role members create their passwords.
Implements restrictions for helpdesk users when they reset domain passwords and unlock accounts on behalf of end users.
Access control is mandatory for organizations to shield them from data breaches. To understand the difference between RBAC vs ABAC and which one to choose, each model has its advantages and shortcomings. Administrators should evaluate their environment and needs to determine the model that best suits their environment.
GroupID provides access management that is way easier to understand, implement, and manage. The role permissions and policies defined can be adapted to cater to all kinds of organizations whether large or small.
Jonathan BlackwellView Profile
Since 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.