When to use Realm roles in Keycloak?

0
votes

I'm experimenting with role mappings among microservices & frontends (keycloak-clients in Keycloak terms).

Let's suppose I have two keycloak clients:

  • routemanagement-api
  • routemanagement-webapp

In the routemanagement-api I'd define some roles, let's say one of them: regular-user . This role is not composite role.

In the routemanagement-webapp, I'd define another role, also named regular-user. This is a composite role. I'd associate it with the "regular-role" user in the routemanagement-api.

Then, I create a user. Let's suppose this user registers through routemanagement-webapp. So, my registration logic will assign "routemanagement-webapp:regular-user" role to this newly created user.

Since "routemanagement-webapp:regular-user" is associated with "routemanagement-api:regular-user" role, calls to routemanagement-api REST endpoints will succeed.

You see, I don't need realm (upper-level) roles to make that happen. I can jump from one client to another client directly. I'd say my approach is a top-down approach; the frontend apps at the top, the apis at the bottom. I'm thinking of having separate webapp for provisioning users. User will be granted roles to "webapps" she is allowed to use. The correct permissions to use associated apis are handled in the keycloak UI, by those composite-roles trick.

What do you think of that approach? Is it a correct way of thinking? And what do we need realm roles for?

1
keycloakroles
I don't understand what do you need such of a procedure, when you basically are referring to the same role? Maybe I don't get the point of the question, but that's basically what realm roles are for, for using them in more than one client. If you have specific needs in one client, then use a client scoped role. – Xtreme Biker
That what i was thinking as well (realm: more general, client: more specific). Can we think of it this way (in an organizational context)?: - Realm roles should map to hierarchical structure in the organization (CEO, cto, manager, etc). - Client roles, should map to functional roles in the "working domain" / "task force" the API is created for. – Cokorda Raka
Yes, that seems to be a proper usage. – Xtreme Biker
Btw, @ExtremeBiker, I have a justification for that role-mapping procedure. When we launch a new webapp, the team don't want to get bogged down by roles in any other microservices. We only care about the roles in the spec for their webapp (frontend). The access to backend API (other microservices) is sorted through that procedure (in the keycloak UI), along with resource-authorizations policies & permissions. – Cokorda Raka
Okay, I guess it is similar for you then to use that or the realm role itself, since other client roles are in some way "public" as long as they're in the same realm. – Xtreme Biker

1 Answers

0
votes

I'd suggest you might not need the composite role. In my view, the api owns the resource so you should design your client roles as the api as the api client as the resource owner. The role could be named "verb-resource", e.g. "create-x, read-x, update-x, delete-x".

Even if you're authenticating using routemanagement-webapp client you can still infer the resource roles of the user for the routemanagement-api.

EXAMPLE JWT

{
  "jti": "0ba58a94-d98e-4f29-abfa-ade95d96a62b",
  "exp": 1589264282,
  "nbf": 0,
  "iat": 1589263982,
  "iss": "http://localhost:8080/auth/realms/master",
  "aud": "routemanagement-webapp",
  "sub": "50b6d1f7-88ea-451c-92bb-fc7f5fcc6683",
  "typ": "Bearer",
  "azp": "routemanagement-webapp",
  "auth_time": 0,
  "session_state": "7a270756-917b-4afc-a06d-054b05e6d41a",
  "acr": "1",
  "allowed-origins": [],
  "realm_access": {
    "roles": [
      "offline_access",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "routemanagement-api": {
      "roles": [
        "manage-regular-stuff"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Test User",
  "preferred_username": "test.user",
  "enabled": true,
  "email": "[email protected]"
}

If you wanted To get more granular your could use the authorization and resource registration instead of the role based "verb-resource" naming strategy.