Authorization Methods

Authorization is the process of giving someone the ability to access a digital resource. There are many ways to grant access to users in enterprise organizations.
 

• Role-based access control (RBAC): Also known as non-discretionary access control, this authorization strategy bases user access on assigned roles.
   

• Policy-based access control (PBAC): Dynamically determines access privileges during authorization based on policies and rules.
   

• Attribute-based access control (ABAC): Attribute-based access control uses attributes to determine a user's access to resources in an application.
   

• Privileged Access Management (PAM): A security mechanism that safeguards identities with special access or capabilities beyond regular users.
   

Role-based access control (RBAC)

RBAC is an authorization approach that bases user access on a user’s role within an organization. 

Data privacy regulations, enterprise security requirements, and customer experience concerns make it critical for organizations to control access to networks and data. The goal of access control measures such as RBAC is to keep unauthorized users from accessing sensitive information that they don’t need or shouldn’t be able to see, whether on-premises or cloud-based.

With RBAC, after a user is authenticated, RBAC determines what they can access based on their role within the organization or system. This role could be defined by job title, department, location, or the user’s specific responsibilities.

This strategy also makes it easier for administrators to manage which users have access to sensitive documents, records, and programs and allows them to set permissions based on a user's role instead of managing permissions for each user individually. 

Additional benefits include:
 

• Streamlined setup: Predefined roles make RBAC largely plug-and-play for the IT department, reducing work when onboarding new employees.
  
  
• Quick changes and terminations: When an employee leaves the company or changes jobs, their resource access can be revoked or changed to a new role. 
  
  
• Regulatory compliance: When access is based on roles, administrators are less likely to make mistakes by giving the wrong people access to sensitive data, which can improve compliance.
  

RBAC and other access control mechanisms can also be used to grant or deny access to stored data based on consumer consent directives. This helps organizations adhere to data privacy regulations such as the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA).
 

How does RBAC work?

With RBAC, users in a system are only granted access to information that directly relates to their role in the system. Access is granted based on factors such as authority, responsibility, and competence. Using RBAC, employees can only access the information needed to effectively perform their jobs.

For example, an entry-level IT department employee doesn't need access to sensitive financial documents to perform their job, but a senior manager working in the sales department does.

All RBAC models contain the following core elements:
 

• Administrators: The users who identify roles and grant permissions.
  
  
• Roles: The users grouped together based on the work they perform.
  
  
• Permissions: The actions and access granted to each role that define what those roles are permitted to do.

RBAC allows administrators to create, assign, and control access permissions for each role within a system. 

How do permissions work?

Permissions specify what a user can access and what they can do in a system based on their role in the organization. For example, access permissions for confidential payroll documents might include:
 

• Reading: Which roles can open and read the documents?
  
  
• Writing: Which roles can make changes to the documents?
  
  
• Sharing: Which roles can download, email, or print documents?

After a role is defined, permissions are assigned accordingly.

Note that while often easy to implement, RBAC is a static form of authorization and cannot be easily updated when organization access policies change.

Types of Role-based Access Control (RBAC)

The National Institute of Standards and Technology (NIST) defines multiple RBAC models tailored for various organizational requirements:

Flat RBAC

Flat RBAC assigns at least one role to each user, with the option of assigning multiple roles as needed. When users need new privileges, additional roles must be explicitly granted. For instance, a marketing analyst who needs temporary project management access would require an additional role assigned for the duration of the project.

Hierarchical RBAC

Hierarchical RBAC establishes a clear organizational structure where roles are layered based on seniority and responsibilities. Senior roles inherit the permissions of their subordinate roles. For example, a senior network administrator would automatically have all the privileges of a junior administrator, plus additional permissions specific to higher-level tasks.

Constrained RBAC

Constrained RBAC introduces "separation of duties" (SoD), a concept designed to mitigate risk by spreading critical tasks across multiple roles. Under this approach, tasks like deploying code or making financial transfers require approval from multiple roles. For example, a software engineer wanting to deploy a critical update might need authorization from both their direct supervisor and the head of cybersecurity, reducing the risk of unilateral, potentially harmful actions.

Symmetric RBAC

Symmetric RBAC involves regular and systematic reviews of all roles and their privileges. Periodic evaluations ensure access remains aligned with current job functions and company policies. During these reviews, unnecessary permissions are revoked, new permissions may be added, and outdated roles are eliminated, effectively combating privilege creep.

Policy-based access control (PBAC)

PBAC is an authorization approach that uses policies to determine user access privileges. Similar to how RBAC works, user roles and the associated permissions are reviewed to determine access, but additional attributes are also evaluated. 

In large organizations, it’s not always possible to create roles for each combination of access privilege, and some things, such as sign-on time of day or location, cannot be captured using RBAC. With PBAC, access is not only determined by role and associated permissions, but also by a variety of other attributes, providing finer-grained control capabilities.

Additional benefits include: 
 

• Flexibility and speed: Administrators have greater control over the level of access and can add, remove, or edit permissions to a large number of users at once.
   

• Adaptability: Policies can address a wide range of dynamic attributes and contextual controls, such as time or location-bound access restrictions.
   

• Observability: Policies are human-readable and make it easier to view the relationship between identities and resources.
  
  

How does PBAC work?

Administrators create access policies based on user roles and attributes and establish rules regarding these roles and attributes that dynamically determine access. Decisions are made according to context and risk when access is requested.

These policies also determine which permissions they have after they access the resource. They can determine whether users only have read-access, or whether they can make changes to the item or share it with others.

Policies can be based on a wide variety of different attributes, including:
 

• Name

• Organization

• Job title

• Security clearance

• Owner

• Creation date

• File type

• Time of day

• Location of access

• Threat level

PBAC gives administrators the flexibility to add fine-grained access control to online resources based on policies and rules. While more powerful and flexible, PBAC methods are also often more complex and expensive to implement than RBAC methods.
 

Attribute-based access control (ABAC)

ABAC is an authorization approach that uses attributes, or characteristics, to dynamically determine user access privileges. 

Similar to PBAC, administrators create access policies based on user roles and attributes and establish rules regarding these roles and attributes that dynamically determine access. Decisions are made according to context and risk when access is requested.

However, PBAC focuses on policies that grant or deny user access to a resource, and ABAC focuses on the specific attributes that influence the policies.

Benefits of using ABAC include:
 

• Granularity: Because it uses attributes rather than roles to specify relationships between users and resources, administrators can create precisely targeted rules without needing to create additional roles.  
   

• Flexibility: Rather than modifying rules or creating new roles, administrators need only assign the relevant attributes to new users or resources.
   

• Adaptability: Administrators can modify attributes and create context-sensitive rules to meet their needs. 
   

How does ABAC work?

With ABAC, when users attempt to access resources, policies enforce access decisions based on the attributes of the subject, resource, action, and environment involved.

Practical Examples of Attributes in ABAC

To understand ABAC clearly, consider the following key attribute categories:

• User Attributes: Information specifically about the individual, such as:
  • Job title (e.g., Manager, Analyst)
  • Department (e.g., HR, Finance, IT)
  • Employment status (e.g., full-time, contractor, intern)
  • Security clearance level (e.g., confidential, top-secret)
• Resource Attributes: Details about the resource being accessed, including:
  • Resource type (e.g., financial report, customer record, medical file)
  • Sensitivity level (e.g., public, internal, restricted)
  • Ownership details (e.g., who created or manages the file)
• Environmental Attributes: Context-specific factors at the time of access
  • Location of access attempt (e.g., remote, in-office, public network)
  • Time-related parameters (e.g., time of day, business hours)
  • Device or network status (e.g., trusted device, secure network)

These attributes interact dynamically through clearly defined conditions such as:

• Subject (Who): Is the employee in finance or engineering?
• Object (What): Is the user trying to access sensitive payroll data or general company documentation?
• Operation (Action): Is the user attempting to view, modify, delete, or transfer information?

For example:

• If the user is a senior manager and is logging in from the corporate network, then allow editing privileges for confidential documents.
• If the access request occurs outside of business hours or from a high-risk location, then require multi-factor authentication.

Like PBAC, administrators have fine-grained access control to online resources based on policies and rules. And like PBAC, ABAC are more powerful and flexible than RBAC methods, ABAC methods are also often more complex and expensive to implement.
 

Similarities and differences between RBAC, PBAC, and ABAC

Important similarities and differences between the three authorization methods include:
 

• RBAC grants access based on user roles, PBAC grants access based on policies, and ABAC grants access based on attributes, or characteristics, of the user, resource, and environment involved during sign-on.
   

• Like PBAC, ABAC provides a more fine-grained, dynamic approach to authorization than RBAC, and is more complex and expensive to implement.
  However, they also lead to better security, flexibility, improved customer experience, and better regulatory compliance than using RBAC, which is not designed to provide the same data access governance and authorization.
  

• PBAC focuses on policies that grant or deny the end user access to a resource, and ABAC focuses on the specific attributes that influence the policies.
   

Privileged Access Management (PAM)

Privileged access management (PAM) uses a combination of people, processes, and technology to safeguard the capabilities of administrators and power users and defend against those who could sabotage a system with a privileged account.

Every technology system maintains security by allocating its users with different levels of access. The principle of least privilege (POLP) dictates that standards users should have the minimum access to the roles and permissions required to perform their work and nothing more.

Administrators have the power to make significant changes to the overall environment, such as adding or deleting users, upgrading and installing hardware and software, performing troubleshooting, backing up data, and managing network security.

Because administrators have the power to significantly alter a network environment, only the most trusted users should have access to these types of accounts. PAM is a form of role-based access control (RBAC), and an essential component of an overall Identity and Access Management (IAM) security protocol.

How does PAM work?

Privileged access users have access to highly sensitive and restricted parts of a technology system that are off-limits to standard users. If a person with malicious intent gets access to a privileged account, it could wreak havoc on a system, with major security and operational consequences.

The concept of PAM helps protect against this possibility by adding additional layers of protection to privileged accounts, and there are several different ways to use it:
 

• Uniform enforcement of multi-factor authentication (MFA) and added layers of authentication for privileged users
  
  
• Frequent auditing of the activities of privileged users by other administrator accounts
  
  
• Storing credentials of privileged users in highly secure password vaults
  
  
• A robust system of monitoring, logging, auditing, and reporting of user sessions to automatically flag anomalous activity