+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:

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

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
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev