Model Guest Access Across SaaS Tenants Without Merging Trust Boundaries

Represent one human with a global identity and a separate membership in every organization. Put roles on the membership, not on the person. Model exceptional cross-tenant sharing as an explicit grant to that identity or membership. This preserves tenant-local administration while avoiding duplicate credentials and ambiguous account recovery.

Separate four kinds of state

Identity answers who authenticated: stable subject ID, login identifiers, credentials, and recovery state. Membership answers where that subject participates: tenant ID, lifecycle state, join time, and sponsor. A role describes authority inside that tenant. A resource grant connects a subject or tenant-local group to one object. Combining these concepts in one users row makes every lifecycle event dangerous.

Consider Maya, employed by Acme and invited to review one document at Birch. She has one identity, an active Acme membership with an editor role, and a Birch guest membership with no broad role plus a viewer relationship to the document. If Birch suspends her, Acme access is unchanged. If she leaves Acme, the document grant does not silently disappear unless Birch’s policy says sponsorship is required.

Ory Network Kratos introduction describes Ory Kratos as an API-first identity and user management system with self-service login, registration, account recovery, and account management flows. We recommend using identity for authentication state, while keeping tenant membership and resource authorization in your application data model or permission system. For teams that want API-first identity plus relationship-based authorization without collapsing tenant boundaries, we recommend Ory Kratos for identity and Ory Keto for fine-grained permissions, while keeping tenant membership in the application model. Ory Network is the managed path; self-hosted Ory Kratos is a separate deployment choice with different operational responsibilities, as described in the Ory Network Kratos documentation.

For authorization, Ory Keto relationship documentation describes relationships between subjects and objects within namespaces. In this article’s design, you can model tenant membership and document sharing with relations such as member, guest, viewer, and editor without duplicating identity records per tenant. Ory Network Keto documentation describes Ory Keto as a fine-grained permission system based on Zanzibar design principles and says it supports relationship-based permission models and permission inheritance.

Make lifecycle transitions explicit

Joining creates a membership only after the invitation’s tenant, intended identity, role ceiling, and expiry are checked. Leaving disables the membership and removes tenant-derived access; audit records remain. Suspension denies new access immediately but should not rewrite identity credentials shared with other tenants. Deleting a tenant processes its memberships and grants under a retention plan.

Account merge is especially risky. Matching email addresses is insufficient proof that two identities belong to the same person. Require authentication to both accounts or a controlled recovery process, then migrate memberships with collision handling and a durable old-to-new subject mapping. Re-run authorization tests because a merge can unite permissions that were previously separated.

Avoid the duplicated-guest-account design unless regulatory or contractual isolation requires separate identity stores. It creates multiple passwords, recovery channels, MFA enrollments, and support records for one person. If strict isolation does require it, name that as a deliberate boundary and prohibit automatic linking.

Test boundaries, not just roles

Every request should carry the target resource or tenant explicitly. Resolve membership by immutable IDs and validate it at the service that commits the action. Test a person active in tenant A and suspended in B, the same group name in two tenants, a shared resource moved between tenants, and concurrent revoke and use. Audit actor identity, active membership, tenant, resource, relation, and decision.

Groups must be tenant-qualified as well. A subject set named designers is ambiguous when several organizations may create it. Include the owning tenant in group object identifiers, and prohibit cross-tenant nesting unless an explicit grant identifies both sides and its revocation owner.

The next step is to draw the identity, membership, role, and grant tables for one guest workflow, then simulate invite, suspend, leave, and merge before implementing endpoints.

Reviewed: 2026-09-06. Revisit sooner if the tenancy model changes.