Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) is a dynamic and context-aware access control model that grants or denies user access to user journeys based on attributes associated with users and their context.

Unlike traditional access control models like Role-Based Access Control (RBAC), which rely on predefined roles, ABAC evaluates policies at runtime using user profile attributes and authentication context to make fine-grained access decisions.

In ReachFive, ABAC allows you to control who can enter a user journey (signup, login, or access to an application) and what rights are granted once access is allowed Coming soon.

ABAC is evaluated during authentication and relies primarily on user profile attributes, such as verified identifiers, custom fields, or roles defined on the user profile.

These attributes can include:

  • User profile attributes (for example, verified email, country, custom fields)

  • User roles or classifications (for example, staff, senior_staff, admin)

    You can create these using Custom fields.

  • Authentication context (for example, login method or assurance level)

ABAC policies are evaluated dynamically and consistently across all user access points.

Why use ABAC? 🤔

ABAC is designed for use cases where access decisions go beyond simple authentication success.

Key benefits include:

  • Preventing unauthorized access early: Block users from entering signup or login journeys when required attributes are missing or invalid.

  • Fine-grained access control: Define access rules based on real user data rather than static roles.

  • Coming soon Personalized authorization: Grant different levels of access or capabilities after authentication using access token claims.

  • Scalable and flexible design: Update access rules without redesigning applications or duplicating logic.

ABAC is particularly useful for:

  • Restricting access to applications based on user role or profession

  • Preventing login with unverified identifiers

  • Enforcing eligibility rules before authentication completes, such as age or location restrictions

  • Supporting multi-portal or multi-brand architectures

  • Delivering personalized authorization through access tokens

ABAC flow

abac flow

At a high level per Rule Type:

  • Forbid Access

  • Allow Access

  1. A user attempts to access a public journey (signup or login).

  2. ReachFive evaluates ABAC rules using user profile attributes.

  3. If rules match, access is blocked.

  4. If rules do not match, authentication completes.

  5. Coming soon Access token claims are issued based on user attributes.

  1. A user attempts to access a public journey (signup or login).

  2. ReachFive evaluates ABAC rules using user profile attributes.

  3. If rules match, authentication completes.

  4. If rules do not match, access is blocked.

  5. Coming soon Access token claims are issued based on user attributes.

ABAC layers in ReachFive

ABAC in ReachFive operates at two complementary layers.

Layer 1: Controlling access to user journeys

The first layer controls whether a user is allowed to enter a user journey, such as signup or login.

At this stage, ReachFive evaluates user profile attributes against access rules before completing authentication.

Examples:

  • Block login attempts using unverified identifiers.

  • Prevent access if required attributes are met or not met depending on Rule Type.

  • Restrict login based on user classification or status.

This layer expands existing security capabilities, such as Forbid unverified identifiers login, which is now managed as part of Access Control rather than Attack Protection.

Layer 2: Granting personalized access after authentication

Coming soon

Once a user is authenticated, ABAC can enrich the access token with claims derived from user attributes.

These claims allow applications to enforce authorization decisions downstream.

As of 2026-03-09, this layer is currently still in development and not yet available in the ReachFive Console.

Examples:

  • Grant access to different portals based on user role.

  • Enable or disable features based on custom attributes.

  • Apply business-specific authorization logic.

Applications can inspect access token claims to determine whether a user is allowed to proceed.

ABAC and access tokens

When ABAC policies are applied successfully, ReachFive can include selected attributes or roles directly in the access token.

For example:

  • A role claim indicating the user’s role

  • Custom claims derived from user profile attributes

Applications can then evaluate these claims:

  • If role = senior_staff, allow access

  • Otherwise, block or redirect the user

This approach keeps authorization logic simple and consistent across applications.

Create ABAC rules in the ReachFive Console

Attributes used by ABAC are defined and managed directly from the ReachFive Console. Once defined, these attributes can be referenced in ABAC rules.

abac overview

You create rule groups where multiple attributes are evaluated together to determine if a user can authenticate or not.

  • The attributes within a group use AND logic, meaning all attributes must match for the user to match the group criteria.

  • The attributes between groups use OR logic, meaning if a user matches any group, they will be denied access.

When creating a group, the console dynamically updates how many of your users match the currently selected criteria.

To create a new rule in the ReachFive Console:

View from the console

abac create rule

  1. Go to Settings  Access Control  Signups & Logins.

  2. Click New Rule.

  3. Define the Key (snake_case).

  4. Give the rule a Description.

  5. Select the Rule Type.

    • Forbid Access

    • Allow Access

  6. Select Forbid all for one or more of the following:

    • Signup

    • Login

    • Login after Signup Coming soon

  7. Define the attributes and values to evaluate for this rule group.

    Repeat this for additional groups.

    Example group

    User - Email Verified is false

    AND

    User Authentication - Identifier type is email

  8. Define a User Error Message to display when access is denied.

    This is a user friendly message that explains why access was blocked and what the user can do to resolve it (if applicable).

    Multilingual support

    All supported languages are available for localisation. When added, the language code (e.g., En for English, Fr for French) turns green to the signal a customisation has been added.

Best practices

  • Keep access rules simple and explicit

  • Prefer verified attributes for access decisions

  • Use access token claims for application-level authorization

  • Document attribute meaning and expected values

  • Test rules across multiple user scenarios

R5 AI Assistant
The R5 AI assistant can make mistakes, verify answers.

Confirm Deletion