3:03 p.m.
Good to know about your approach to multi-tenancy. It is an interesting
solution.
On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca <
federico.facca(a)martel-innovate.com> wrote:
Dear Pedro,
this is a very relevant discussion to us. We currently solved the issue
using a single realm,
and using "root" level groups with a attribute "tenant=true". We have
then
created a custom
client to manage this configuration from the single "tenant" admin
perspective.
Could you elaborate more on that, please? I understand how you are using
groups and the tenant attribute, but what you exactly mean by "custom
client to manage this configuration" ?
I guess you all your tenants share the same security policies defined on
the realm level too?
This solution for us allows to manage "multi-tenancy" also at the single
oidc client without
much complexity (your approach wouldn't allow for that, right?)
Do your users have access to different tenants? When issuing tokens to
these users, do you have roles within the token for each tenant the user
belongs to?
Of course we had to use some tricks to do fine grained control
access,
which is basically working under the assumption you attach users to groups
and you
manage roles attached to groups and not to users. Then, within the token,
we return
user roles per client based on their group membership.
Cheers,
Federico
On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva(a)redhat.com> wrote:
> Hi,
>
> As you know, currently users belong to a realm and as such, you can't
> share
> them across different realms. We always had people looking for
> alternatives
> about how to solve this problem where all the available options have their
> pros and cons.
>
> I would like to see what you think about decoupling users from realms in a
> way that user federation and management are completely decoupled from
> realms so that users (or group of users) can be *associated* with realms.
>
> As an example, here is how you would configure users and realms in
> Keycloak:
>
> 1) Configure your identity stores/user federation from where users will be
> fetched. Or create users in Keycloak.
>
> 2) Assign to your users a label or a logical group. This assignment could
> be done manually or even automatically depending on:
>
> a) default group where all users are in
> b) the identity store from where users are fetched
> c) based on the user's email (domain)
> d) anything else that makes sense
>
> 3) Create a realm and specify which users should belong to a realm based
> on
> these labels or groups. A realm should be able to have users with
> different
> labels/groups.
>
> The realm definition/configuration would not change much as it stands
> today. Each of them would still have their own way of managing realm
> specific groups and roles.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
MAKE IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>