SSO for Multi-org Customers
You set up sso for multi org customers by linking identity providers to tenant groups. Each tenant maps user group claims to local app roles during login. Many teams build this setup by sharing one broad admin role across tenants. When roles are too broad, one user can change data in every tenant space. How to set up sso for multi org customers Multi-tenant apps need a clear boundary between customer workspaces and internal support teams. You start by creating separate tenant workspaces insid
Multi-Factor Authentication (MFA) + Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up sso for multi org customers by linking identity providers to tenant groups. Each tenant maps user group claims to local app roles during login. Many teams build this setup by sharing one broad admin role across tenants. When roles are too broad, one user can change data in every tenant space.
How to set up sso for multi org customers
Multi-tenant apps need a clear boundary between customer workspaces and internal support teams. You start by creating separate tenant workspaces inside your central login provider. Each customer links their own identity provider through standard SAML or OIDC protocols.
When a user logs in, the identity provider sends a signed token. This token holds the user email, tenant ID, and assigned group names. Your app reads the token and checks the digital signature against stored keys. Next, the app matches the tenant ID to the right customer workspace.
Group claims inside the token decide which role the user gets at login. A support engineer might belong to three customer workspaces with read-only rights. An admin might hold write rights in one workspace and no rights elsewhere. You can also sync directory groups ahead of time so roles update fast. When a user leaves a customer team, directory sync removes their role right away.
Why role mapping across tenants needs extra checks
Setting up tenant login rules solves the problem of who can enter each workspace. It stops unknown users at the door and removes shared password lists. Central identity providers also let customer admins manage their own team members.
Still, login checks only run once when the user starts a new session. Once inside the workspace, the user holds all rights tied to that role. Native login tools do not inspect what individual queries or commands do in flight.
This gap matters when engineers switch between many customer tenants during one shift. An engineer with a shared admin role can run a delete query by mistake. Native login logs show that the engineer logged in at nine in the morning. They do not record which database rows changed or which commands ran later.
Multi-Factor Authentication (MFA) + Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Broad tenant roles also expose private customer fields during routine support work. When a developer runs a select query, the database returns full records. Those records often hold emails, phone numbers, card numbers, or national IDs. Without query-level checks, every user in that role gets raw data in results. You need controls that check every command and mask sensitive fields in flight.
How to keep tenant roles scoped and safe
Start by splitting broad admin roles into smaller task roles for each tenant. Give read-only roles to most support staff and keep write roles empty by default. Map each role to a dedicated group claim in the identity provider.
Set short token lifetimes so the app checks group membership often during the day. Short sessions make sure role changes take effect without waiting for the next week. Log every tenant switch so auditors can trace which workspace an engineer entered. Pair your login setup with runtime checks that approve risky commands before they run.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How can one user belong to multiple customer tenants with one email?
Your login system maps one user identity to multiple tenant membership records. At login, the user picks a workspace and receives a token scoped to it.
What happens when a customer removes a user from their identity provider?
Directory sync removes the user from the tenant workspace right away. Any active session ends as soon as the current short-lived token expires.
Does multi-org SSO stop engineers from running bad queries in a tenant?
No, SSO only checks identity and assigns a role when the session starts. You need command-level controls and data masking to guard queries in flight.