The “pathway to hell” – this is how Eran Hammer-Lahav once called the security protocol OAuth 2.0, on which he himself had worked for years. Others, however, use the service without issue. It enables users to use data and functions across multiple platforms in multiple services – for example, with the convenient single sign-on – using secure API authorization. But how exactly does OAuth2 work and...OAuth & OAuth 2: data usage across platforms
Companies and organizations only assign access permissions in their IT systems to users who actually need them to carry out their activities. This protects sensitive data from unauthorized access and modification. To ensure that security is maintained in large organizations, individual access permissions are defined in an access-control list (ACL). This does have a disadvantage. The larger the number of users, the more high maintenance and error prone the assignment of individual permissions will be. A flexible yet efficient alternative for handling this is role-based access control (RBAC).
What is RBAC?
Role-based access control (RBAC) is an approach to handling security and permissions in which roles and permissions are assigned within an organization’s IT infrastructure. The key term here is “role-based”. This is what distinguishes RBAC from other security approaches, such as mandatory access control. In this model, a system administrator assigns a security level and category to each user and object. The operating system automatically compares the two levels and then either grants or denies access.
In RBAC, access permissions are assigned based on a defined role model. Defined user roles represent the work processes in an organization and vary from company to company. To effectively break down user roles, you could do this by department, location, cost center or employee responsibilities.
How role-based access control works
Before RBAC can be implemented in a company, the permissions for each role have to be defined as thoroughly as possible. This involves precisely defining the permissions for the following areas:
- Modification permissions for data (e.g. read, read and write, full access)
- Access permissions for company applications
- Permissions within the applications
To fully benefit from the advantages of the RBAC model, the first step is always to establish a model for the roles and permissions. This involves the organization assigning all employee responsibilities to specific roles which determine the corresponding access permissions. Then, the roles are assigned to employees according to their responsibilities. Role-based access control allows you to assign one or more roles per user. This also lets you individually assign access permissions with the role model. The goal of this is to ensure that the access permissions allow the users to perform their activities without having to make any additional modifications.
RBAC is implemented and monitored by an identity access management system (IAM). This system primarily supports companies with a large number of employees in recording, monitoring, and updating all identities and access permissions. Assigning permissions is called “provisioning”, and removing permissions is called “de-provisioning”. In order to use this kind of system, a uniform standardized role model must be established.
Self-service portals allow users to modify their permissions themselves. When a change is made, the system automatically alerts the administrators. They can then immediately reverse the changes if need be.
How do you create an RBAC?
Role-based access control is based on a three-level structure consisting of users, roles and groups. In role mining, organizations define roles which are usually based on the organizational structure of the company. Each employee is then assigned one or more roles which in turn consist of one or more access permissions. One or more groups are also assigned to a role, which are not necessarily the same.
In most cases, the pyramid approach is suitable when creating the role model:
The top level: permissions for all employees
At the top level, you will find the permissions required by all employees in the organization. These typically include access to the intranet, Office suite, email client, shared network directory, and login access via Active Directory.
The second level: departments
In an organization, employees working in the same department carry out similar activities. For example, the finance department needs access to the ERP system and the department drive, while the HR department needs access to all employee data. The corresponding permissions are assigned to all employees within a department.
The third level: responsibilities
Additional permissions are defined based on the employees’ responsibilities and corresponding tasks.
Team leaders know their employees’ tasks best. It is, therefore, recommended to include them in the process of defining roles. By using an IAM system, permissions can automatically be requested and confirmed with the department heads.
The bottom level: roles
In many cases, employees must perform activities that were not previously covered by the role request for their department and responsibilities. Therefore, the organization will ultimately assign each employee additional roles that they need for their actual tasks.
Data sources for RBAC
To define and assign roles, the employee data of an organization needs to be complete and up to date. Detailed records of this data are logged in the HR system, primarily in larger companies. When creating a model for the roles and permissions, it is also recommended to incorporate roles that may not be filled at the moment. These roles typically include interns in a department or positions that have not been filled for a long time.
Advantages and disadvantages of RBAC
In some cases, role-based access control has been accepted as the best-practice model. If the model for the roles and permissions has been defined and has been implemented and enforced throughout the company, RBAC can offer numerous advantages:
- Flexibility: The company only assigns roles to an employee as required. Any modifications to the organizational structure or permissions are quickly applied to all employees when the company modifies the corresponding role.
- Reduced administration work: RBAC has rendered the time-consuming process of individually assigning permissions obsolete.
- Less error prone: Assigning permissions individually is a more complex process and is thus more error prone than using role-based access control for assigning permissions.
- Increased efficiency: Reducing the amount of work and error rate increases the efficiency of IT and other employees. There is no longer any need for manual modifications, error handling, wait times or individual permission requests.
- Security: Access permissions are defined exclusively via the role model which prevents you from giving more permissions than needed to individual employees. This is in line with the Principle of Least Privilege (PoLP).
- Transparency: The naming of roles is usually straightforward and thus increases transparency and comprehensibility for users.
Role-based access control also has some disadvantages:
- Labor-intensive setup: Translating organizational structures into the RBAC model requires a lot of work.
- Temporary assignments: If a user only needs extended access permissions temporarily, it is easier to forget about them when using RBAC than when assigning permissions individually.
- Application: In small companies, creating and maintaining roles would be more labor intensive than assigning permissions individually. Therefore, the RBAC model is only used when a certain number of roles and employees has been reached. However, even in large companies, role-based access control suffers from the drawback that it is easy to end up creating a large number of roles. If a company has ten departments and ten roles, this will already result in 100 different groups.
When is RBAC used?
In many organizations, role-based access control has been accepted as the best method for managing access permissions. In addition, the RBAC model is also used in operating systems and other software, such as the Microsoft Windows Server Active Directory, the highly secure Linux operating system SELinux, and the Unix operating system Solaris.