--- id: CON-PFM-SEC-003 name: User Account feature: FEAT-PFM-SEC-02 product_area: platform module: security revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A user account records a person’s membership and sign-in identities within a customer or workspace boundary. Its access is expressed through role definitions, assignments and any staff-entry record. owned_by: MOD-PFM-SEC synonyms: - user - console user - portal member - staff member - membership not_to_be_confused_with: - CRM contact - Shared team login - Service principal facets: - name: Wall meaning: >- The membership belongs to one customer’s console, one workspace’s portal or Rhythm’s staff customer. used_for: Separating accounts that belong to different customers or workspaces. - name: Account status meaning: 'Invited, active, suspended and revoked describe membership standing.' used_for: Controlling whether membership can provide usable access. - name: Invitation meaning: A recipient-bound link lasts seven days and records delivery; a resend replaces outstanding links. used_for: Bringing invited people into console and staff membership. - name: Sign-in identities meaning: The registered pool identity supports password sign-in and an eligible Google link. used_for: Proving the caller behind a membership. - name: Profile meaning: >- Names, time zone and locale support presentation while routine editing preserves the sign-in address. used_for: Displaying people and dates consistently. - name: Linked contact meaning: A portal account can be linked to the CRM person identified by matching or verification. used_for: Connecting portal work to contact-based responsibilities. - name: Former user meaning: A retained name explains the actor after an account is deleted. used_for: Preserving readable attribution for earlier work. - name: Founding staff meaning: An environment’s founding list establishes designated active staff without ordinary invitations. used_for: Providing initial administration in an environment. - name: Service principal meaning: A registered service name identifies a non-human caller and can be suspended. used_for: Attributing and controlling service-originated activity. - name: Permission meaning: 'An application action carries tier, sensitivity and any staff-only classification.' used_for: Expressing allowed or denied work using a common vocabulary. - name: Permission catalog meaning: Released services supply the set of available permission definitions. used_for: Keeping rule choices aligned with exposed operations. - name: Policy meaning: 'A reusable named rule group combines allows, denies and supported conditions.' used_for: Sharing access definitions between job roles. - name: Built-in policy meaning: >- Release-controlled policies include generated application tiers and declared sensitive-power groups. used_for: Providing shared read-only starting definitions. - name: Custom policy and role meaning: Customer-owned definitions can be authored locally or copied with their original version recorded. used_for: Representing the customer’s own job requirements. - name: Built-in role meaning: Five customer roles and three staff roles group Rhythm’s shared policies. used_for: Supplying standard assignments for common audiences. - name: Grants-nothing label meaning: The indication identifies a role with no effective allow of its own or through active policies. used_for: Recognizing incomplete or emptied definitions. - name: Eligibility binding meaning: A custom role may identify a workspace eligibility rule and re-check interval. used_for: Deriving assignments from qualifying contact facts. - name: Scope meaning: 'The assignment names a customer, workspace, supported custom record or staff-platform scope.' used_for: Locating the authority represented by the role. - name: Grant state meaning: 'Pending, scheduled, live, ended and withdrawn distinguish current authority from retained history.' used_for: Explaining whether an assignment counts now. - name: Window and conditions meaning: Optional validity dates and supported conditions limit when access applies. used_for: Bounding authority by time and circumstances. - name: Automatic grant meaning: A source-managed assignment names a contact and its derivation. used_for: Keeping access aligned with appointments or eligibility. - name: Widening rule meaning: Delegation checks require authority for the access handed out and refuse self-widening. used_for: Preventing privilege escalation through administration. - name: Last administrator guard meaning: Guard checks preserve an active customer security administrator and a Rhythm Administrator. used_for: Retaining the ability to administer security. - name: Security context meaning: The evaluated document describes usable access for the current workspace. used_for: Initializing the console and explaining permissions. - name: Security history meaning: The audit trail describes security changes and recorded refusals. used_for: Supporting access reviews and investigations. - name: Approved access meaning: Customer approval converts a staff request into time-limited access of one to thirty days. used_for: Supporting routine customer work with recorded consent. - name: Given access meaning: A customer administrator initiates access for a named staff member without a preceding request. used_for: Giving staff entry proactively for agreed work. - name: Emergency access meaning: A Rhythm Administrator opens up to four hours of incident access with a reason and ticket. used_for: Responding when an incident requires entry before approval. - name: Standing access meaning: Rhythm Administrators and founding super users receive ongoing customer-wide Administrator access. used_for: Entering customer work under recorded standing authority. - name: Request meaning: A pending access record awaits a decision and provides no usable assignment. used_for: Recording the request before consent is decided. - name: Emergency report meaning: The report groups emergency access opened during the selected month. used_for: Inspecting incident entry across that reporting period. - name: Staff roles meaning: The three staff roles hold their HQ authority at platform scope. used_for: 'Separating support, engineering and staff-administration powers.' relationships: - to: CON-PFM-SEC-001 statement: Console membership is owned by a single customer. provenance: documented source: 'services-platform:docs/security/security-administration.md#1. What the area is for' - to: CON-PFM-SEC-002 statement: Portal membership is owned by a single workspace. provenance: test source: >- services-platform:modules/security/tests/integration/services/provisioning/post-confirmation.integration.spec.js#creates the member, active and verified, in the pool’s tenant under the account’s own id - to: CON-PFM-SEC-001 statement: Customer-owned definitions remain local while built-in definitions are shared. provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses another customer's policy, the one way authority could cross a wall through a definition - to: CON-PFM-SEC-002 statement: Workspace-scoped assignments apply within a workspace belonging to the customer. provenance: test source: >- services-platform:modules/security/tests/integration/services/membership/set-role-scope.integration.spec.js#turns the customer grant into one active grant per tenant asked for, revoking the customer grant - to: CON-PFM-SEC-002 statement: 'The access record identifies either a workspace or, for standing access, a customer.' provenance: documented source: 'services-platform:docs/hq/rhythm-hq-plan.md#D2. Staff access to customer tenants' - to: CON-PFM-SEC-001 statement: Each access record names the staff account acting in the customer’s workspace. provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js#gives every Rhythm Administrator its grant, the integration database’s own among them lifecycle: - state: invited meaning: Membership awaits acceptance and its offered grants do not yet authorize work. how_it_changes: Acceptance activates membership; withdrawal revokes it. - state: active meaning: Membership is eligible to use the authority its grants provide. how_it_changes: 'Acceptance, eligible direct activation or reinstatement establishes active membership.' - state: suspended meaning: 'Membership is deactivated and sign-in disabled, with cached authorization subject to its expiry.' how_it_changes: An administrator deactivates membership and can later reinstate it. - state: revoked meaning: Membership and its invitations and grants have ended. how_it_changes: Removal revokes membership; return requires a fresh invitation. acted_on_by: - CAP-PFM-SEC-005 - CAP-PFM-SEC-006 - CAP-PFM-SEC-007 - CAP-PFM-SEC-008 - CAP-PFM-SEC-009 - CAP-PFM-SEC-010 - CAP-PFM-SEC-011 - CAP-PFM-SEC-012 - CAP-PFM-SEC-013 - CAP-PFM-SEC-014 - CAP-PFM-SEC-015 - CAP-PFM-SEC-016 - CAP-PFM-SEC-017 - CAP-PFM-SEC-018 - CAP-PFM-SEC-019 - CAP-PFM-SEC-020 visible_to: - ACT-PFM-001 - ACT-PFM-002 - ACT-PFM-003 - ACT-PFM-004 - ACT-PFM-005 evidence: - >- Pinned services-platform references for the structured rows: docs/hq/rhythm-hq-plan.md; docs/security/security-administration.md; modules/security/tests/integration/db/security-definition-integrity.integration.spec.js; modules/security/tests/integration/services/membership/set-role-scope.integration.spec.js; modules/security/tests/integration/services/provisioning/post-confirmation.integration.spec.js; modules/security/tests/integration/services/staff-access/rhythm-administrator-standing-access.integration.spec.js. supersedes: - CON-PFM-SEC-004 - CON-PFM-SEC-005 - CON-PFM-SEC-006 --- # User Account ## What It Is A user account represents a person’s membership within a particular part of Rhythm. Console membership belongs to a customer, portal membership belongs to a workspace, and Rhythm staff use membership under Rhythm’s own customer. The account connects sign-in identities, profile information, membership standing and the access assigned to that person. Access definitions and assignments are facets of this concept. A role names a reusable collection of policies and permission rules; a grant connects that definition to a subject, scope and validity period. Staff customer entry has an additional record explaining consent, standing authority or emergency use. Those records explain an account’s authority without creating separate broad product concepts. The account can exist before usable sign-in or access. An invitation establishes a pending membership and offers assignments for acceptance. Portal registration follows its own confirmation path. An ended membership can still need readable attribution in earlier activity, so historical identity and present access have different responsibilities. ## What It Is Not An account differs from the CRM contact describing a person known to an association. A contact can exist without sign-in, while a portal account can link to that contact. Membership also differs from authority: owning an account or defining a role does not by itself establish usable permissions. Registered service principals identify machine callers separately from human membership. ## How It Is Used Customer administrators invite colleagues, maintain profiles and review assignments. They work with role and policy definitions when standard access does not fit a local job. Membership controls support temporary interruption, return and permanent removal. History and access explanations help them understand both recorded changes and currently evaluated authority. People accept invitations, authenticate and recover their sign-in. The console reads evaluated access to organize their work. Portal members can connect their membership to CRM records. Staff administer their own memberships through HQ and use customer-entry records when their work requires a customer workspace. These activities remain subject to the rules in their respective capabilities. ## Its Facets **Boundary and status.** The membership’s wall identifies its customer or workspace. Account status distinguishes invited, active, suspended and revoked membership. Invitation delivery and sign-in identities explain entry; profile fields support names, dates and presentation. Former-user records retain names after deletion, and founding staff support initial administration. **Contact and machine identity.** A linked contact connects portal work to association records. A service principal supplies a separate machine identity for attribution and status control. **Access definitions.** Permissions and their released catalog provide the vocabulary for application actions. Policies group allow, deny and condition rules. Built-in policies and roles supply shared definitions; custom policies and roles represent customer jobs. The grants-nothing indication describes empty effective access, while an eligibility binding connects a custom role to source-managed qualification. **Assignments.** Scope, grant state, time windows and conditions describe where and when a role counts. Automatic grants retain their derivation. Widening and last-administrator safeguards govern delegation. The security context describes evaluated access, and security history supports review of changes and recorded refusals. **Staff entry.** Approved access follows a customer decision; given access begins with the customer’s initiative. Emergency access and standing access have distinct bases. A request records an undecided proposal, the emergency report supports review, and staff roles describe HQ authority separately from customer entry. ## How It Relates Customers own console memberships and customer access definitions. Workspaces own portal memberships and locate workspace-scoped assignments. A CRM contact supplies the person behind linked portal work and contact-based derivations. Staff-entry records retain the staff account as actor while applying a customer-appropriate role assignment. Released applications define the permissions used in those roles. ## What It Could Become The product should resolve the subject model for automatic grants and complete the associated editor experience. Deferred authentication extensions, staff multi-factor requirements and service-principal screens need explicit decisions. Access reviews should clearly distinguish manual, derived, approved, emergency and standing authority, and explain the accepted cache limit when authority changes.