+1. Name the event RealmPostCreateEvent.
OK, so I'll be filing now a JIRA issue and then a PR, right?
I was also thinking of
having a FeatureProvider that would be an "uber" component that
could install sub components. i.e. an authenticator, user
federation provider, etc.
Interested in contributing?
Absolutely! This would be a perfect match for what I'm working on now.
It's in beta at the moment, but I think a little disclosure won't hurt:
it will be a device management add-on that will let KeyCloak manage
hardware OTP generators (tokens). It implements full device lifecycle
support, including bulk import (from a vendor-supplied XML file),
maintaining a pool of available devices, enrollment/revocation etc.
Here's a draft manual:
(It's in Russian, so skip the text and look at screenshots, just to
have an idea what's it all about.)
Under the hood, it consists of custom JPA entity, custom REST resource,
custom authenticator, a customized GUI theme, and a code to tweak newly
created realms (hence this discussion). I think extensions like this
would definitely benefit from some kind of umbrella construct, or
"uber" component. I could even envision it becoming the base for
plugin-like architecture and even plugin "market", similar to what we
have in Atlassian products.
I'm not mentioning Atlassian just because; KeyCloak and Atlassian Crowd
are the same field players. Before KeyCloak came into existence, we had
tried to implement similar device management system on top of Crowd -
and had failed miserably, due to lack of documentation and extension
points (that's not the case for JIRA and Confluence, obviously).
Implementing the same on top of KeyCloak was orders of magnitude
easier. Surely I've encountered some caveats; I think I'll do another
ML post to summarize my experience, and maybe one day even will turn it
into a walkthrough tutorial for creating full-featured KeyCloak
> > > >
> On 7/20/16 2:52 PM, Dmitry Telegin
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > >
> A KeyCloak extension might have a need to apply
customizations to a newly created realm, be it master realm on a
first-time run, or a realm added later via admin console. From
my practice, I can mention at least two use cases for that:
> 1. Creating a custom authentication flow. If you provide a
custom authenticator, you might also want to provide a custom
flow for it, thus making it usable out-of-the-box, and without
having an end-user dive deep into the details of flow setup;
> 2. Creating custom admin roles, i.e. atomic
and "manage-something" roles belonging
to a *-realm client of
master-realm (and automatically joining the realm "admin" role).
This might be topical if you provide a custom realm resource,
and you want to secure it with individual roles different from
the built-in ones.
> There is a RealmModel.RealmCreationEvent event fired from
JpaRealmProvider. Unfortunately, it is fired too early; it
delivers a realm instance in its bare, non-initialized state
which is unusable for both of the above use cases:
> - adding custom authentication flow at this moment will break
further realm initialization logic, as latter relies on the
emptiness of the flow container;
> - adding roles simply wouldn't work because no clients
(including the desired *-realm) are yet registered with the
> It would be nice to have something like RealmCreatedEvent
(maybe inside RealmManager) that would be fired just before
RealmManager::createRealm returns. Should be as trivial as
adding an inner class/interface and firing an event.
> > > _______________________________________________
keycloak-dev mailing list
keycloak-dev mailing list