[keycloak-user] Using KeyCloak with multiple Realms

[Stian Thorgersen]

I didn't say Keycloak isn't meant to work with multiple realms, but it's
wasn't designed to work with a large number of realms. We considered it
initially, but then figured true multi tenancy would be best introduced by
having multiple instances rather than trying to achieve total isolation
between realms. We don't test how well it scales with a large number of
realms either.

KEYCLOAK-3067, complexity of having a "master" realm and finally the fact
that an admin may be managing realms on a single instance or on multiple
instances we've decided that in the future we'll drop the master realm.
Instead we'll have an option to setup "trust" between realms so an admin
can easily authenticate to a different realm.

To prevent being locked out from the master realm you can remove the roles
from the new realm in the admin composite realm.

On 28 July 2016 at 09:55, Tobias Schmidt <freez3 at me.com> wrote:

> Dear Stian,
>
>
>
> we faced an issue when using KeyCloak with a multiple-tenant service and
> came up with a working solution we would like your opinion on.
>
>
>
> Our old approach was outlined as follows:
>
> Each of our tenants was assigned a single realm. Within this realm, an
> "administrator" user was created that enabled the tenant to full extent
> within our application, but not within the KeyCloak realm itself.
>
>
>
> Our software utilized the master realms root user to obtain the JSON
> installation files for our respective services.
>
> Thus, we ran into the problem of roots ever growing access rights, as
> described in this issue:
>
> https://issues.jboss.org/browse/KEYCLOAK-3067
>
>
>
> The encoded  list of roots rights  in the “Authentication” header exceeded
> 8KB and our web server was unable to process any requests from this point
> onward.
>
>
>
> To get rid of this problem, we devised a literal workaround: Each realm
> gets its specific master user who is entitled with all rights the client
> “realm-management”  has to offer- one could say we created a local root for
> each realm. This master now steps up to the hole left by root and provides
> the public keys etc. for our services. As its rights are limited to its own
> realm, its bearer token remains at a constant, reasonable size.
>
>
>
>
>
> The (scripted) creation of such a new realm works like this:
>
>
>
> We manually added  a user in the master realm who has no rights besides
> creating new users. We access this user via the admin-cli client and create
> a new user “creator”.
>
> Creator is then assigned a random password (which is cached) and the role
> “create-realm”.
>
>
>
> In the next step, we access creator and create our new realm, complete
> with clients, roles, groups and the two users ,  the administrator and the
> master.
>
>
>
> After successful creation of the realm, creator has fulfilled its purpose
> and is deleted. As he possesses full rights in the newly created realm, his
> continued existence presents a potential insecurity with no practical use
> to justify it.
>
>
>
> The big downside of our new approach is the fact that the rights of the
> master realms root user still keep growing. So we inevitably lock ourselves
> out of the mater realm security console in the long run.
>
> Of course, we’re still able to access each realms console via
> /auth/admin/<realm>/console with the master user.
>
> Also,  in the issue linked above, you commented that KeyCloak is not meant
> to be used with multiple realms. However, if the master realm was actually
> removed from KeyCloak in the future, our temporary workaround might yet
> turn into a long – lasting solution. Are we right on this part?
>
>
>
> Thank you very much for your consideration.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160816/5e403b4d/attachment.html