Map SSO Users to Tenants

Single sign-on proves an identity under an identity provider's rules. It does not, by itself, decide which tenant the person may enter. A matching email domain can be a useful routing hint, but it can be wrong after a domain transfer or account change. The OpenID Connect Core specification defines identity claims; your application must supply the membership policy.

Claim-to-membership map

Bind the external identity to the tenant connection that the organization configured. Do not accept a client-supplied tenant ID as the final authority. Record which claim changes update a local role and which require an administrator decision.

Test conflicting states

Use synthetic identities for Tenant A and B. Test an A user with a B-looking email, a user whose email changes, a subject from a different issuer, and an account already linked to another tenant. Verify the final membership and session tenant, not only a successful login. Then remove a group or local membership and check how active access changes.

OWASP Authorization supports explicit grant decisions after authentication. This mapping artifact keeps identity proof and tenant authorization separate. It should include an owner for each claim source and an exception process for conflicts. If a rule depends on an IdP feature, verify the exact provider configuration before publication or deployment. A user who can sign in is not automatically a member of every organization with a matching domain.

Illustrative conflict: issuer I and subject S authenticate through Tenant A's configured connection, while the verified email ends in B's domain. Local membership grants A only. Expected session tenant=A; B access is denied until B grants membership through its own approved path. If the same subject arrives from issuer J, treat (J,S) as a different external identity and do not reuse A's link. Record the actual IdP claim names and connection mapping used by the product.