[Hawkular-dev] Relationship between Accounts and KeyCloak

Thomas Heute theute at redhat.com
Thu Mar 26 05:08:28 EDT 2015


+1

On 03/26/2015 09:53 AM, Gary Brown wrote:
> Ok thanks - that sounds like a good approach.
>
> Regards
> Gary
>
> ----- Original Message -----
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/26/2015 09:23 AM, Gary Brown wrote:
>>> Just curious whether there have been discussions with the KeyCloak
>>> project on the boundaries with Hawkular Accounts?
>> Sort of. There were some discussions with some KC members about multi
>> tenancy, which is really the "key" feature we need. Unfortunately, our
>> model of multi tenancy doesn't match nicely with Keycloak's.
>>
>> Basically, Keycloak's multi tenancy capability is achieved in the form
>> of realms: each realm is a tenant. In our case, that could work (we
>> even contributed some code for allowing multi tenancy on the adapter
>> side), *but*, there we have a scenario where users from one tenant
>> would be given permission to access resources from another tenant. And
>> there's no easy/pretty solution for that, as it's a conceptual
>> mismatch, not a technical one.
>>
>>> Its just it seems like concepts such as Organizations and Roles
>>> are generic and therefore should really be work contributed to
>>> KeyCloak, leaving just the relationship from Orgs/Users to
>>> resources as Accounts specific?
>> Indeed. I sent an email to the PicketLink lead last week, as it's a
>> component that already has all the features we need (on the
>> Permissions API), including multi tenancy (with the concept of
>> partitions, which relates to our 'organizations'). But the work in
>> integrating PicketLink and Keycloak will still take some time. And
>> this specific part of PicketLink is dependent on PicketLink IDM,
>> conflicting with Keycloak, so, we can't use that as a standalone
>> component.
>>
>> My plan is to ditch our custom code as soon as possible, as much as
>> possible, to reuse what can be provided by specialized frameworks and
>> tools. But "as soon as possible" is, as of now, "not soon enough for MVP
>> ".
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQEcBAEBAgAGBQJVE8a+AAoJECKM1e+fkPrXzL0H/jaI6+rYNSibEPKf5ormkB3r
>> 9KpX7HapkLrvpGwBXRW+L8WPAbeMncZnkbbmQMlrn4SrjUIUb9qibKYcAr44n7mG
>> tvZNYye0+Z3+K0i9RxQ+W4rrsLvseRfaywcO1sr7UQkVLLOthK3fWQ9797TJ0Re7
>> pNY5rI0ae9iBaHxHKc0OoWdsqLZPWuKBHtL+Yrntwb7dLL3Kpu2+WPJgsCtOeEQZ
>> 7pebdESjBV/sNZoMh9yXJQoKlniC82lniWrWRfJ3QGH5MylkjEdp1bOnkpxo3OSY
>> pim8qSgvNPFOE1d2qTxa3KC0pERFNvaeSv9EMlyjqTAJ/pCPwEh29eL0YRHXjYM=
>> =QP2u
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



More information about the hawkular-dev mailing list