[keycloak-user] Scalable architecture for multi-tenant (multi-resource) auth solution

Yuriy Yunikov yuriy.yunikov at verygood.systems
Fri Mar 16 16:55:42 EDT 2018


We're evaluating two different architectures for setting up KeyCloak to
allow users to grant access to other users and third parties to tenants
within our system.

I'm looking for experienced feedback on these to try and save some time
with experimentation.

## First approach *Dynamic Client Registration*

In this approach we would have several static services (resource servers)
that orchestrate access and then each tenant is represented via a
dynamically registered client.

We would then have a static set of roles (permissions) which are assigned
between the user and client when they are granted access.

The total universe of roles is then fixed. The proliferation here is
between users and clients or resource-servers and clients.

## Second approach *Dynamic Role Generation*

In this approach we're considering dynamically generating roles
(permissions) for each tenant in the system. We're thinking of mirroring
AWS's URN style so that the permissions look something ssl_certificate_key

They follow the general structure `urn:service:tenant:permission`

E.g.

- urn:service-1:tenant-id-1:read
- urn:service-1:tenant-id-2:read
- urn:service-1:tenant-id-1:write
- urn:service-1:tenant-id-1:admin
- urn:service-2:tenant-id-1:read

This is very simple and powerful but we have the potential for the JWT to
proliferate in size as we connect a user or service to more and more
tenants.

I feel like the first approach is more standard but requires us to add more
complexity into the system since we have to deal with registering clients
and guiding the user through the auth delegation flow each time they want
to grant a server access to a client that they own.
The second approach is dead simple technically but less standards
compliant.

We've been evaluating Authorization API
<http://www.keycloak.org/docs/latest/authorization_services/index.html#_overview>
(UMA) for this, but it's doesn't fit at the moment as there are number of
unresolved issues on KeyCloak which have to be addressed.
https://issues.jboss.org/browse/KEYCLOAK-4134
https://issues.jboss.org/browse/KEYCLOAK-6321
https://issues.jboss.org/browse/KEYCLOAK-5737
https://issues.jboss.org/browse/KEYCLOAK-6868
https://issues.jboss.org/browse/KEYCLOAK-6547

What do people tend to do in the real world to address this issue?
Our system has an unlimited number of tenants but realistically each user
is going to be associated with a few dozen at most. Third party
applications (which are all dynamic clients) will potentially be associated
with hundreds or thousands of other clients.


More information about the keycloak-user mailing list