[keycloak-user] Multi Tenancy

[Travis De Silva]

for now Wildfly would do. It would be great if this can be part of Alpha 3
:)


On Tue, Mar 11, 2014 at 10:41 AM, Bill Burke <bburke at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140311/4c1670f7/attachment-0001.html