Rhythm 2.0 Specifications

Appearance

CAP-PFM-SEC-019Register and authenticate portal members

Markdown

CAP-PFM-SEC-019

Register and authenticate portal members

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

Planning

Feature
FEAT-PFM-SEC-06
Key concepts
CON-PFM-SEC-003, CON-PFM-SEC-002
Actors
ACT-PFM-003, ACT-PFM-004, ACT-PFM-006
Related
CAP-PFM-SEC-020, CAP-PFM-SEC-014, CAP-PFM-SEC-002
Proved by
ATS-PFM-SEC-019
Executed by
TST-PFM-SEC-046, TST-PFM-SEC-060, TST-PFM-SEC-069, TST-PFM-SEC-132, TST-PFM-SEC-178, TST-PFM-SEC-218

KindCapabilityProduct areaPlatformModuleSecurity, Customers and WorkspacesRevision1

Read atservices-platform ad3f6a65

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Portal membership belongs to a workspace-specific sign-in boundary.Identity operations limit address information according to the observed refusal rules.Portal-pool reconciliation supports provisioning and retry on demand.
Surfaces
portalapijob
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#4.3 Participants at launch (security.portal-pool, Andrew 2026-10-16)services-platform:docs/security/security-administration.md#2. Capability checklist (X8: portal work deferred, Andrew 2026-10-09)

Controls

41 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-IAM-001 TC-IAM-002 TC-IAM-003 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-SEC-001 TC-SEC-002 TC-SEC-003 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.security-self.readapirecord
platform.tenants.onboardapiglobal

Business Rules

11 rules, 8 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Portal-pool provisioning begins when Websites is enabled or a site is created, rather than during workspace creation. Provisioning admits one concurrent build, permits retry after failure and reuses an existing active pool.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#4.3 Participants at launch (security.portal-pool, Andrew 2026-10-16)
no proof recorded yet
lifecycleservice, jobtest
services-platform:modules/security/tests/integration/services/onboarding/ensure-tenant-portal.integration.spec.js#answers a second call with the onboarding already under way rather than a second job
02
Proposed
A staff-only onboarding operation can initiate portal-pool provisioning directly because it allocates Rhythm cloud resources.
permissionapiobserved
services-platform:aws/platform.service.ts#TENANTS_PERMISSIONS.Onboard
03must prove
Proposed
The discovery handler gives the same refusal for an unknown workspace and one lacking an active portal pool. Workspace availability is checked earlier and can produce a different response.
no proof recorded yet
policyapitest
services-platform:modules/security/tests/e2e/access.e2e.spec.js#refuses an unknown tenant and a tenant with no portal pool with the same sentence, saying nothing about either
04must prove
Proposed
Signup creates an unconfirmed pool account and sends a verification code. An address already held by a workspace member is rejected, as is a password that violates pool policy.
no proof recorded yet
validationservicetest
services-platform:modules/security/tests/unit/services/portal/portal-identity.spec.ts#refuses an address a member of the tenant already holds as 409 email_address_taken, asking Cognito nothing
05must prove
Proposed
Portal signup confirmation creates one active, verified workspace member and one Portal Member assignment. Repeated confirmation is idempotent; console-pool and password-recovery confirmations do not create memberships.
no proof recorded yet
lifecycleservicetest
services-platform:modules/security/tests/integration/services/provisioning/post-confirmation.integration.spec.js#grants the Portal Member role, active, at the tenant’s scope
06must prove
Proposed
Portal password sign-in gives unknown addresses and wrong passwords the same refusal. It reports an unverified address only after a correct password. Disabled, suspended or wrong-workspace members are rejected; revoked members have newly issued tokens revoked.
no proof recorded yet
policyservicetest
services-platform:modules/security/tests/unit/services/portal/portal-identity.spec.ts#refuses a wrong password exactly as it refuses an address nobody holds
07must prove
Proposed
Recovery initiation and verification-code resend return equivalent responses for known and unknown addresses. Recovery confirmation treats an unknown address like an incorrect code.
no proof recorded yet
policyservicetest
services-platform:modules/security/tests/unit/services/portal/portal-identity.spec.ts#answers an address nobody holds exactly as it answers a member, having asked Cognito for both
08must prove
Proposed
Sign-out uses the caller’s own access token to revoke their pool sessions. A token identifying someone else causes no revocation.
no proof recorded yet
policyservicetest
services-platform:modules/security/tests/unit/services/portal/portal-identity.spec.ts#refuses an access token issued to somebody other than the caller, ending no session
09must prove
Proposed
Authorized workspace administrators can invite and list portal members. Portal users remain confined to their workspace and may read only their own membership record.
no proof recorded yet
permissionapi, servicetest
services-platform:modules/security/tests/e2e/users.e2e.spec.js#reads a user in scope, answers 404 for another customer's user (row-level security hides it) and an unknown one, and a portal user reads only itself
10
Proposed
Identity handlers treat unavailable portal pools alike. The preceding workspace gate may reject the request before identity handling.
policyservicetest
services-platform:modules/security/tests/unit/services/portal/portal-identity.spec.ts#refuses a tenant whose portal pool is suspended exactly as an unknown tenant
11
Proposed
The portal contract’s distinct success statuses remain a proposed correction; successful handlers currently use the ordinary success response.
validationapidocumented
services-platform:docs/debt/portal-sign-in-contract-gaps.md

Scenarios

IdGivenWhenThenProvenance
01A customer enables Websites for a workspace.A member registers, confirms the email code and signs in.Confirmation creates the active portal membership and Portal Member assignment, and successful authentication returns tokens.test
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

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software