Keycloak ABAC Configuration: Step-by-Step Guide

Last updated: March 2026
Role-Based Access Control (RBAC) works well for straightforward permission models, but many applications eventually need more granular, context-aware authorization. That is where Attribute-Based Access Control (ABAC) comes in. Keycloak’s built-in Authorization Services provide a powerful framework for implementing ABAC without building a custom authorization engine from scratch.

This guide walks through the full process of configuring ABAC in Keycloak, from enabling Authorization Services to evaluating permissions in production.

ABAC vs RBAC: When to Use Which

RBAC assigns permissions based on roles. A user with the “editor” role can edit content; a user with the “viewer” role can only read it. This model is simple to understand and works well when your permission structure maps cleanly to job functions or user types.

ABAC, on the other hand, evaluates access decisions based on attributes — properties of the user, the resource, the action, and the environment. Instead of asking “Does this user have the editor role?”, ABAC asks questions like:

• “Is this user in the same department as the document owner?”
• “Is the request coming from an approved IP range during business hours?”
• “Does this user have a clearance level equal to or higher than the document’s classification?”

Use RBAC when your permissions are relatively static and map to well-defined roles. Most applications start here, and many never need anything more complex. Skycloak’s RBAC features make it straightforward to manage role-based permissions across your Keycloak instances.

Use ABAC when you need fine-grained, context-dependent access decisions that cannot be practically expressed through role assignments alone. Common scenarios include multi-tenant applications, document-level access control, regulatory compliance requirements, and applications where the same role needs different permissions depending on context.

In practice, most organizations use a hybrid approach — RBAC for broad permission categories and ABAC for fine-grained decisions within those categories.

Keycloak’s Authorization Services

Keycloak includes a comprehensive authorization framework built on the User-Managed Access (UMA) specification. This framework provides the building blocks for implementing ABAC without writing authorization logic from scratch.

The authorization model in Keycloak revolves around four core concepts:

• Resources: The things you want to protect (documents, APIs, database records)
• Scopes: The actions that can be performed on resources (view, edit, delete, approve)
• Policies: The rules that determine whether access should be granted or denied
• Permissions: The connections between resources, scopes, and policies

These components work together to answer the question: “Should this user be allowed to perform this action on this resource, given the current context?”

Understanding how these pieces fit together is essential before diving into configuration. A permission ties a resource and scope to one or more policies. When an access decision is needed, Keycloak evaluates the relevant policies and returns a permit or deny decision.

Step 1: Enable Authorization Services on the Client

Authorization Services in Keycloak are configured at the client level. You need an OpenID Connect client with Authorization Services enabled.

1. Log into the Keycloak Admin Console
2. Select your realm
3. Navigate to Clients and select the client you want to configure (or create a new one)
4. Set Client authentication to On
5. Set Authorization to On
6. Click Save

Once enabled, a new Authorization tab appears in the client settings. This tab contains sub-tabs for Resources, Scopes, Policies, Permissions, and Settings.

Under the Settings sub-tab, review the following:

• Policy Enforcement Mode: Set to Enforcing (denies access when no policy matches) for production. Use Permissive during development to allow access when no policy applies.
• Decision Strategy: Choose Unanimous (all policies must grant access) or Affirmative (at least one policy must grant access). Unanimous is the safer default.

Step 2: Define Resources

Resources represent the objects or endpoints you want to protect. Navigate to the Resources sub-tab under Authorization.

Click Create resource and configure:

• Name: A descriptive identifier (e.g., “Document”, “Report”, “User Profile”)
• Display name: A human-readable name for the admin console
• Type: A category string for grouping related resources (e.g., “urn:app:resources:document”)
• URIs: The API endpoints associated with this resource (e.g., “/api/documents/*”)

For a document management application, you might create these resources:

Resource Name	Type	URI
Document	urn:app:resources:document	/api/documents/*
Report	urn:app:resources:report	/api/reports/*
Admin Settings	urn:app:resources:settings	/api/admin/*

A few guidelines for defining resources:

• Be specific enough to be useful but not so granular that you end up with hundreds of resource definitions
• Use consistent naming conventions and type URNs across your application
• Map resources to your domain model, not to individual API routes

Step 3: Define Scopes

Scopes represent the actions that can be performed on resources. Navigate to the Authorization Scopes sub-tab.

Click Create authorization scope and provide a name. Common scopes include:

• view — Read access
• edit — Modify existing resources
• create — Create new resources
• delete — Remove resources
• approve — Approve or publish resources
• export — Export or download resources

After creating scopes, go back to each resource and associate the relevant scopes. Not every scope applies to every resource — for example, “Admin Settings” might only need view and edit, while “Document” might need all six scopes.

Step 4: Create Attribute-Based Policies

Policies are the heart of ABAC. They define the rules that determine access decisions. Navigate to the Policies sub-tab.

Keycloak supports several policy types out of the box:

User Attribute Policies

The most common ABAC pattern uses attributes stored on the user profile. In Keycloak, you can add custom attributes to users under Users > Attributes.

For example, you might add attributes like:

• department: engineering, marketing, finance
• clearance_level: public, confidential, secret
• region: us-east, eu-west, ap-south

To create a policy based on user attributes, select JavaScript as the policy type (or Regex for simpler pattern matching).

JavaScript Policies

JavaScript policies give you full control over authorization logic. Create a new policy with type JavaScript:

Policy Name: Same Department Policy

var context = $evaluation.getContext();
var identity = context.getIdentity();
var attributes = identity.getAttributes();
var userDepartment = attributes.getValue('department').asString(0);

// Get the resource owner's department from resource attributes
var resource = $evaluation.getPermission().getResource();
var resourceAttributes = resource.getAttributes();
var ownerDepartment = resourceAttributes.get('department');

if (ownerDepartment != null && ownerDepartment.contains(userDepartment)) {
    $evaluation.grant();
}

This policy grants access only when the user’s department matches the resource owner’s department.

Policy Name: Business Hours Policy

var context = $evaluation.getContext();
var contextAttributes = context.getAttributes();
var hour = new Date().getHours();

// Allow access only during business hours (8 AM - 6 PM)
if (hour >= 8 && hour < 18) {
    $evaluation.grant();
}

Note: JavaScript policies require the upload-scripts feature to be enabled in Keycloak. In newer versions of Keycloak (v22+), JavaScript providers must be deployed as JAR files rather than written inline. Check your Keycloak version’s documentation for the current approach.

Role-Based Policies (Hybrid ABAC/RBAC)

You can combine ABAC with RBAC by creating role-based policies alongside attribute-based ones. This hybrid approach is often the most practical:

1. Create a Role policy that requires the document-editor role
2. Create a JavaScript policy that checks the user’s department attribute
3. Combine both in a permission with a Unanimous decision strategy

This ensures a user must both have the right role AND belong to the correct department.

Aggregated Policies

Aggregated policies combine multiple policies with a decision strategy. Create a new policy with type Aggregated, then add existing policies and choose:

• Unanimous: All sub-policies must grant access (logical AND)
• Affirmative: At least one sub-policy must grant access (logical OR)
• Consensus: Majority of sub-policies must grant access

Step 5: Create Permissions

Permissions tie everything together by linking resources and scopes to policies. Navigate to the Permissions sub-tab.

Resource-Based Permissions

Click Create resource-based permission:

• Name: “Document Edit Permission”
• Resources: Select “Document”
• Policies: Select the policies that should govern this permission
• Decision Strategy: Unanimous (recommended)

Scope-Based Permissions

For more granular control, create scope-based permissions:

• Name: “Document Delete Permission”
• Resources: Select “Document”
• Scopes: Select “delete”
• Policies: Select a more restrictive set of policies (e.g., require both manager role and same department)

Scope-based permissions let you apply different policies to different actions on the same resource. A user might be allowed to view a document but not delete it, even though both involve the same resource.

Permission Decision Strategy

When multiple permissions apply to the same resource and scope, Keycloak uses the client-level decision strategy (configured in Authorization Settings) to determine the final outcome. Keep this in mind when designing your permission structure — overlapping permissions can lead to unexpected results if you are not careful.

Step 6: Using User Attributes in Policies

To make ABAC work effectively, you need meaningful attributes on your users. Keycloak provides several ways to manage user attributes that feed into your policies.

Custom User Attributes

Add attributes directly to user profiles:

1. Navigate to Users and select a user
2. Go to the Attributes tab
3. Add key-value pairs (e.g., department = engineering)

For production use, consider populating these attributes automatically through:

• Identity provider mappers: Import attributes from external identity providers during federation
• Custom user storage providers: Sync attributes from your HR system or directory
• Admin API: Update attributes programmatically as part of your provisioning workflow

Skycloak’s user management features simplify attribute management across your Keycloak instances, especially when managing users at scale.

Group Membership as Attributes

Group membership can serve as an implicit attribute in your policies. Users inherit attributes from their groups, and you can create group-based policies that check membership:

var context = $evaluation.getContext();
var identity = context.getIdentity();
var attributes = identity.getAttributes();
var groups = attributes.getValue('groups');

if (groups != null && groups.containsValue('/finance-team')) {
    $evaluation.grant();
}

Time-Based and Contextual Attributes

Keycloak’s authorization context includes environmental attributes beyond user properties:

• Time-based rules: Restrict access to specific hours, days, or date ranges
• Client attributes: Different policies for mobile vs. web clients
• Network context: Evaluate based on request metadata passed through your application

Step 7: Evaluating Permissions

Before deploying your ABAC configuration, test it thoroughly using Keycloak’s built-in evaluation tools.

Policy Evaluation Tool

Keycloak provides a policy evaluation tool in the admin console:

1. Navigate to your client’s Authorization tab
2. Click the Evaluate sub-tab
3. Select a user to evaluate
4. Optionally specify resources, scopes, and context attributes
5. Click Evaluate

The tool shows which policies were evaluated, their individual results, and the final permission decision. This is invaluable for debugging complex policy configurations.

Use this tool to test edge cases:

• Users with multiple conflicting attributes
• Resources with no matching policies
• Time-sensitive policies at boundary conditions

Token Introspection

You can also verify permissions by inspecting the authorization data included in access tokens. Keycloak can embed permission information directly in the JWT token, which you can examine using tools like our JWT Token Analyzer to verify that the correct permissions are being granted.

Step 8: Integrating with Your Application

Once your ABAC configuration is in place, your application needs to enforce it. There are several integration approaches.

Token-Based Authorization

The simplest approach is to request permissions when obtaining tokens. Include the authorization scope in your token request, and Keycloak will embed the user’s permissions in the access token:

POST /realms/{realm}/protocol/openid-connect/token
grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
audience={client_id}
permission=Document#view

Your application then checks the token’s authorization claim to determine what the user is allowed to do.

Policy Enforcer

Keycloak provides policy enforcer adapters for Java applications that automatically intercept requests and evaluate permissions:

{
  "enforcement-mode": "ENFORCING",
  "paths": [
    {
      "path": "/api/documents/*",
      "methods": [
        {
          "method": "GET",
          "scopes": ["view"]
        },
        {
          "method": "PUT",
          "scopes": ["edit"]
        },
        {
          "method": "DELETE",
          "scopes": ["delete"]
        }
      ]
    }
  ]
}

UMA (User-Managed Access)

For applications where resource owners need to manage access to their own resources, Keycloak supports the full UMA 2.0 protocol. This is particularly useful for document sharing, collaboration platforms, and any scenario where access control is decentralized.

The UMA flow involves:

1. A resource owner registers their resource with the authorization server
2. The resource owner creates policies governing who can access their resource
3. A requesting party obtains a permission ticket and exchanges it for an RPT (Requesting Party Token)
4. The resource server validates the RPT before granting access

For a deeper understanding of authorization models and how they apply in practice, see the Skycloak documentation.

Best Practices

Start Simple and Iterate

Begin with RBAC and add attribute-based policies only where roles alone are insufficient. Every ABAC policy adds complexity to your authorization model, so be intentional about what you add.

Document Your Policy Model

Maintain clear documentation of your resources, scopes, policies, and how they connect. A well-documented authorization model is much easier to audit and troubleshoot than one that exists only in the Keycloak admin console.

Test Thoroughly Before Production

Use Keycloak’s policy evaluation tool extensively before going live. Test with real user profiles and realistic attribute combinations. Pay special attention to edge cases like users with missing attributes or unusual group memberships.

Audit Regularly

Review your authorization policies on a regular cadence. Remove unused resources, scopes, and policies. Check that your policies still align with your application’s security requirements as features evolve.

Skycloak’s security features include audit logging and monitoring capabilities that help you track authorization decisions and identify potential issues in your ABAC configuration.

Use Aggregated Policies for Clarity

Rather than writing complex logic in a single JavaScript policy, break your rules into smaller, focused policies and combine them with aggregated policies. This makes individual rules easier to understand, test, and reuse.

Handle Missing Attributes Gracefully

Always account for the possibility that a user attribute might be missing or empty. A policy that fails to check for null values can produce unexpected results — typically a silent denial that is difficult to debug.

var attributes = identity.getAttributes();
var department = attributes.getValue('department');

if (department == null || department.asString(0) == '') {
    // Explicitly deny — don't leave it ambiguous
    $evaluation.deny();
    return;
}

Consider Performance

Complex policies with many attribute lookups can impact authorization latency. Cache permission decisions where appropriate, and avoid policies that make external calls during evaluation. Monitor your Keycloak instance’s performance as you add ABAC policies.

Next Steps

With ABAC configured in Keycloak, you have a flexible authorization framework that can adapt to complex access control requirements. As your application grows, you can add new attributes, policies, and resources without restructuring your entire permission model.

To explore related topics, check out Skycloak’s RBAC features for managing role-based permissions, or visit the documentation for guides on integrating Keycloak with your application stack.