Hi, The idea of getting rid of master realm has been around for years [1] [2]. Just wanted to know, what's the current stance on this? Can we tell for sure that there still will be master realm in KC 5.0? Or can we tell the opposite? Some background: we're working on a Keycloak extension (provider) that needs to operate a global (non-realm-based) writable config. So I'm choosing between the two options: - store config keys as master realm attributes; - introduce full-fledged configuration system based on Apache Commons Configuration, backed by its own DB table and Infinispan cache. The latter is obviously more complex, however more powerful. I've posted a write-up on it about a year ago [3], but didn't get any feedback. I hope it could be reevaluated today; for Keycloak proper, there are several use cases like auto-update settings, admin email, periodic tasks etc. The former, on the contrary, is much easier to implement, however there is a risk of having to rewrite everything from scratch should master realm bite the dust one day. Cheers, Dmitry Telegin CTO, Acutus s.r.o. [1] http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006066.html [2] https://issues.jboss.org/browse/KEYCLOAK-3443 [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-December/010261.html _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hello Stian, On Mon, 2018-11-05 at 20:13 +0100, Stian Thorgersen wrote: > It is very unlikely that we will remove the master realm in 5.x. Glad to hear that, thx for the info > There are already a way to deal with global config which is in standalone.xml. The limitation there currently is that changes require a server restart and we don't have a schema so it's a simple key-value type config. Changes here can be done through jboss-cli and with domain mode you can have these propagated to all nodes in the cluster. At this point we won't consider adding another level of global config like Apache Commons Configuration. I'd also add my 2¢ to the list of limitations: - it's impossible to modify configuration in runtime from either Keycloak itself or providers (or is it? DMR maybe?)

- in standalone-ha mode, you'll still need to propagate the changes to the nodes somehow.

I think for now I'll stick to using master realm attributes. And if Keycloak is about to undergo such a drastic changes, I hope it will be announced in advance so I'll have enough time to port my code.

Thanks for clarifications, Dmitry > > > On Mon, 5 Nov 2018 at 10:47, Dmitry Telegin <dt(a)acutus.pro&gt; wrote: > > Hi, > > > > The idea of getting rid of master realm has been around for years [1] [2]. Just wanted to know, what's the current stance on this? Can we tell for sure that there still will be master realm in KC 5.0? Or can we tell the opposite? > > > > Some background: we're working on a Keycloak extension (provider) that needs to operate a global (non-realm-based) writable config. So I'm choosing between the two options: > > - store config keys as master realm attributes; > > - introduce full-fledged configuration system based on Apache Commons Configuration, backed by its own DB table and Infinispan cache. > > > > The latter is obviously more complex, however more powerful. I've posted a write-up on it about a year ago [3], but didn't get any feedback. I hope it could be reevaluated today; for Keycloak proper, there are several use cases like auto-update settings, admin email, periodic tasks etc. > > > > The former, on the contrary, is much easier to implement, however there is a risk of having to rewrite everything from scratch should master realm bite the dust one day. > > > > Cheers, > > Dmitry Telegin > > CTO, Acutus s.r.o. > > > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006066.html > > [2] https://issues.jboss.org/browse/KEYCLOAK-3443 > > [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-December/010261.html > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >