Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Realms to implement Multi Tenant Deployments

Mike Schwartz edited this page Apr 19, 2021 · 4 revisions

Multi-Tenant Deployment

For years people have asked, "What about multi-tenancy". While cloud native has driven down the cost of single-tenant deployments, multi-tenancy is still more cost effective. For this reason, let's think about how Janssen Auth Server could be modified to support multiple "Realms".

Functional considerations

  • dns: Each customer OP would need its own DNS hostname so that session cookies in the web browser are not shared
  • open-configuration: each customer may have its own openid-configuration endpoint to customize claims, scopes, signing and encryption algorithms, and acr's
  • acr: All customers will have to share authentication mechanisms. Custom scripting could not be allowed.
  • scim: All users would have to be tagged for a realm. Admins should only be able to create/update/delete/search users in their realm
  • config-api: Realm would be required for config-api calls. For example, only clients, scopes and claims for the realm should be visible via the API. We will have to limit or eliminate some API calls for realms.
  • Authn-API: This client API will provide an API simpler for developers then pure OpenID Connect

Deployment considerations

  • persistence: Database could be either RDBMS or Couchbase. Couchbase might be interesting because of its loose schema enforcement and good horizontal scalability.