Alauda Application Services Identity Management E1

Authorization Services

Keycloak provides fine-grained authorization services based on the User-Managed Access (UMA) specification and a rich policy evaluation engine. These services go beyond role-based access control (RBAC) to support attribute-based, time-based, and context-aware authorization decisions.

TOC

OverviewKey ConceptsPolicy TypesDecision StrategiesAuthorization FlowEnabling Authorization ServicesUser-Managed Access (UMA)

Overview

Traditional RBAC assigns roles to users and checks roles in application code. Keycloak Authorization Services externalizes authorization logic from the application into a centralized policy engine:

  • Applications register their protected resources and scopes.
  • Administrators define policies that govern access to those resources.
  • Keycloak evaluates policies at runtime and returns authorization decisions.
  • Applications enforce the decisions using the authorization response.

This separation allows authorization logic to be managed centrally without changing application code.

Key Concepts

ConceptDescription
Resource ServerA client application that hosts protected resources and delegates authorization to Keycloak
ResourceA protected entity (for example, an API endpoint, a document, a database record)
ScopeAn action that can be performed on a resource (for example, view, edit, delete)
PermissionA rule that associates a policy with specific resources and/or scopes
PolicyA condition that determines whether access is granted or denied
Requesting Party Token (RPT)An access token enriched with authorization data (granted permissions)

Policy Types

Keycloak supports multiple policy types that can be combined:

Policy TypeDescriptionExample
User-basedGrants access to specific usersAllow alice and bob
Role-basedGrants access based on realm or client rolesAllow users with manager role
Group-basedGrants access based on group membershipAllow members of Engineering group
Client-basedGrants access to requests from specific clientsAllow requests from admin-portal client
Time-basedGrants access during specific time windowsAllow access Monday–Friday, 09:00 –18:00
JavaScript-basedCustom logic evaluated at runtimeCheck custom user attributes or request context
AggregatedCombines multiple policies with a decision strategyAll sub-policies must grant access (Unanimous), or at least one (Affirmative)
Regex-basedMatches a claim value against a regular expressionAllow if department matches eng-.*
Client ScopeGrants access based on the client scope present in the tokenAllow if scope admin is present

Decision Strategies

When a permission references multiple policies, the decision strategy determines how the individual policy decisions are combined:

StrategyDescription
UnanimousAll policies must grant access (AND logic)
AffirmativeAt least one policy must grant access (OR logic)
ConsensusThe majority of policies must grant access

Authorization Flow

  1. The client application requests an access token from Keycloak.
  2. The client sends the access token to the resource server (API).
  3. The resource server requests an RPT from the Keycloak token endpoint, specifying the resource and scope being accessed.
  4. Keycloak evaluates all applicable policies and returns an RPT containing the granted permissions (or denies the request).
  5. The resource server inspects the RPT permissions and allows or denies the operation.

Alternatively, the resource server can call the token introspection endpoint to evaluate permissions without obtaining an RPT.

Enabling Authorization Services

Authorization services are enabled per client:

  1. In the Admin Console, go to Clients and select the target client.
  2. Enable Client authentication (the client must be confidential).
  3. Enable Authorization.
  4. Click Save.
  5. A new Authorization tab appears with sub-sections for resources, scopes, policies, and permissions.

For step-by-step configuration, see Configure Authorization.

User-Managed Access (UMA)

UMA extends the authorization model to allow resource owners (end users) to manage access to their own resources. With UMA:

  • Users can share resources with other users or groups.
  • Users can approve or deny access requests.
  • Authorization decisions respect the resource owner's policies.

UMA is an advanced feature used primarily in scenarios where end users need fine-grained control over resource sharing (for example, document sharing, API access delegation).