+1.  Name the event RealmPostCreateEvent.  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?


On 7/20/16 2:52 PM, Dmitry Telegin wrote:
Hi,

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 "view-something" 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 realm.

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.

Regards,
Dmitry



_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev