@stianst Yeah, they are. But if you are doing client credentials to obtain tokens, you should be fine to access the Admin API even though the built-in client is tied with KC URLs?

Or these clients are alternative Admin UIs served by server-side apps doing code grant?

In theory, people should be able to have a specific admin client (admin-cli) on a per realm basis, if each tenant/customer has its own realm. But I guess it is not the case here, @danielFesenmeyer? Mainly because we are not good at supporting a large number of realms.

So I guess the main requirement here is to avoid sharing the built-in admin client between tenants when in a single realm?

@pedroigor that's true, the main requirement is not sharing built-in admin client. Our tenant/customer wants to manage multiple realms and we want to provide them with a client but don't want to share it.

To summarize all cases which are solved by the flag:

1. Use different clients for service provider operating Keycloak and service customer who is managing multiple realms
2. Different automation/management tools/UIs which should not share the same client
3. For a credential rotation, if you want to have a phase when old and new credentials are valid

@pedroigor sharing the clients makes no sense at all. Basically what you are advocating for is client impersonation.

@jbman the use-case of being able to create additional clients that can manage many realms is perfectly valid, and would be good to support properly. However, I'm not keen on having a config flag like this, and would like us to figure out a different way to achieve it.

@stianst @jbman Actually, adding a special config flag was the only idea I came up with. I was not aware what you have planned in context of Namespaced Roles (#8516) - looks promising. I like your suggestion from above: to include a scope of roles in the token (instead of all the actual roles).

I like that idea much better than a config option. Could we make it more generic perhaps? What about a mapper that can set a claim in the token that means the token should allow all roles the given client has a scope on without actually listing the roles? That can then be also useful for generic use-cases where the # roles are to large for the initial access token, allowing the token introspection endpoint to be used to retrieve all the roles.

With a single mapper all roles would be excluded from the token, while it would be much better if a token can still contain some roles and some would only be available internally or through token introspection. This would need a config option at the client scope. A flag exclude roles from token which needs to be read by the existing client roles and realm roles mappers so that they don't put the roles in the token. However the client scope should still end up in the token and the roles should end up to be available at the token introspection endpoint.

I wouldn't add an option to client scopes to configure this, so would need some other solution to that problem. I would imagine that you wouldn't us client roles or realm roles mapper in this scenario though, or they would have config options for this purpose.

Hi @jbman, @stianst. I've implemented a draft PR with a mapper approach: #8914 - I've also added a detailed description, with considered alternatives. Would be great to get some feedback from you.

@danielFesenmeyer thanks, while looking at your PR I was wondering if there's an even simpler and more generic solution to this problem, essentially just making the role mappers add to introspection endpoint, and not access token. We can discuss that through your PR though.