🌐 Language: English Version | 中文版
Summary: Business users—the identities through which a person participates in business activities—can be authorized independently, while some resources remain jointly held under their login user. Using personal experimental compute quotas shared across project identities, this article discusses acting identities, resource ownership, consistency boundaries, and how the identity relationships can later extend to a person entity.
In IAM User Model: Trade-offs in Separating Login Users and Business Users, I discussed how one login user can be associated with multiple independent business users. Qualifications, authorization, and business relationships can be managed separately. Ending one relationship need not affect the other identities.
Following that model further raises another question: once business users are separated, should resources also be separated by business user?
Using the business user ID as the ownership reference for all data would make the implementation more uniform. But some resources belong to a broader scope than a single business user. Switching identities does not give the same person another allocation. Conversely, bringing those resources together does not mean that existing business data and permissions should all be merged.
Separate business users do not always need separate resources
Consider an internal experimental compute platform at an enterprise. An engineer participates in projects A and B using the same login user, with a separate business user in each project. Each project independently manages its code, experiment records, and access permissions.
The platform also provides a personal experimental compute quota: each person can use 20 hours of compute resources per month for exploration and validation. The enterprise allocates this quota centrally, regardless of how many projects a person joins, and it does not consume the projects’ own budgets. This scenario serves only to illustrate the model.
After the engineer uses 6 hours through their project A identity and switches to project B, their remaining personal quota is still 14 hours. Switching to the business user for project B should not give them another 20 hours.
If each business user had a separate quota account, the same person would receive two allocations. Project identities would remain isolated, but the personal quota would no longer follow the allocation rule.
Another option would be to associate all data with the login user. That could consolidate the quota, but it could also blur the boundaries between business relationships and records that need to remain independent.
I chose to retain the existing responsibilities of business users and explicitly identify the resource owner in domains that require shared ownership.
Data ownership therefore needs to be considered domain by domain. The identity model provides subjects that can be referenced; domain rules determine who owns a particular resource.
One operation, two subjects
In this example, each experimental task needs to answer two questions: which project identity is acting, and whose personal quota is being consumed?
The first determines whether that identity is eligible to perform the operation and records the business context in which it occurred. The second determines where to look up the available quota and where to record consumption.
| Question | Relevant subject | Example |
|---|---|---|
| Can the operation be initiated or performed? | Current business user | Whether this business user is eligible to submit experimental tasks |
| Which identity is recorded as the actor? | Current business user | Which business user was recorded when the task was initiated |
| Who owns the resource? | Login user to which the business user belongs | The login user holds the personal quota, which does not change when identities are switched |
| How is ordinary business data isolated? | Current business user | Data is organized by project; the current business user’s project relationships and permissions determine access scope |
flowchart TD
L[Login user] --> A[Business user A]
L --> B[Business user B]
A --> PA[Check eligibility for business user A]
B --> PB[Check eligibility for business user B]
PA --> R[Login user's personal resource quota]
PB --> R
The two paths represent resource operations after their respective authorization checks. They do not imply that the two identities automatically have the same permissions.
An operation record can retain both the business user and the resource owner. This makes it possible to explain what changed in the resource and which business user initiated the change.
I did not change all business records to use the same ownership model. Relationships that belonged to business users remain there, while the quota domain explicitly uses its own ownership subject. The cost is that callers need to understand the distinction between the two identifiers; a vague notion of “user” can no longer cover every meaning.
A business user belongs to a fixed login user
In this model, every business user belongs to one specific login user and cannot be reassigned to another after creation. A login user can be associated with multiple business users, while the reverse relationship is unique and fixed.
Starting from any business user, its login user can therefore be identified. Disabling the project A identity changes its eligibility to act. It does not change which login user it belongs to or transfer its previous quota consumption to someone else.
Within the current scope, where each person corresponds to one login user, the personal experimental compute quota can belong directly to that login user. This avoids an additional person entity and the maintenance of its mappings, while preserving independent authorization and business relationships for each business user.
If one person is later allowed to have multiple login users, the relationship from business user to login user still holds. The additional relationship needed is from login users to a specific person:
flowchart LR
A[Business user A] --> L1[Login user 1]
B[Business user B] --> L1
C[Business user C] --> L2[Login user 2]
L1 --> P[Same person entity]
L2 --> P
P --> R[Personal resource quota]
Business systems still resolve the login user from the business user, then follow the explicitly established person relationship to determine quota ownership. Consolidating quotas by person requires corresponding changes to resource accounts and existing data, but does not require changing the fixed ownership relationship of business users.
The extension path is to add a person layer after the existing relationships. Person relationships require explicit confirmation; matching email addresses or display names is not enough to merge identities automatically. Resources held by projects, such as project budgets, continue to follow their own ownership rules.
Interfaces express both identity and ownership
Once the model distinguishes the two subjects, interfaces need to preserve that distinction.
Existing integrations often already use a user identifier for authorization and business data associations. Changing its meaning to introduce a shared quota could leave requests flowing normally while callers start querying data for a different kind of subject. Field types alone are unlikely to reveal that change.
My choice was to preserve the business user meaning of the existing identifier and add a resource owner identifier to calls that need it. Domain method parameters also distinguish the acting identity from the ownership subject, reducing reliance on callers remembering implicit conventions.
The server determines resource ownership from verified identity relationships. A client may select the target of a business operation, but the server still checks whether that operation is allowed. An ownership identifier supplied in a request cannot itself be treated as a trusted identity relationship.
Adding an identifier increases the cost of understanding the interface contract, but that cost is easier to manage than one field silently changing meaning across services. Preserving field semantics is also only the starting point for compatibility work. Authorization checks and data queries throughout the call chain still need to be examined separately.
Ownership scope is also the scope of concurrency checks
Associating new records with the correct subject is only part of the work. Whether resources still satisfy the rules also depends on reads and writes using the same scope.
Suppose the engineer has 4 hours left and simultaneously submits two tasks, each requiring 3 hours, through their project A and project B identities. Both requests read a remaining balance of 4 hours. If each successfully reserves 3 hours, the total reservation reaches 6 hours, exceeding the available balance.
If concurrency control covers only an individual business user, the two requests will not wait for each other. Because the same subject holds the quota, contention occurs at the scope of that subject and the corresponding resource.
Possible implementations include conditional atomic updates or reading, validating, and writing within the lock scope of a single transaction. Storage choices and resource rules affect the implementation, but the constraint to protect is the same: competing operations on one resource need to make their decisions within the same consistency boundary.
There is no need to serialize all of a person’s business operations. The scope can be divided further by owner and specific resource. Finer granularity allows more parallelism, but it also requires checking that a single constraint has not been split across scopes that do not coordinate.
Asynchronous processing follows the same ownership relationship
Experimental tasks may run in the background. Quota is reserved at submission based on the estimated duration, then settled against actual usage on completion, with any unused reservation released. The background executor and the engineer who initiated the task are different acting subjects, but the executor still handles the personal quota already reserved for the original task.
The task retains the business user that initiated it. Subsequent processing can follow that business user’s fixed login user relationship and use the task’s quota period to locate the specific resource account. The quota record can also retain a direct reference to that account for settlement and queries. Whether to store that reference redundantly depends on domain records and query requirements; the fixed identity relationship already provides a deterministic resolution path.
What needs to be avoided is treating the background executor or the person currently viewing the task as the quota owner. Those are roles in the execution context. The original task’s business user and its login user provide the basis for attributing the resource operation.
Even after the business user is disabled, the task can still be traced to the original resource account. Whether it should continue running, and who may cancel it, are separate decisions governed by task rules and current permissions. The identity relationship locates the owner; the business user’s status and authorization determine whether an operation is allowed.
If the background process receives the same task completion notification more than once, it also needs to deduplicate by that task’s settlement event to avoid repeated deductions. This is a separate concern from whether a business user’s ownership relationship is fixed.
Shared resources still require separate authorization decisions
Sharing a quota between two business users addresses resource ownership. Their permissions to query, consume, or manage it may differ.
For example, the project A identity may submit experimental tasks, while the project B identity may only view project results. Even with 14 hours of personal quota remaining, the engineer cannot submit a task through the project B identity. Sufficient quota and an eligible project identity are two independent conditions. Sharing a personal quota also does not automatically give the project B identity access to project A’s experiment records.
This is also why the business user layer remains: resource accounting can be unified within a domain while access control continues to express differences between business relationships.
The implementation needs to address both whether the current business user may perform the operation and whether the target resource falls within its authorized scope. Checking only one of these is insufficient to express the full access constraints.
The costs of this choice
Introducing a resource ownership subject means each relevant call needs to make clear whether it concerns the acting identity, resource ownership, or both. Interfaces, queries, audits, and asynchronous events all need to carry these semantics.
Adding an identifier does not automatically give existing data the correct ownership. The kind of subject referenced by historical records, distinctions hidden by numerically identical IDs, and whether previously separate resources may be merged all need individual confirmation. The new model can guide future writes, while historical migration remains a separate task requiring evidence.
If business users and resource owners always correspond one to one, retaining a single subject may be more straightforward. The distinction becomes useful when their lifecycles or management scopes actually differ.
This round of design led me to revisit what “user ID” means within a domain. An identifier can conveniently associate many tables, but it cannot replace a decision about ownership rules. I retained the independence of business users, made resource ownership explicit in the domains that need it, and accepted the additional costs of managing contracts and consistency.