[keycloak-user] Multi Tenancy

[Travis De Silva]

yes that sounds great. Thanks Bill


On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke <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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140302/20c6a82e/attachment-0001.html