<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
<br>
On 2/27/2014 11:31 PM, Travis De Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As per your future plans, if we can get a stateless keycloak co-location<br>
option and also enable external config in a DB when you refactor the<br>
adapter code, that should cover the needs of most developers who 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 associate one<br>
war with multiple realms and this is not a core keycloak structure<br>
design issue.<br>
<br>
</blockquote>
<br></div>
How soon you need this by? Yesterday? ;)<br></blockquote><div><br></div><div>In our project, I was going to build the security model with social login and was on the verge of using an open source social login library to start building it when like god sent the keycloak project appeared :) So I am not the one to demand and happy with the little miracles that come my way. Having said that, yesterday would be great :) But seriously if your Jira roadmap is sort of an indicator and beta 1 would be released end of Match, that timeframe is fine for us :)</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Like I said earlier, I don't think colocation is necessarily a requirement if we a) provided an option for public clients (don't require a client secret) or b) you had a shared secret between clients for all realms. The adapter would just extract the realm name from the request, invoke on the keycloak server to get the public information about the realm (i.e. public key), then cache this information locally.<span class=""><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>I guess a shared secret would do. Just wondering why we can't use the keycloak-admin realm as the top level realm and use it's secret to get the realm info to be cached locally and from that point onwards, it falls into the current keycloak flow.</div>
<div><br></div><div>I am assuming that the individual keycloak realm admins (as per the change done by Stin on <a class="" href="https://issues.jboss.org/browse/KEYCLOAK-292" id="key-val" rel="12532035" style="font-family:Arial,sans-serif;font-size:14px;line-height:20px;color:rgb(51,51,51);text-decoration:none">KEYCLOAK-292</a>) will not be able to view the keycloak-admin realm info.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888">
Bill</font></span><div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>