3:23 a.m.
Hi
Just curious whether there have been discussions with the KeyCloak project on the
boundaries with Hawkular Accounts?
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?
Regards
Gary
3:43 a.m.
-----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-----
3:53 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:08 a.m.
+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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4026
days inactive
4026
days old
3 comments
3 participants
participants (3)
-
Gary Brown -
Juraci Paixão Kröhling -
Thomas Heute