<div dir="ltr">for now Wildfly would do. It would be great if this can be part of Alpha 3 :)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 10:41 AM, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Travis.  Where are you deploying to?  Wildfly?  JBoss EAP?  Gonna try and work on your extension tomorrow to see if I can get it in by Alpha 3 deadline.<div class="">
<br>
<br>
On 3/2/2014 5:05 AM, Travis De Silva wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
yes that sounds great. Thanks Bill<br>
<br>
<br>
On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br></div><div class="">
&lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;&gt; wrote:<br>
<br>
    I&#39;ll work on refactoring the adapters next week to help support<br>
    this. Maybe if I get things cleaned up enough and provide some bare<br>
    bones support for multi-tenancy you could take it over to help drive<br>
    for your requirements?<br>
<br>
<br>
    On 2/28/2014 3:57 PM, Travis De Silva wrote:<br>
<br>
<br>
        On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
        &lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;<br></div><div><div class="h5">
        &lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> &lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;&gt;&gt; wrote:<br>
<br>
<br>
<br>
             On 2/27/2014 11:31 PM, Travis De Silva wrote:<br>
<br>
<br>
                 As per your future plans, if we can get a stateless<br>
        keycloak<br>
                 co-location<br>
                 option and also enable external config in a DB when you<br>
        refactor the<br>
                 adapter code, that should cover the needs of most<br>
        developers who<br>
                 want to<br>
                 go beyond the out of the box solutions.<br>
<br>
                 BTW, I hope with the above changes it would be possible to<br>
                 associate one<br>
                 war with multiple realms and this is not a core<br>
        keycloak structure<br>
                 design issue.<br>
<br>
<br>
             How soon you need this by?  Yesterday?  ;)<br>
<br>
<br>
        In our project, I was going to build the security model with social<br>
        login and was on the verge of using an open source social login<br>
        library<br>
        to start building it when like god sent the keycloak project<br>
        appeared :)<br>
        So I am not the one to demand and happy with the little miracles<br>
        that<br>
        come my way. Having said that, yesterday would be great :) But<br>
        seriously<br>
        if your Jira roadmap is sort of an indicator and beta 1 would be<br>
        released end of Match, that timeframe is fine for us :)<br>
<br>
<br>
             Like I said earlier, I don&#39;t think colocation is necessarily a<br>
             requirement if we a) provided an option for public clients<br>
        (don&#39;t<br>
             require a client secret) or b) you had a shared secret between<br>
             clients for all realms.  The adapter would just extract the<br>
        realm<br>
             name from the request, invoke on the keycloak server to get the<br>
             public information about the realm (i.e. public key), then<br>
        cache<br>
             this information locally.<br>
<br>
<br>
        I guess a shared secret would do. Just wondering why we can&#39;t<br>
        use the<br>
        keycloak-admin realm as the top level realm and use it&#39;s secret<br>
        to get<br>
        the realm info to be cached locally and from that point onwards, it<br>
        falls into the current keycloak flow.<br>
<br>
        I am assuming that the individual keycloak realm admins (as per the<br>
        change done by Stin on KEYCLOAK-292<br></div></div>
        &lt;<a href="https://issues.jboss.org/__browse/KEYCLOAK-292" target="_blank">https://issues.jboss.org/__<u></u>browse/KEYCLOAK-292</a><div class=""><br>
        &lt;<a href="https://issues.jboss.org/browse/KEYCLOAK-292" target="_blank">https://issues.jboss.org/<u></u>browse/KEYCLOAK-292</a>&gt;&gt;) will not be<br>
        able to view<br>
<br>
        the keycloak-admin realm info.<br>
<br>
             Bill<br>
<br>
<br>
             --<br>
             Bill Burke<br>
             JBoss, a division of Red Hat<br>
        <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
<br>
<br>
<br>
    --<br>
    Bill Burke<br>
    JBoss, a division of Red Hat<br>
    <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
<br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br></div>