Replies: 5 comments 9 replies
-
|
+1 from me. It could really make significant improvement if it turns out we would be able to follow this proposal. It'd be of course big change, as admin user of master realm would not be able to manage all realms any more. But as far as I remember there was plan to get rid of master realm completely. But I don't know the details. |
Beta Was this translation helpful? Give feedback.
-
|
This idea would not work for us. We are providing Keycloak as a managed service. We only provide users access to their realms on their instance and keep the master realm for us. That allows us to support users in their realms while limiting the ability for users to shoot themselves in the foot. For example, users get access to their realms via the master realm so they cannot lock themselves out. The master realms are integrated with a centrally managed company IDM system which is kind of mandatory to use. |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, Still, the role composition model is still there and we may end up into a similar situation for different use cases, such as creating a large number of very fine grained roles and composing them within a single realm - probably at a different scale, though, so the impact might be less noticeable. I think that changing this all-realms role collection for the root admin might be actually difficult to swallow, because Keycloak has been around for a while (probably a significant installed base) and real-life use cases have been built around what exists up to now. As an example, we do use Keycloak is a multi-tenant environment, having one realm per tenant (no surprise here), and ops are using the root admin to setup such tenants (along with automation through API), but also to setup more complex IdP federation scenarios for the sake of our customers (example: delegating the auth process to Azure AD through OIDC or SAML), still using the root admin. On the positive side, I think that forbidding the master admin to reach into other realms than |
Beta Was this translation helpful? Give feedback.
-
|
This approach doesn't work I'm afraid as there's a clear use-case for managing all realms from the master realm, with the ability to specify which realms/roles for individual realms a given user should be access to. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the inputs. I now see that we need to make the setup efficient "as is" with the roles in the master realm. @stianst - would you support a change in Keycloak that those realm clients can be deleted from those people who don't need them and that don't want to wait for performance enhancements to become available? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem statement
A Keycloak instance with more than 100-200 realm will slow down significantly, see discussion #11074 and KEYCLOAK-4593.
When analyzing the performance, one of the sources of the slowdown is evaluating the permissions in the admin realm, where each realm 'xxx' will have a client named 'xxx-realm'. When logging into the
masterrealm, those client roles and its composite roles will be evaluated which is costly. With caching enabled, the cache initialization can take minutes, and without caching logging is is also slow.This is caused by the iterative evaluation of the composite roles, and with each iterative step the persistence context grows, which slows down Hibernate's dirty checking. The PR #11799 and upcoming PRs aim to speed up this process, while keeping the one-client-per-realm structure as is.
Approach
While evaluating the composite roles could be sped up, another approach could be keep the clients only temporarily until a per-realm admin has been set up, and then delete it.
Setting up a new realm would then work as follows:
I first suggested it in this comment.
If the user for the new realm would lock themself out of the realm, the client would need to be re-added for that realm in the master realm, so that the master realm's admin would regain access.
The changes to support this in Keycloak look minimal: A first POC showed that two placed need to change that assume the client-per-realm always exists (fdbf876), plus there is currently a protection when trying to delete client-per-realm with the API.
Benefits
This could open the door for scaling the number of realms without a constraint on evaluating the roles and composite roles on all realms. Performance of the admin UI and REST endpoints should then remain constant with a growing number of realms.
Alternatives
Other
./.
Beta Was this translation helpful? Give feedback.
All reactions