[keycloak-dev] Applying post-create realm modifications

[Dmitry Telegin]

> 
    > +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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

    

    

  

> > _______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160721/89d02731/attachment.html