Access In A Controlled Manner

Reading Time: 9 minutes

Access Control mechanisms enforce policies, preventing unauthorized access while allowing legitimate entities to engage with services securely in a B2C and/or B2B SaaS solution environment. Access Control is an essential component in any CIAM integration for ensuring security.

My name’s Peter Fernandez, and in this article, I’m going to explore various aspects of Access Control and the mechanisms that can be employed in authorization scenarios within a CIAM context.

What is Access Control?

Access Control is the security technique used to regulate who or what can view or use resources within a system. The goal is to ensure that only authorized individuals or systems are permitted to access certain resources while denying access to those that aren’t.

The general concept of Access Control applies to both physical and digital resources and is a fundamental element of any (cyber) security solution. In a CIAM context, access control mechanisms ensure that only authorized access is permitted to data or digital services, and is typically aligned with roles, privileges, and/or authorization levels.

It is especially critical in B2C and/or B2B SaaS customer-facing solutions, where personal and sensitive data are typically involved, and offers the following benefits:

• Protection of User Data: Robust access control mechanisms ensure that unauthorized users cannot access or manipulate this data.
• Ensuring Regulatory Compliance: Regulations such as GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act) mandate that organizations handle customer data responsibly. Access control mechanisms help enforce these regulations by ensuring that only authorized users have access to sensitive customer data.
• Minimizing Risk: By restricting access to authorized users only, access control helps minimize the risk of data breaches, fraud, or misuse of customer data.
• Enhancing User Experience: A seamless and secure authentication process combined with precise access control can improve the overall user experience by providing convenience while maintaining privacy and security.

Mandatory Access Control (MAC)

Mandatory Access Control (MAC) is the most common, where access permissions are determined by a central authority and which users cannot modify. MAC is often based on predefined policies that specify what users and systems can access based on factors such as user roles, (user) relationships, data classification levels (e.g., confidential, top secret), etc.

As an example, certain customer data (e.g., health records or financial records) may have access controls determined by an organization that subsequently define who, or what can access that information.

• Pros: High level of security, ensures compliance with regulatory standards.
• Cons: Less flexibility for end-users which may lead to more complex administration processes.

Discretionary Access Control (DAC)

In contrast to MAC, Discretionary Access Control offers the owner of a resource the discretion to determine who can access it and to what extent. This allows users or groups to share access to resources based on personal preferences.

In a CIAM context, DAC can be used for user-generated content or self-service account settings, or for situations involving delegation. For instance, a customer may decide to share specific data — to which they have been granted access — with a third-party application or service. The owner (the customer) has the ability to grant or revoke access to that data, offering greater control over the information.

• Pros: Flexibility for end-users, minimal overhead for administrators.
• Cons: Can be difficult to manage at scale, as users may make inconsistent decisions regarding data sharing.

Permission

Permission typically plays a fundamental part in determining Access Control, and is typically categorised in two ways:

• User Permissions: For a user, this may have a bearing on what functionality is available via the user interface experience and will ultimately impact the explicit function(s) the user can perform.
• Client Permissions: For a client/machine — i.e. an account in a non-user context — permission will determine what functionality is available and, by virtue, the operations that can be performed.

In the context of user Access Control, permission often goes hand-in-hand with consent, where a user explicitly controls what access is granted to a system acting on their behalf. You can read more about the topic of consent in my article entitled

Access Control Models

Irrespective of whether the access is mandatory or discretionary, various models of control can be employed to address the numerous authorization scenarios within a CIAM context. These models differ in terms of how access permissions are granted and how rules are applied to manage user interactions with resources, and they can be deployed in various combinations to achieve the desired outcome.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) assigns permissions based on the roles users hold within an organization. Instead of managing individual permissions, administrators assign users to specific roles, and each role has a set of permissions linked to it; with access to resources being determined based on these roles.

RBAC is highly effective in a CIAM context for segmenting customers based on different use cases or subscription levels. For example, users with a “premium” role might have access to certain exclusive features or data, while “basic” users have limited access. RBAC simplifies access control management by organizing users into roles rather than managing permissions individually.

• Pros: Easy to manage and scale, helps to prevent privilege creep (when users accumulate more permissions than necessary).
• Cons: Less granular than other models, as users are often assigned predefined roles. Where multiple roles must be defined/assigned the notion of “role explosion” can become a difficult situation to manage.

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) enables access decisions based on a wide range of attributes, including user characteristics, environmental conditions, and resource properties. These attributes can include things like time of day, location, device used, user consent, and more.

ABAC can be highly effective in a CIAM system by providing a dynamic approach to access control based on real-world characteristics. For instance, access to certain customer data could be contingent upon the user’s geographical location or the type of device they’re using. This approach allows for more flexibility and customization in managing access.

• Pros: Flexible and adaptable to different contexts.
• Cons: Can be complex to implement and manage due to the number of attributes involved.

Relationship Based Access Control (ReBAC)

Relationship-based Access Control defines a paradigm where access is defined by the relationship(s) between the various objects — e.g. users and the resources provided.

ReBAC can be used to model extremely complex scenarios, providing a fine-grained approach to access control, and can also be used to emulate many of the capabilities provided by RBAC, ABAC or the other models.

• Pros: A more flexible, finer granularity for modelling access control.
• Cons: Complex modelling typically requires extensive resources; ideally implemented via an independent access control service.

Other Access Control Models

Whilst RBAC, ReBAC and ABAC are arguably the most common access control models, others exist that can also be deployed in a combinatorial fashion, and include the likes of:

• Context-Based Access Control (CBAC): takes ABAC a step further by considering the context of an access request. This could include situational factors such as the user’s past behaviour, current status, or even the type of transaction.
• Policy-Based Access Control (PBAC): a strategy for managing user access to systems and resources based on additional policies and rules, rather than just roles. 
• etc.

Access Control Lists (ACLs)

ACLs are often used to define who can access specific resources and what actions they can perform. ACLs are used to manage permissions for customer data and services, and can also be used in combination with the various access control models discussed above.

For example, an ACL can specify that a particular user role has read-only access to a product catalogue, say, while another role has full access to both view and purchase items.

Access Control Policy

An access control policy is a set of rules that govern who can access certain resources, how they can access them, and under what conditions. Policies ensure that entities — whether customers, employees, third-party users or automated system services — are granted the appropriate level of access to applications, data, or other digital resources.

Policies help organizations balance security with usability, protecting sensitive customer data and ensuring compliance with privacy regulations, such as GDPR. Access control policies are typically based on a combination of user attributes, roles, relationships, actions, and context(s) (e.g., time, location, or device), etc.

Whilst Access Control policies can be pivotal — determining who or what can access resources, under which conditions, and for what purposes — the management and enforcement of these policies typically requires more than just a simple decision-making process. As a consequence, policy architecture often involves several key components that work together, typically referred to as Policy Enforcement Point (PEP), Policy Information Point (PIP), and Policy Decision Point (PDP).

Policy Enforcement Point (PEP)

A Policy Enforcement Point (PEP) is the component responsible for enforcing access control decisions made by the Policy Decision Point (PDP). When a user attempts to access a resource or perform an action, the PEP acts as the gatekeeper, intercepting the request and enforcing the decision that was made.

The role of the PEP is to ensure that only those who have been authorized by the PDP can access a resource and that any conditions or restrictions set by the policy are met. If a request is authorized, the PEP grants access to the resource; if not, the PEP denies access. The key functions of a PEP include:

• Intercepting Access Requests: The PEP monitors and intercepts user requests to access resources.
• Enforcing Policy Decisions: It ensures that the access control decisions made by the PDP are applied, including any restrictions or conditions set by the access policy.
• Communicating with PDP: The PEP sends requests to the PDP to determine whether access should be granted based on the policy.
• Logging and Auditing: The PEP often tracks and logs access attempts for auditing purposes, which is crucial for compliance, reporting, and troubleshooting.

For example, a customer might request to access their account settings. The PEP intercepts the request and sends it to the PDP for authorization. If the policy allows the customer (based on attributes like subscription level, age, or location) to make changes, the PEP will grant access. If the customer is restricted from making those changes (perhaps due to a lack of permission), the PEP will deny the request and inform the user.

Policy Information Point (PIP)

A Policy Information Point (PIP) is a component responsible for providing the necessary information required to make an access control decision. The PIP stores and retrieves data about the user, the environment, and the resources being requested. This data might include attributes about the user’s role, their location, the time of the request, or the type of device they are using.

The PIP plays a crucial role in ensuring that access decisions are made based on the most accurate and up-to-date information. It supplies the Policy Decision Point (PDP) with the attributes it needs to evaluate whether access should be granted or denied according to the policy. Key Functions of the PIP include:

• Storing and Managing Attributes: The PIP manages various attributes related to users, resources, and the environment. These attributes are vital in making informed decisions.
• Retrieving User Data: It can retrieve attributes such as user roles, subscription levels, or context-specific details (e.g., location, time, and device).
• Feeding Data to PDP: The PIP provides the PDP with the data needed to evaluate access requests. For example, if a policy is based on a user role, the PIP would retrieve the user’s role from the system.

Policy Decision Point (PDP)

The Policy Decision Point (PDP) is the component responsible for evaluating the access request based on the policies defined by an organization. Once it receives all the necessary information from the PIP, it evaluates the request against the relevant access control policies.

The PDP then makes an authorization decision — i.e. whether to allow or deny the request — and provides this decision to the PEP for enforcement. The PDP’s role is critical in ensuring that decisions are consistent with the organization’s security and authorization policies, and some of its key functions include:

• Evaluating Access Requests: The PDP evaluates whether a user’s request complies with the access control policies, using information provided by the PIP.
• Making Authorization Decisions: Based on the policy evaluation, the PDP decides whether the request is authorized or denied.
• Return Decision to PEP: The PDP communicates the decision to the PEP, which enforces it.
• Handling Complex Policies: The PDP can support complex policies, such as those based on user roles, attributes, time of day, device, or even environmental factors.

Interaction Between PEP, PIP, and PDP

The effective enforcement of access control policies relies on the interaction between the PEP, PIP, and PDP. These components work together to make and enforce decisions about access based on user attributes, roles, and the policies in place.

1. User Makes a Request – The process begins when a user attempts to access a resource, such as a customer trying to access their profile or a specific SaaS service.
2. PEP Intercepts the Request – The PEP intercepts the access request and determines that the request must be evaluated against access control policies. It sends the request to the PDP for a decision.
3. PIP Provides Information – The PDP requires information about the user and the PIP provides this information by querying data sources, like the CIAM account store or user database.
4. PDP Makes a Decision – With the information from the PIP, the PDP evaluates whether the user is authorized to access the requested resource. It does so by comparing the data with the access control policies in place.
5. PEP Enforces the Decision – Once the PDP returns a decision, the PEP enforces it. If access is granted, the PEP allows the user to proceed. If access is denied, the PEP prevents access and may notify the user about the denial reason.

The Policy Lifecycle

An access control policy is typically organic, with a lifecycle that often involves several stages:

• Policy Creation: Defining policies based on user roles, attributes, and access requirements.
• Policy Evaluation: The PDP evaluates access requests against the policies.
• Policy Enforcement: The PEP enforces the decision(s) made by the PDP.
• Policy Monitoring: Tracking and auditing access requests for compliance and security purposes.
• Policy Adjustment: Revising policies based on evolving requirements, risks, or regulations.

Considerations for Policy-Based Access Control

With a policy-based approach, organizations can implement comprehensive and effective access control systems that protect sensitive customer data while providing a seamless and secure user experience.

However, implementing policy-based access control relies on a well-designed architecture that includes the Policy Enforcement Point (PEP), Policy Information Point (PIP), and Policy Decision Point (PDP). Building and maintaining these components to ensure that access requests are evaluated accurately and that security policies are enforced consistently, provides for a robust solution, though the effort required can be considerable.