Secure your Keycloak surface
Realm configuration, client scopes, and role mappings that grant more than anyone intended. We don’t connect to Keycloak to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Keycloak goes wrong
Keycloak goes wrong through composite roles: a role whose name suggests narrow access can expand into far more through composition.
- Clients configured as public when they hold credentials, or with wildcard redirect URIs
- Realm roles composited in ways that grant far more than the name suggests
- Admin console exposed beyond the intended network boundary
- Token lifespans set long enough to outlive a revocation
- Brute force detection disabled on realms holding real users
[02] What We Secure
What we watch, catch and fix on Keycloak
On Keycloak we expand composite roles into effective permissions, so what a role grants is visible rather than implied by its name.
- Client configuration audited for wildcard redirects, which are a direct token theft path
- Composite role expansion resolved so effective permissions are visible rather than implied
- Admin console exposure tested from outside
- Token lifespan reviewed against your revocation expectations
- Realm security settings checked against your standard rather than defaults
[03] Where It Lands
Where Keycloak lands in your registers
Directory data drives your access reviews directly: reviewers see live entitlements rather than a spreadsheet exported three weeks ago, and leaver revocation is verified against the systems themselves. The asset register records each identity provider as a critical dependency, and the risk register carries the concentration risk that comes with it — because if this tier fails, everything behind it fails with it.
[04] How We Engage
On Keycloak specifically
On Keycloak, we tighten client configuration and enable brute force protection. Role model restructuring and realm separation we scope and drive with your engineers.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Keycloak FAQs
What Keycloak access does Konfirmity need?
Konfirmity needs a service account client with the view-realm, view-users, view-clients and view-events roles in each realm you connect. That covers configuration, role mapping and event review without any ability to modify the realm.
Do you check whether our admin console is exposed?
Yes, and by testing from outside rather than reading configuration. An admin console reachable beyond its intended boundary is one of the highest-severity findings we can raise on Keycloak, because it grants control over authentication for everything behind it.
Okta
Microsoft Entra ID
Google Workspace
Auth0
JumpCloud