Security · Role-Based Access
Access that matches how your teams actually work
We design Keycloak roles, groups and permissions around your applications and org structure, map them cleanly into tokens, and add fine-grained policies where a role alone isn't enough — with least privilege as the starting point.
- Realm, client and composite roles
- Authorization Services & UMA 2.0
- Runs on upstream Keycloak 26.x
Standards & integrations
- OAuth 2.0 Scopes
- OpenID Connect Claims
- UMA 2.0
- Keycloak Authorization Services
- Keycloak Organizations
- LDAP Group Mapping
Overview
Role design is where access control succeeds or fails
Keycloak gives you realm roles, client roles, composites, groups and a full policy engine. The hard part is choosing a model that stays understandable as you add applications, teams and customers — one where a new hire gets the right access from a group, tokens carry only what each app needs, and an access review doesn't turn into archaeology. We design that model and implement it as code.
What we deliver
- Role and group model with naming conventions
- Roles, groups and client scopes defined as code
- Token claim map per application
- Authorization Services policies where needed
- Access review report built on the Admin REST API
- Runbook for granting and removing access
Capabilities
What Role-Based Access covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Roles with a clear scope
Realm roles for company-wide duties, client roles for application-specific permissions, and composite roles that bundle them into job functions.
Groups that carry access
Hierarchical groups assign roles once, subgroups inherit from their parents, and default roles give every new user a safe baseline.
Tokens that stay lean
Client scopes, role scope mappings and protocol mappers put only the roles each application needs into its tokens, not every role a user holds.
Fine-grained authorization
Authorization Services model resources, scopes, policies and permissions, so rules like 'owners edit, reviewers comment' live in Keycloak instead of scattered through code.
B2B membership
Keycloak Organizations group each customer's members, domains and identity providers, and put organization membership in tokens for your apps to enforce.
Access reviews
Scheduled reports built on the Admin REST API list who holds which roles, directly or through groups, giving owners a concrete list to certify.
How it works
From first call to production
Model roles around real duties
We interview application owners, inventory existing permissions, and agree a role and group model that follows least privilege.
Implement as code
Roles, groups, composites, scopes and authorization policies are defined in Terraform or OpenTofu and promoted through environments like any other change.
Migrate and verify
Existing users are mapped to the new model, tokens are checked per application, and a first access review confirms nobody gained or lost access by accident.
Use cases
Where teams put it to work
Multi-application platforms
Consistent roles across a suite of products, with each app receiving only its own client roles in its tokens.
B2B SaaS
Customer organizations with their own members, where your app enforces tenant boundaries using the membership Keycloak puts in the token.
Internal tools and least privilege
Replace ad-hoc admin flags inside individual apps with centrally managed roles that can be reviewed and revoked in one place.
FAQ
Role-Based Access questions, answered
Should we use realm roles or client roles?
Usually both. Realm roles suit duties that span applications; client roles keep application-specific permissions contained. Composite roles and groups tie them together without duplicating assignments.
When do we need Authorization Services instead of plain roles?
When a decision depends on the resource itself — who owns a record, which project it belongs to, what time it is — rather than only on who the user is. For simple checks, roles in the token are enough.
How do roles reach our applications?
Through tokens. Protocol mappers add realm and client roles as claims in OIDC tokens or as attributes in SAML assertions, and we configure scopes so each app sees only what it needs.
Can we delegate user administration to team leads or customers?
Keycloak's fine-grained admin permissions can delegate management of specific users, groups or clients. For a customer-facing admin experience inside your product, we usually build on the Admin REST API behind your own authorization checks.
Ready to roll out Role-Based Access?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.