This would need to be a community contribution. We (the RHT/Keycloak
open source devs) have too many things scheduled in queue right now and
I don't think there would be a lot of users that would request this feature.
On 5/18/16 9:19 AM, Stian Thorgersen wrote:
On 18 May 2016 at 15:07, Thomas Raehalme
<thomas.raehalme(a)aitiofinland.com
<mailto:thomas.raehalme@aitiofinland.com>> wrote:
On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote:
On 18 May 2016 at 14:52, Thomas Raehalme
<thomas.raehalme(a)aitiofinland.com
<mailto:thomas.raehalme@aitiofinland.com>> wrote:
By sharding do you mean that the environment should have
multiple independent Keycloak instances/clusters to which
tenants are distributed?
Yes. At first our plan was to have a single Keycloak support
multiple tenants in a SaaS environment. However, we decided
that this level of tenants would be better achieved by having
completely separate instances.
Ok, thanks for the clarification. I don't think from a developer
point of view it makes a big difference to have multiple instances
if you're already working with multiple realms. My concern,
however, is how to manage all those realms hence my original
message. At the moment there is no tool to support that, or at
least I am not aware of one.
Fair point, but any solution would need to work with realms that are
located on the same instance as well as on different instances.
It would also be a fairly tedious thing to implement.
Realms would need some inheritance, then there's the
admin console to worry about. At the moment there's
not even a "shared" place for multiple realms, so no
logical place to create/edit realm templates.
Oh I never presumed this would be easy task to do :-)
I meant we're very unlikely to accept the feature due to the
amount of complexity that would be involved. It also has very
little benefit in the use-cases we've designed Keycloak for
and wouldn't work when realms are located on separate
instances which we expect would be the norm.
One important use case in my opinion is the possibility to ensure
that in a SaaS environment all realms contain the required data.
If you, for example, add a new role in your SaaS application,
you'll need to make sure the role is added to all realms (and
assign it to users properly).
You could do that through admin rest endpoints
Another thing is that in the future we plan to remove
master realm concept completely. Instead we'll have a
trusted realm option that will use identity brokering
behind the covers. The idea is that a single admin can
manage multiple realms independently on what servers the
realm are located on. This would mean that an admin in
reality can only manage a single realm, but automatically
authenticate to other realms to manage those as well
without re-authentication. There would be no cross-realm
permissions though, so no "master" realm admin that can
manage realm templates.
Do you mean that in the future the current master realm
will be just-another-realm, but when creating new realms
they automatically trust the master?
There will be no special "master" realm at all. We've not
fully figured out the bootstrapping of new realms. Rather than
having a "master" realm it would be possible to link realms
together which will enable cross-realm management. One key
aspect of this is that not only will you be able to manage
multiple realms within the Keycloak admin console, but you
will also be able to authenticate to your own applications
that exist in different realms.
How is that different from the currently available keycloak-oidc
identity provider?
It would use keycloak-oidc identity provider behind the covers, but
the bootstrapping would be a single click button. Rather than a button
on login form we'd also hide the button and use idp_hint to
automatically "login" to another realm.
Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev