OK, so I'll be filing now a JIRA issue and then a PR, right? 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: https://dteleguin.gitbooks.io/keycloak-tms-ru/content/ (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 extensions. Cheers, Dmitry wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, 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: 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; 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. 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: further realm initialization logic, as latter relies on the emptiness of the flow container; (including the desired *-realm) are yet registered with the realm. (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(a)lists.jboss.org https://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