What is the process that provides a user with permission including access levels and abilities?

Learn about role-based access control (RBAC) in Data Protection 101, our series on the fundamentals of information security.

Role-based access control (RBAC) restricts network access based on a person's role within an organization and has become one of the main methods for advanced access control. The roles in RBAC refer to the levels of access that employees have to the network.

Employees are only allowed to access the information necessary to effectively perform their job duties. Access can be based on several factors, such as authority, responsibility, and job competency. In addition, access to computer resources can be limited to specific tasks such as the ability to view, create, or modify a file.

As a result, lower-level employees usually do not have access to sensitive data if they do not need it to fulfill their responsibilities. This is especially helpful if you have many employees and use third-parties and contractors that make it difficult to closely monitor network access. Using RBAC will help in securing your company’s sensitive data and important applications.

Examples of Role-Based Access Control

Through RBAC, you can control what end-users can do at both broad and granular levels. You can designate whether the user is an administrator, a specialist user, or an end-user, and align roles and access permissions with your employees’ positions in the organization. Permissions are allocated only with enough access as needed for employees to do their jobs.

What if an end-user's job changes? You may need to manually assign their role to another user, or you can also assign roles to a role group or use a role assignment policy to add or remove members of a role group.

Some of the designations in an RBAC tool can include:

Management role scope – it limits what objects the role group is allowed to manage.
Management role group – you can add and remove members.
Management role – these are the types of tasks that can be performed by a specific role group.
Management role assignment – this links a role to a role group.

By adding a user to a role group, the user has access to all the roles in that group. If they are removed, access becomes restricted. Users may also be assigned to multiple groups in the event they need temporary access to certain data or programs and then removed once the project is complete.

Other options for user access may include:

Primary – the primary contact for a specific account or role.
Billing – access for one end-user to the billing account.
Technical – assigned to users that perform technical tasks.
Administrative – access for users that perform administrative tasks.

Managing and auditing network access is essential to information security. Access can and should be granted on a need-to-know basis. With hundreds or thousands of employees, security is more easily maintained by limiting unnecessary access to sensitive information based on each user’s established role within the organization. Other advantages include:

Reducing administrative work and IT support. With RBAC, you can reduce the need for paperwork and password changes when an employee is hired or changes their role. Instead, you can use RBAC to add and switch roles quickly and implement them globally across operating systems, platforms and applications. It also reduces the potential for error when assigning user permissions. This reduction in time spent on administrative tasks is just one of several economic benefits of RBAC. RBAC also helps to more easily integrate third-party users into your network by giving them pre-defined roles.
Maximizing operational efficiency. RBAC offers a streamlined approach that is logical in definition. Instead of trying to administer lower-level access control, all the roles can be aligned with the organizational structure of the business and users can do their jobs more efficiently and autonomously.
Improving compliance. All organizations are subject to federal, state and local regulations. With an RBAC system in place, companies can more easily meet statutory and regulatory requirements for privacy and confidentiality as IT departments and executives have the ability to manage how data is being accessed and used. This is especially significant for health care and financial institutions, which manage lots of sensitive data such as PHI and PCI data.

Best Practices for Implementing RBAC

Implementing a RBAC into your organization shouldn’t happen without a great deal of consideration. There are a series of broad steps to bring the team onboard without causing unnecessary confusion and possible workplace irritations. Here are a few things to map out first.

Current Status: Create a list of every software, hardware and app that has some sort of security. For most of these things, it will be a password. However, you may also want to list server rooms that are under lock and key. Physical security can be a vital part of data protection. Also, list the status of who has access to all of these programs and areas. This will give you a snapshot of your current data scenario.
Current Roles: Even if you do not have a formal roster and list of roles, determining what each individual team member does may only take a little discussion. Try to organize the team in such a way that it doesn’t stifle creativity and the current culture (if enjoyed).
Write a Policy: Any changes made need to be written for all current and future employees to see. Even with the use of a RBAC tool, a document clearly articulating your new system will help avoid potential issues.
Make Changes: Once the current security status and roles are understood (not to mention a policy is written), it’s time to make the changes.
Continually Adapt: It’s likely that the first iteration of RBAC will require some tweaking. Early on, you should evaluate your roles and security status frequently. Assess first, how well the creative/production process is working and secondly, how secure your process happens to be.

A core business function of any organization is protecting data. An RBAC system can ensure the company's information meets privacy and confidentiality regulations. Furthermore, it can secure key business processes, including access to IP, that affect the business from a competitive standpoint.

Tags: Data Protection 101

Solve your authorization

Watch this webinar to see how one company solved their authrization problems with Auth0.

Authorization is the process of giving someone the ability to access a resource.

Of course, this definition may sound obscure, but many situations in real life can help illustrate what authorization means so that you can apply those concepts to computer systems.

A good example is house ownership. The owner has full access rights to the property (the resource) but can grant other people the right to access it. You say that the owner authorizes people to access it. This simple example allows us to introduce a few concepts in the authorization context.

For instance, accessing the house is a permission, that is, an action that you can perform on a resource. Other permissions on the house may be furnishing it, cleaning it, repair it, etc.

A permission becomes a privilege (or right) when it is assigned to someone. So, if you assign permission to furnish your house to your interior decorator, you are granting them that privilege.

On the other hand, the decorator may ask you permission to furnish your house. In this case, the requested permission is a scope, that is, the action that the decorator would like to perform at your house

Sometimes authorization is somewhat related to identity. Think of the process of boarding a plane. You have your boarding pass that states you are authorized to fly with that plane. However, it is not enough for the gate agent to let you get on board. You also need your passport stating your identity. In this case, the gate agent compares the name on the passport with the name on the boarding pass and let you go through if they match.

In the authorization context, your name is an attribute of your identity. Other attributes are your age, your language, your credit card, and anything else relevant in a specific scenario.

Your name written on the passport is a claim, that is, a declaration stating you've got that attribute. Someone reading your name on your passport can be sure of your name because they trust the government that issued your passport.

The boarding pass, along with the proof of identity of consumers, represents a kind of ‘access token’ that grants access rights to jump onto the plane.

In the scenarios described above, you can see that the act of authorizing enables entities to execute tasks that other entities are not allowed to complete.

Computer systems that use authorization work in a similar manner.

In computer systems, authorization rules are part of an IT discipline called Identity and Access Management (IAM). Within IAM, authorization and authentication help system managers to control who has access to system resources and set client privileges. The way that IT systems deal with authorization services is very similar to a real-world access control process.

Consider a collaboration tool like Google Docs.

The application allows you to create and share documents. Other permissions include being able to update, delete, comment on a document. If you are the owner of a document, you can share it with someone else and define one or more access policies. For example, you can share your document with someone by letting them just add comments.

In this scenario:

Resource: it’s the document

Resource Owner: this is the user that creates a document, the owner of the document

Authorized User: the user who is given comment rights by the Resource Owner

The following diagram represents the authorization to resource access:

There are several different authorization strategies that computer systems leverage during application deployment. The most prominent ones are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Recently, Auth0 has been investigating and solving for Relationship Based Access Control (ReBAC). There are multiple other alternatives, including Graph-Based Access Control (GBAC) and Discretionary Access Control (DAC). Each one of these strategies will help application developers deal with different authorization requirements and authorization services.

When using ABAC, a computer system defines whether a user has sufficient access privileges to execute an action based on a trait (attribute or claim) associated with that user. An example use case of this authorization process is an online store that sells alcoholic beverages. A user of the online store needs to register and provide proof of their age. In the authorization context, this scenario can be described as follows:

The online store is the resource owner
The alcoholic beverage is the resource
The age of the consumer validated during the registration process is a claim, that is the proof of the user’s age attribute

Presenting the age claim allows the store to process access requests to buy alcohol. So, in this case, the decision to grant access to the resource is made upon the user attribute.

RBAC, on the other hand, treats authorization as permissions associated with roles and not directly with users. A role is nothing but a collection of permissions. For example, imagine that you work as a department manager in an organization. In this situation, you should have permissions that reflect your role, for example, the ability to approve vacation requests and expense requests, assign tasks, and so on. To grant these permissions, a system manager would first create a role called "Manager" (or similar). Then, they would assign these permissions to this role and would associate you with the "Manager" role. Of course, other users that need the same set of permissions can be associated with that role.

The advantage of using RBAC is that managing authorization privileges becomes easier because system managers can deal with users and permissions in bulk instead of having to deal with them one by one.

Relationship Based Access Control examines the following question in regards to authorization: “Does this user have a sufficient relationship to this object or action such that they can access it?” The relationship can come via a user attribute, such as being a member of a role group related to the object, or having a direct relationship, such as being shared on a document. Sometimes a traversal of a graph of groups, roles, organizations, and objects requires exploring many nodes to establish a relationship between a user and what they are trying to do. Which relationships are critical to gaining access and the permissions that those relationships grant is up to the implementer of the ReBAC system.

Auth0 has recently released a Developer Community Preview for our upcoming Auth0 Fine Grained Authorization product, based on ReBAC. You can learn more at our developer preview page for Fine Grained Authorization.

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.

Sorry that was Incorrect... Try Again?