3:14 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user