Realm-scoped customer identities, tenant memberships, authentication authority, invitation activation, ownership boundaries, and tenant-scoped application sessions.
This document defines the customer identity and access model shared by Dream Consistency products. It establishes the relationship between Realm Accounts, Tenants, TenantApplications, product-specific roles and permissions, invitations, authentication, and application sessions.
AUT_USR_AccountID is the stable customer identity.
Tenant membership and tenant-specific ownership are properties of
AUT_USR_AccountTenantMemberships.
| Area | Status |
|---|---|
| Realm-scoped Account identity | Locked architecture |
| Account-to-Tenant membership model | Implemented in Realm schema 1.6.0 |
| Membership lifecycle catalog | Implemented and installed |
| Initial owner membership provisioning | Implemented in Hestino.Management.Api |
| Existing Account reuse during provisioning | Target architecture; implementation pending |
| Realm-wide normalized email uniqueness | Target architecture; schema change pending |
| Invitation-driven membership activation | Target architecture; implementation pending |
| Multi-workspace login | Target architecture; implementation pending |
This architecture applies to customer Accounts used by Dream Consistency products such as Hestino and Legislator. It does not merge customer identity with Dream Consistency internal Core operator identity.
| In Scope | Out of Scope |
|---|---|
| Customer Account identity inside one Realm | One customer identity spanning multiple Realms |
| Account membership in multiple Tenants | Cross-Realm customer account synchronization |
| Tenant-specific ownership | Core operator identity |
| Authentication and scoped sessions | External OIDC/SAML federation |
| Invitation and membership activation | Social login providers |
| Workspace selection for multi-tenant Accounts | Platform-global identity directory |
| Layer | Main Question | Authority |
|---|---|---|
| Realm Account | Who is the customer user? | AUT_USR_Accounts |
| Tenant Membership | Which Tenants may this Account participate in? | AUT_USR_AccountTenantMemberships |
| TenantApplication | Which Dream Consistency application is active for this Tenant? | TEN_APP_TenantApplications |
| Product Authorization | What may the Account do inside the product? | Product Tenant RAP roles and permissions |
| Authentication | Has the Account proved its identity? | DreamConsistency.AccessControl.Api |
| Session Scope | For which TenantApplication is this session valid? | Realm Account session |
A customer Account is global only within the Realm database that owns it. The same physical person may therefore have independent Account identities in different Realms.
AUT_USR_Accounts represents the authentication identity of one customer user
within a Realm. The Account is not a Tenant user record and is not itself an Identity Provider.
| Property | Meaning |
|---|---|
AUT_USR_AccountID |
Stable Realm-local customer identity key. |
PrimaryEmailAddress |
Mutable login/contact identifier; not the identity key. |
NormalizedPrimaryEmailAddress |
Target Realm-wide unique email lookup value. |
PasswordHash |
Realm Account credential state. |
IsDisabled |
Global Account lifecycle state. |
IsRemoved |
Global Account lifecycle state. |
TEN_Tenant_RefID |
Legacy compatibility field; not the target multi-tenant authorization source. |
IsOwnerAccount |
Legacy compatibility field; tenant-specific ownership belongs to membership. |
AUT_USR_AccountID remains the identity when the email changes.
The target Realm contract introduces a normalized email value used for deterministic Account lookup and Realm-wide uniqueness.
Provider-specific transformations are deliberately excluded. Dream Consistency does not remove Gmail dots, strip plus aliases, or otherwise assume that different email addresses represent the same person.
NormalizedPrimaryEmailAddress must be unique within one Realm.
AUT_USR_AccountTenantMemberships represents the relationship between a
Realm Account and a Tenant. It is the target authority for Tenant membership state and
Tenant-specific ownership.
| Field | Meaning |
|---|---|
AUT_USR_Account_RefID |
Realm Account participating in the Tenant. |
TEN_Tenant_RefID |
Realm Tenant membership scope. |
MembershipStatus_RefID |
Realm-local reference to the canonical membership lifecycle status. |
IsOwnerAccount |
Whether this Account is an owner of this specific Tenant. |
MembershipStatusReason |
Reason describing the current membership state. |
ActivationTimestamp |
Most recent transition into ACTIVE. |
SuspensionTimestamp |
Most recent transition into SUSPENDED. |
RemovalTimestamp |
Most recent transition into REMOVED. |
| Status | Meaning |
|---|---|
PENDING_ACTIVATION |
Membership exists but access has not yet been activated. |
ACTIVE |
Membership permits Tenant participation, subject to application and product authorization. |
SUSPENDED |
Tenant-specific access is temporarily disabled. |
REMOVED |
Tenant membership has been removed but the historical relationship remains represented. |
Membership rows are not physically recreated merely because a user is re-invited. The unique Account/Tenant relationship remains stable and lifecycle transitions are explicit.
Tenant membership is deliberately Tenant-level rather than TenantApplication-level. A TenantApplication represents the enrollment and operational state of a Dream Consistency product for a Tenant.
DreamConsistency.AccessControl.Api is the Realm-scoped authentication authority.
It validates customer credentials, manages customer authentication sessions, performs
invitation credential-establishment and acceptance flows, and issues sessions scoped to a
concrete TenantApplication.
A modern customer session represents one authenticated Account operating within one TenantApplication scope.
A client does not change Tenant authority by sending a different Tenant UUID with an already-issued token. Tenant scope is derived from the session's TenantApplication reference.
The target provisioning flow resolves a Realm Account by normalized email before establishing the new Tenant membership.
The preallocated owner AccountId remains useful when a new Account must be created. When an existing Realm Account is reused, later provisioning steps must use the resolved existing AccountId rather than the unused preallocated value.
An invitation activates an already-existing Tenant membership. AccessControl does not create Tenant memberships as part of invitation redemption.
Modern customer invitations are scoped through TenantApplication_RefID.
AccessControl derives the Tenant from that TenantApplication and resolves exactly one expected
Account-to-Tenant membership.
Authentication proves the Realm Account first. Tenant selection is performed only after credentials are valid.
A user may therefore use one Realm Account and one credential set while participating in several independent customer Tenants.
AUT_USR_AccountTenantMemberships.IsOwnerAccount.
It is not a global property of the Realm Account.
One Realm Account may therefore own one Tenant, administer another, and have no access to a third. Product-specific administrator roles remain separate from Realm Tenant ownership.
Realm schema 1.6.0 retains legacy Tenant-bound fields on AUT_USR_Accounts
while the platform moves toward first-class multi-tenant Accounts.
| Legacy Field | Transitional Meaning | Target Authority |
|---|---|---|
AUT_USR_Accounts.TEN_Tenant_RefID |
Original / compatibility Tenant reference. | AUT_USR_AccountTenantMemberships.TEN_Tenant_RefID |
AUT_USR_Accounts.IsOwnerAccount |
Legacy Account-level ownership flag. | AUT_USR_AccountTenantMemberships.IsOwnerAccount |
TEN_Tenant_RefID to the new Tenant.
| Data | Owner |
|---|---|
| Realm customer Account | Realm DB |
| Credentials and email verification | Realm DB / AccessControl |
| Account-to-Tenant membership | Realm DB |
| Tenant ownership | Realm membership |
| TenantApplication lifecycle | Realm DB |
| Authentication session | Realm DB / AccessControl |
| Provisioning execution and resolved workflow state | Management DB |
| Product user participation and RAP authorization | Product Tenant DB |
| Invariant | Rule |
|---|---|
| Stable identity | AUT_USR_AccountID is the customer identity; email is never the cross-database identity key. |
| Realm isolation | Accounts do not span Realm boundaries. |
| Membership authority | Tenant-specific access state is derived from AccountTenantMembership. |
| Ownership authority | Tenant-specific ownership is derived from membership, not the Account. |
| Invitation scope | Invitation activation resolves one Account and one Tenant through TenantApplication. |
| Credential protection | An existing Account invitation never replaces an established password. |
| Session scope | One customer session is scoped to one concrete TenantApplication. |
| Client trust boundary | Tenant authority is never taken from an arbitrary client-supplied Tenant UUID on session validation. |
| Product authorization | Realm membership does not replace product Tenant roles and permissions. |
| Decision | Status |
|---|---|
| A customer Account is global within one Realm. | Locked |
| A customer Account does not span Realm boundaries. | Locked |
AUT_USR_AccountID is the stable customer identity. |
Locked |
| Email is a mutable login/contact identifier, not the identity key. | Locked |
| A single Account may participate in multiple Tenants within the same Realm. | Locked |
Tenant membership belongs to AUT_USR_AccountTenantMemberships. |
Locked |
| Tenant-specific ownership belongs to the membership. | Locked |
| Membership is Tenant-level, not TenantApplication-level. | Locked |
| AccessControl is the Realm-scoped authentication authority. | Locked |
| Modern sessions are scoped to a concrete TenantApplication. | Locked |
| Invitation acceptance activates an existing membership; it does not create one. | Locked |
| An invitation for an existing Account never resets its password. | Locked |
| Product RAP remains the authority for product-specific roles and permissions. | Locked |
The current architecture deliberately stops at the Realm boundary. A future platform-global identity directory, OIDC provider, external identity federation, social login, or cross-Realm account linking may be introduced only as separate architectural capabilities.
| Date | Change | Author |
|---|---|---|
| 2026-09-09 | Established the Realm-scoped customer Account model, first-class Account-to-Tenant memberships, Tenant-specific ownership, invitation activation boundaries, and the target multi-workspace authentication architecture. | Branko |