Re: [keycloak-dev] Realm templates

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 > wrote: > > > On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: >> >> On 18 May 2016 at 14:52, Thomas Raehalme < >> <thomas.raehalme@aitiofinland.com&gt;thomas.raehalme(a)aitiofinland.com&gt; >> 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 listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev