How does the `security-admin-console` client use the `realm-management` client?

How does the default security-admin-console client use the realm-management client? That’s probably not crystal clear, so I’ll elaborate. The Keycloak Admin Console (written in Angular) uses the default security-admin-console client. Admin permissions are determined by the realm-management client (the realm-management client is documented here). For example, if you want an administrator to be able to view audit events, give them the view-events role in the realm-management client, then the admin can login to the Keycloak Admin Console, which uses the security-admin-console client, to view events.

What I don’t understand is how the security-admin-console “uses” the realm-management client. I’ve looked at the configuration of both clients, and I don’t see any mappers to connect the two together. How does the security-admin-console “know about” realm-management roles? I assume the interaction is still governed by OIDC, so I expected some kind of mapping.


I’m not just asking for curiosity’s sake. My team has decided to create a purpose-built administration console. (The existing admin console is great, but we need some other features like drop-down menus for attributes.) The console will be a purely client-side application, just like the existing Keycloak Admin Console. So far we have no difficulty implementing this, but not knowing not the answer to the above question makes me doubt our design.

Our custom admin console, which we based off of Keycloak’s excellent js-console example, uses the security-admin-console client to send REST requests to Keycloak. The configuration is simply this:

{
  "realm": "our-realm",
  "auth-server-url": "http://localhost:8081/auth/",
  "ssl-required": "none",
  "resource": "security-admin-console",
  "public-client": true,
  "confidential-port": 0
}

And I can see that the REST requests are constrained by the user’s realm-management permissions – without the appropriate permissions, requests are Forbidden. But I don’t understand how they’ve been constrained. We’re using the security-admin-console client, not the realm-management client, so how is Keycloak authorizing the request?

Now, let’s say I wanted to create my own client instead of reusing security-admin-console, but I still wanted to use realm-management permissions. I can do so by adding the realm-management roles to the new client’s scope. If I do this, realm-management will appear in the aud list of the token, roles appear in the resource_access claim, and requests to Keycloak are authorized. That makes sense, but it’s not how it works for security-admin-console: realm-management isn’t in the aud list, and the realm-management roles don’t appear in the resource_access claim: it just magically works.

1 Like

I’ll add that my hunch is that the security-admin-console “cheats” somehow to use the realm-management permissions: it’s not actually OIDC.