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.
-
|
Thanks for explaining your scenario. Could you please provide some number of how many realms per Keycloak instance you support today, and how many you would like to see supported? |
Beta Was this translation helpful? Give feedback.
-
|
@ahus1 Depends, as usual. Most of our customers work in B2C scenarios, they will probably just have a handful of realms, maybe even just one. Some run in B2B2C scenarios, so they use the Keycloak instance we provide and create a new realm every time they get a new (business) customer. We typically give them a technical user in the master realm with the ability to create new realms (but still not do anything on the master realm). So far most of our B2B2C customers have a few big business customers, so the order of magnitude there is somewhere around 100. However, I could easily see cases with much bigger numbers of small business customers (e.g. car workshops) - for these thousands of realms might be necessary. I remember talking to @stianst about it and he hinted that a more lightweight subtenant concept might be coming up more appropriate to handle these cases. |
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.
-
|
@stianst - I read in your comment:
I'm not sure how that would work ... could you please elaborate? |
Beta Was this translation helpful? Give feedback.
-
|
HI @ahus1 ,
Note that last time, I checked, the way to write recursive CTEs was DB-dependent... Not a showstopper by itself but increases the code complexity as you have to use the right native query depending on the configured DB. |
Beta Was this translation helpful? Give feedback.
-
|
@davoustp - thanks for pointing me at the cyclic graph issue. I suppose the lower SELECT could be adjusted to not select those roles again that have been in the previous select. The solution for the CTE would only work with the new store as I see it, as that one is targeting only PostgreSQL and CockroachDB for now, and those support it. The new store won't cache within Keycloak, but will use the database's cache for now - the current Infinispan layer for caching will be disabled there can can't be used there. Future versions will have a transparent cache as part of the tree store. It would still be possible to cache the results where the user has and doesn't have a role (first within a single session, later across sessions if needed for the performance). |
Beta Was this translation helpful? Give feedback.
-
The way to handle cycle with Postgres is documented at https://www.postgresql.org/docs/14/queries-with.html , section
Ah, that's new to me, I thought the new store was applicable to the full range of supported databases with the legacy implementation. That makes it easier.
Wow, ok, no caching for now in the new store, ok ok.
Makes sense - such a lookup should be performed at most once per session for sure, at least. |
Beta Was this translation helpful? Give feedback.
-
|
@davoustp - see #10404 for the discussion on which databases will be support. To quote from there:
|
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