Repository navigation
Support arbitrary amount of "admin clients" #8599
Replies: 4 comments 12 replies
|
I'm not keen on adding a flag like you're suggesting, as that results in a config option that makes no sense to 99.9999% of clients, so would like to have some cleaner approach on how to fill this use-case. Maybe there's also some connection here to non-admin usage as well when there are large amounts of roles. There's perhaps some connection here with #8516 since with namespaces we could add a scope of roles to the token rather than the roles themselves, which would suggest to a resource provider that it needs to lookup what roles a user has separately. With internal clients like admin APIs they can just lookup the roles for the user internally, while external clients can use the token introspection endpoint to get the actual roles. |
|
@danielFesenmeyer It is not clear to me why you need to create additional clients other than using the built-in ones. Could you please, elaborate more on that? Also for scheduled management operations, perhaps it makes more sense to have these jobs running on Keycloak itself? It should avoid additional overhead when processing HTTP requests to our APIs and blocking worker threads. In regards to credential rotation, looks like this one could be something we could have OOTB? I don't know ... |
|
@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 ( 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:
|
|
@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. |
Client scope keycloak-admin-apiHow about an other option: Instead of a flag, a client scope keycloak-admin-api is defined and used at the default admin clients and on other custom ones, if required. More details: @stianst What do you think, better or worse than a flag? I would be happy with any configuration as long as it is explicitly configured and explainable to an admin user. Current approach is hard to explain, as the |
|
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 |
|
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. |
|
@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. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Currently, there are two built-in "admin clients": admin-cli and security-admin-console. For requests with one of these clients, Keycloak authorizes based on all roles of the user, not only the ones contained in the token. In fact, there are no roles in the scope (and therefore in the created tokens) of these clients. This has the advantage that tokens don't get too big to fit into a Bearer Authorization header.
Our customers would like to create their own "admin clients" in addition to the existing ones. There are several use cases, for example these ones:
What about adding an "admin client" flag to the client representation, which leads to the behaviour described above? Some places in the code could even be simplified, for example here it could just be checked for the flag instead of checking for the special client IDs:
keycloak/services/src/main/java/org/keycloak/services/resources/admin/permissions/MgmtPermissions.java
Line 102 in 7b135c4
What do you think about such a flag?
If you think it's useful, we would be happy to provide a PR.
All reactions