This repository has been archived by the owner on Oct 12, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 23
Realms to implement Multi Tenant Deployments
Mike Schwartz edited this page Apr 19, 2021
·
4 revisions
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".
-
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
-
persistence
: Database could be either RDBMS or Couchbase. Couchbase might be interesting because of its loose schema enforcement and good horizontal scalability.