Scalable architecture for multi-tenant auth solution

Question

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 (based on 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.

Answer 1

If you'd still want to continue with Keycloak and stick to those standards, I'd recommend you to look at Keycloak Authorization Services.

However, the other good solution is https://www.openpolicyagent.org/ where you can specify a policy for each tenant. It's not a part of OAuth 2.0/OpenID Connect, but it scales nicely across multiple services because it can be deployed as a sidecar, but you'd need to build some permissions storage service with it.

UPDATE: Check out the blog post related to this topic: https://blog.verygoodsecurity.com/posts/building-a-fine-grained-permission-system-in-a-distributed-environment