[keycloak-user] Multi Tenancy

[Bill Burke]

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:
> yes that sounds great. Thanks Bill
>
>
> On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke <bburke at redhat.com
> <mailto:bburke at 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 at redhat.com
>         <mailto:bburke at redhat.com>
>         <mailto:bburke at redhat.com <mailto:bburke at 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
>         <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
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com