User has multi tenants with different roles

[Alexander Schmidt]

Hi guys,

I'm thinking about how to best model the following scenario:

- only one realm for everything

- a group represents a tenant

- a client represents an application

- a client role represents a role in a certain application

- a user can be assigned to many groups (tenants)

- for each group (tenant) the roles could differ (i.e. user A is in group B an ADMIN and in group C a REPORTER)

I'm struggling in particular with the last point "a user has multi tenants with different roles".

Considering using a relam for each tenant would make it impossible for a user to be in multiple tenants, so this is probably no option for my case.

Are there any best practices or approaches at all with keycloak to model this scenario?

Thank you!

Alex Schmidt

[Garth]

This is a question that gets asked on this list in many different forms. And, as long as I've been following it, I haven't seen a great answer to "a user has multi tenants with different roles".

A couple approaches I've seen:
- Model the roles as groups and sub-groups. I.e. a top level group would represent the org, and the sub-groups to that group would represent the roles (e.g. user, admin, finance, etc.)
- Write extensions to Keycloak that add Organization and Team entities. Create mapping entities for Roles to User/Org and User/Team tuples. Build mappers that put those in the token as you need them.

However, both of these present the problem that other things in Keycloak that could rely on Role, do not work as expected.

Unfortunately, given that this is a pretty common use case (a SaaS application with a single user belonging to multiple Orgs/Teams, with different roles and permissions in each), it's too bad there isn't better support for this, or a more concrete best practice for solving it.

> --
> You received this message because you are subscribed to the Google
> Groups "Keycloak User" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to keycloak-use...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/keycloak-user/53a18578-ff94-4f6f-b005-eed51e7e9933n%40googlegroups.com <https://groups.google.com/d/msgid/keycloak-user/53a18578-ff94-4f6f-b005-eed51e7e9933n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Marco Lettere]

Yes, a very typical question indeed.
We had a similar use case with two more constraints. The organization
was a 3-level tree of contexts and every context exposed the same set of
roles.
A user may be in any of the levels having any combination of the roles
with no automatic hierarchical relationships.
We were not allowed to use multiple semantics for groups (contexts and
roles) as suggested by Garth because groups were needed in order to bind
to a pre-existing LDAP instance which had to be preserved for legacy
purposes. Thus groups correspond only to contexts but not roles.
Access to the infrastructures is granted through specific applications
called gateways which are orthogonal to contexts and may group together
access to different contexts.

The way we solved this is the following:

1) register one public client for every gateway (few) - lets call them
gateway clients
2) register one confidential client for every context (several dozens) -
let's call them context clients
3) create set of client roles for every context client (ten)
4) create a group tree reflecting the context tree and map to every
group the least powerful role of the corresponding context being
"Member" in this way a user belonging to a group is granted necessarily
at least the role Member of that context.
5) Grant access from a gateway through standard OIDC flow with
correspoding gateway client. Access Token with full scope carries, for
the identified user, all roles for every context.
6) Use the set of roles to allow the user to select the context he/she
wants to operate in.
7) Once the user selects a context, request an RPT (following UMA flow)
for the according context client. RPT doesn't have full scope. Thus it
carries only the permission for the user to access the Default Resource
of that specific context client.
8) Use this RPT to call backend services.

PROS: the model covers all the tricky requirements but still looks sound
to us. Every call to backend service carries only the required
information (user identity and context).
CONS: It is rather complex and thus required a significant effort in
order to automate all workflows for setup, provisioning and maintenance.

Hope that this is somehow useful and most importantly I'd like to have a
feedback on this.

Thanks,
Marco.