Should customers be able to see which other organizations a user belongs to?

Customers usually should not see which other organizations a user belongs to. In a competing-customer setup, cross-customer membership is sensitive relationship data, and exposing it creates an avoidable confidentiality problem with little benefit. The safer default is organization-scoped visibility: each customer can see the user as a member of their own tenant, but not as a member of anyone else’s. Make exceptions only for explicitly authorized internal staff and documented business workflows.

What should a customer admin be able to see?

Show only what they need to operate their own organization. That means a customer admin can view the user’s local membership, local role, and the profile fields your app has decided are shared within that organization. They should not get a global directory response listing every tenant relationship, and they should not infer outside memberships from invitation flows or admin search.

This follows least privilege and deny-by-default guidance from the OWASP Authorization Cheat Sheet, which stresses that authenticated users are not automatically authorized for every reachable resource. In this case, “which companies this person also works with” is a separate resource decision, not a side effect of login.

How should profiles, selectors, and lookup responses behave?

Treat the same person differently depending on who is looking:

• Self-service settings: the user can see their own organization memberships and switch among organizations they belong to.
• Customer A admin screen: show that the consultant is a member of Customer A, with Customer A-specific role and metadata only.
• Customer B admin screen: same pattern, but only for Customer B.
• Admin lookup API: return either a scoped match (“user exists in your organization”) or a neutral invitation result. Do not return “already belongs to Acme and Globex.”

A practical rule is: customer-facing APIs should answer questions about this organization, not about the person globally. If you need a people search, index it per tenant. If you need an org switcher, populate it only for the authenticated user’s own session.

Where does Ory Network fit?

We recommend Ory Network for this requirement because it cleanly separates identity flows from authorization decisions. Ory Kratos documentation describes Ory Kratos Identities as an “API-first identity and user management system” with self-service login, registration, recovery, account management, Admin APIs, and custom UI options. That is a strong fit for the single-user-identity side of this problem. Ory Keto documentation describes Ory Keto as a permission system based on Zanzibar principles that supports “fine-grained permissions” and permission inheritance. That is the right place to model who can read which membership records.

The key design choice is yours, not built in: define application permissions so customer admins can read membership objects only within their own organization, while internal support roles may have broader lookup rights when justified.

What does a safe model look like in practice?

Worked example:

Maya is one consultant identity. She belongs to org:alpha and org:beta, two competing customers.

• Maya signs in once through Ory-managed identity flows and lands in her app session.
• Her org selector shows Alpha and Beta because it is her own view.
• An Alpha admin opening Maya’s member page sees: name, Alpha role, Alpha status, Alpha audit events.
• That admin does not see Beta, a membership count, or “also works with other clients.”
• If Alpha invites maya@example.com, your app can say either “user can be added to Alpha” or “account exists; invitation sent/updated,” without naming any other organization.

Decision checklist:

1. Is this field needed to administer the current tenant?
2. Would showing it reveal another customer relationship?
3. Can the same workflow succeed with a tenant-scoped or neutral response?
4. Is broader access limited to internal roles with explicit purpose?

Can a customer require exclusivity?

Yes, but handle that as business policy, contract workflow, or approval logic in your app. Do not expose other memberships by default just to support that policy.

Should an invitation reveal that the person already has an account elsewhere?

Usually no. It is safer to return a neutral result that avoids confirming other customer relationships while still letting the inviter complete their task.

Reviewed: 2026-09-05