<html><head>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
</head>
<body><blockquote type="cite">
<p>+1. Name the event RealmPostCreateEvent. </p></blockquote><div><br></div><div>OK, so I'll be filing now a JIRA issue and then a PR, right?</div><div><br></div><blockquote type="cite"><p>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.</p>
<p>Interested in contributing?<br></p></blockquote><div><br></div><div>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:</div><div><br></div><div><a href="https://dteleguin.gitbooks.io/keycloak-tms-ru/content/">https://dteleguin.gitbooks.io/keycloak-tms-ru/content/</a></div><div><br></div><div>(It's in Russian, so skip the text and look at screenshots, just to have an idea what's it all about.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Dmitry</div><div><br></div><blockquote type="cite"><p>
</p>
<br>
<div class="moz-cite-prefix">On 7/20/16 2:52 PM, Dmitry Telegin
wrote:<br>
</div>
<blockquote cite="mid:1469040726.4229.17.camel@cargosoft.ru" type="cite">
<div>Hi,</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>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;</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div>- adding custom authentication flow at this moment will break
further realm initialization logic, as latter relies on the
emptiness of the flow container;</div>
<div>- adding roles simply wouldn't work because no clients
(including the desired *-realm) are yet registered with the
realm.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Dmitry</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre></blockquote></body></html>