🌐 Language: English Version | 中文版
Summary: A login user represents an authentication identity; a business user carries business relationships. Separating them depends on whether business identities need to exist independently. Introducing tenants depends on service and administration boundaries.
The earlier discussion of enterprise unified identity governance focused on sharing authentication and identity management across business systems. Once authentication is unified, another modeling question remains: does one login account always represent the same participant in business operations?
Many enterprise systems begin with a single notion of a “user.” It is used for login, referenced by business records, and assigned permissions. This is straightforward when each person has one set of business relationships.
But one person may participate in several independent business contexts. Under the same login credentials, their qualifications, relationships, and responsibilities can differ. If one user object continues to carry all these meanings, each difference becomes another condition attached to it.
That is when I would reconsider whether login users and business users should be separated, and why that separation does not necessarily require a multitenant model.
The background to multiple business accounts
In enterprise systems, one person may hold several independent appointments or working relationships. For example, an employee may handle procurement for two companies within a group using the same login account, while each company separately manages their appointment, authorization scope, and period of validity. Ending one appointment should neither end the other nor require closing the login account.
Multiple business accounts here mean these independently managed participation identities, which this article calls “business users.” Each carries its own qualifications, relationships, and historical records, while authentication can still use one set of credentials.
If the differences concern only permitted operations, scoped roles may be enough. A separate business user becomes useful when the participation relationship itself needs to exist and end independently. Using multiple applications does not automatically require multiple business users. The earlier article on per-client authorization isolation at the gateway addressed application access boundaries; the concern here is the subject of a business relationship.
One “user,” two responsibilities
A login user first represents an authentication subject: it identifies the account through which the visitor authenticates.
A business user represents that account’s participation identity in a particular business context. Beyond whether someone can log in, the business needs to know whether they qualify to participate, their business status, and to whom an operation should be attributed.
The two often appear together, which makes it easy to treat them as one object. But they change for different reasons.
For example, leaving one business activity does not necessarily invalidate a person’s login account. Authentication may still be needed for other activities. Conversely, successful authentication does not establish eligibility for every business activity.
When these distinctions start affecting everyday operations, “user” becomes more than a convenient shared name. It covers two concepts that need separate expression.
Giving relationships a clear subject
The model discussed here is simple: one login user can be associated with multiple business users.
flowchart TD
L[Login user
Authentication subject] --> A[Business user A
One set of business relationships]
L --> B[Business user B
Another set of business relationships]
A and B represent two independent business identities. The diagram does not assume that they belong to different applications, organizations, or tenants.
The login user retains its authentication meaning. Business qualifications, states, and relationships belong to the corresponding business user. A person can continue using one login account without merging several business relationships into one.
This also explains why adding roles is sometimes insufficient.
In Pulling Permissions Out of the Menu, roles organize permissions. That responsibility remains here: if the difference is only “which operations are allowed,” assigning different roles to one user may be sufficient. But when appointments, working relationships, and the attribution of actions need separate records, the business subject to which those permissions attach also needs to be explicit.
The reason to separate the model is that business identities need to exist independently. Roles can still be assigned to business users to express their permissions; the two serve different purposes.
Considering a tenant model
When one person has several business identities, a natural thought is to assign each identity a tenant to distinguish them.
Whether that model fits depends on what a tenant means in the system.
Multitenancy commonly expresses boundaries between customers or user groups sharing a service. It introduces questions about data ownership, administration, and resource sharing. A tenant can also represent an internal business unit, rather than only an external SaaS customer. Microsoft’s multitenant architecture overview likewise distinguishes tenants from users.
Separating login users and business users addresses a different question: which business subjects correspond to a given account?
| Model | The first question it needs to answer |
|---|---|
| Login user | Through which account does the visitor authenticate? |
| Business user | Who holds the qualifications, relationships, and responsibilities in this business context? |
| Tenant | Which users and resources share a service or administration boundary? |
If the business identities belong to independent tenants, organizing them by tenant is natural. But if the difference concerns participation identities alone, without a corresponding tenant boundary, introducing tenants adds another concept that needs explanation.
For example, someone may have two business identities within the same service boundary. Treating them as two tenants raises further questions: why do the tenants share business resources? Do they need separate administration scopes? Which relationships may cross tenant boundaries?
These questions may not have been part of the original requirement, yet they become part of the design.
Where no independent tenant boundary exists, separating login users from business users more directly expresses the problem. It adds a business subject with a defined purpose without interpreting every identity difference as a tenant difference.
Both models can coexist
Separating login users and business users is compatible with multitenancy.
If a system serves several independent tenants, one login user can be associated with business users in different tenants. Authentication identity and business identity within a tenant can still be separate.
In some systems, a user–tenant membership is enough to carry the business identity. In others, a business user needs its own state and relationships. Its name, and whether it becomes a separate entity, depend on the business meaning it needs to express.
Multitenancy also does not require each tenant to maintain separate login credentials. The decision to split the user model should therefore not rest on an assumption that multitenancy necessarily requires repeated registration.
I find it more useful to identify the business subject first, then the tenant boundary. If they coincide, the model can remain compact. If they do not, there is no need to collapse them into one concept.
Preserving existing business relationships during the split
In an existing IAM integration landscape, business systems often already use user IDs to associate permissions, business records, and historical actions. Giving every business user a new ID during the split would require migrating those relationships as well.
Where an existing user originally had one business identity, a compatibility choice is to let the business user inheriting those relationships retain the original user ID, while additional business identities receive separate IDs. Existing records can then keep referencing the same identifier, reducing changes to relationship data and the way integrations read identifiers.
What this preserves is identifier continuity. Even if a login user and a business user have the same numeric ID, they remain objects with different responsibilities. Matching IDs are a migration accommodation and should not become a dependency in new business logic.
This choice is particularly useful when most users still have only one business identity: the model can accommodate additional identities without requiring existing integrations to replace all user identifiers. Compatibility still depends on the identity semantics, authorization decisions, and data scopes those integrations actually use. Retaining IDs reduces migration scope; it does not by itself establish that every integration is unaffected.
Where the complexity moves
The benefit of the split is that changes can belong to the appropriate object. Ending one business qualification affects its business user, while the login account’s authentication status has its own meaning. Historical records can continue pointing to the business subject involved at the time.
The cost is that the system can no longer use an ambiguous “user” for every scenario. Business operations need an explicit business user, and action records need to distinguish authentication subjects from business subjects.
This adds model comprehension and relationship maintenance costs. Splitting the model does not automatically provide permission isolation; authorization still depends on the actual business subject and business rules.
Not every system benefits from this separation. If a login user always corresponds to one business subject and roles can express all relevant differences, a simpler model may be more appropriate.
When business relationships do need independent existence, the split expresses complexity already present in the business rather than introducing it ahead of need.
Choosing the model through responsibilities
User models tend to expand as features accumulate: another state, another set of roles, another scope of membership. Each addition can solve an immediate problem while gradually giving “user” several different meanings.
I prefer to revisit object responsibilities when those meanings begin changing independently. Authentication needs a stable login subject; business activities need participants that can express their own relationships. The two are associated, but they can have separate lifecycles.
Whether tenants belong in the model depends on service and administration boundaries. Establishing why an object is needed before deciding how it relates to other objects helps keep the model grounded in the problem being addressed.