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.
On 3/2/2014 5:05 AM, Travis De Silva wrote:
<mailto:bburke@redhat.com>> wrote:
I'll work on refactoring the adapters next week to help support
this. Maybe if I get things cleaned up enough and provide some bare
bones support for multi-tenancy you could take it over to help drive
for your requirements?
On 2/28/2014 3:57 PM, Travis De Silva wrote:
On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com><https://issues.jboss.org/__browse/KEYCLOAK-292<mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
On 2/27/2014 11:31 PM, Travis De Silva wrote:
As per your future plans, if we can get a stateless
keycloak
co-location
option and also enable external config in a DB when you
refactor the
adapter code, that should cover the needs of most
developers who
want to
go beyond the out of the box solutions.
BTW, I hope with the above changes it would be possible to
associate one
war with multiple realms and this is not a core
keycloak structure
design issue.
How soon you need this by? Yesterday? ;)
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 :)
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.
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.
I am assuming that the individual keycloak realm admins (as per the
change done by Stin on KEYCLOAK-292
<https://issues.jboss.org/browse/KEYCLOAK-292>>) will not be
able to view
the keycloak-admin realm info.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com