[keycloak-dev] The ultimate fate of master realm

[Stian Thorgersen]

On Mon, 5 Nov 2018 at 23:44, Dmitry Telegin <dt at acutus.pro> wrote:

> 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?)
>

It is possible, but not that nice. There is Java libs to interact with DMR.
We use it in some tests.


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

Yes, that's what domain mode is for really.


>
> 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.
>

Absolutely - it will be a lengthy discussion and we will keep it the
discussion open. So keep monitoring keycloak-dev ;)


>
> Thanks for clarifications,
> Dmitry
>
> >
> > > On Mon, 5 Nov 2018 at 10:47, Dmitry Telegin <dt at acutus.pro> 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
>