Skip to content

CAP-PFM-SEC-010Assign roles within a controlled scope

Markdown

CAP-PFM-SEC-010

Assign roles within a controlled scope

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

KindCapabilityProduct areaPlatformModuleSecurity, Customers and WorkspacesRevision1

Read atservices-platform ad3f6a65react-console baf6dae3

The Formal Contract

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

Outcomes
Role assignments identify where access applies.Delegation refuses authority beyond the administrator’s effective permissions.Assignment history and access explanation support review.
Surfaces
consoleapi
Intent sources
services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-11 Final acceptance)services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-13/14 Final acceptance)services-platform:docs/security/security-administration.md#4. Delegation, escalation and lockoutservices-platform:docs/security/security-administration.md#12. Approved omissions and tracked gaps (resource-scoped grants, PLAT-M5 D10)

Controls

31 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-IAM-001 TC-IAM-002 TC-IAM-003 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-003 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.security-access.manageapitenant
platform.security-access.explainapitenant
platform.users.readapitenant

Business Rules

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

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Assignment creation, withdrawal and scope changes require access-management permission covering the target scope; read-only authority cannot write grants.
origin: services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-11 Final acceptance)
permissionapi, servicetest
services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the reader’s attempt to grant as 403, and grants nothing
02must prove
Confirmed
Delegation requires the administrator to hold every affected permission unconditionally and without a deny at the target scopes; failures identify the missing keys and scopes without disclosing others’ grants, and self-widening fails.
origin: services-platform:docs/security/security-administration.md#4. Delegation, escalation and lockout
permissionservicetest
services-platform:modules/security/tests/unit/services/invitations/widening.spec.ts#refuses a scope the caller does not manage, and says which scope rather than which role
03must prove
Confirmed
Customer assignments can cover the whole customer, one of its workspaces or an existing unarchived custom record type in a workspace; unsupported single-record kinds fail.
origin: services-platform:docs/security/security-administration.md#12. Approved omissions and tracked gaps (resource-scoped grants, PLAT-M5 D10)
validationapi, servicetest
services-platform:modules/security/tests/integration/services/membership/resource-scopes.integration.spec.js#refuses an archived custom object, naming the object key, and writes nothing
04must prove
Confirmed
Customer security operations cannot create or amend platform-scope staff authority, including its duration, conditions or scope, and refusals direct staff to HQ.
permissionservicetest
services-platform:modules/security/tests/integration/services/membership/amend-grant.integration.spec.js#refuses a window that would have ended the staff grant, naming where such a change is made
05must prove
Confirmed
Assignments for active memberships are active, assignments for invited memberships remain pending until acceptance, and future validity windows contribute no access until they open.
origin: services-platform:docs/security/security-administration.md#2. Capability checklist (U8, DEF-CRM-0551)
lifecycleservicetest
services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#answers a grant whose window opens tomorrow as scheduled, in the grant and in the list
06must prove
Confirmed
A person can hold only one non-revoked role assignment for the same scope and validity window; sequential or concurrent duplicates fail, and revocation allows a replacement grant.
origin: services-platform:docs/security/security-administration.md#2. Capability checklist (U8, DEF-CRM-0552)
invariantservice, databasetest
07must prove
Confirmed
Withdrawal preserves assignment history, guards against losing the last administrator and requests an authorizer flush after commit without guaranteeing eviction of cached decisions.
origin: services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-11 Final acceptance)
lifecycleservicetest
08must prove
Confirmed
Setting role scope atomically reconciles customer-wide or 1–100 selected-workspace assignments, retains matching rows, creates missing rows under delegation checks and revokes unwanted rows; outside-customer workspaces fail and resource assignments remain unchanged.
origin: services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-13/14 Final acceptance)
calculationservicetest
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
09must prove
Confirmed
Weakening an assignment’s deny by narrowing scope, shortening validity or adding a condition requires widening authority; extending validity or removing that restriction can strengthen the deny instead.
permissionservicetest
services-platform:modules/security/tests/integration/services/membership/amend-grant.integration.spec.js#refuses a narrowing of the scope for an editor who is not allowed the key the grant was denying
10
Confirmed
Grant checking reports the role and whether the caller can assign it at a proposed scope without making a write, including checks within a workspace administrator’s scope.
policyapi, servicetest
services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#writes no assignment and no audit event, however many checks were asked
11must prove
Confirmed
Access explanation evaluates a member’s permissions and traces allowed keys to assignments, roles and policies; denies remove keys and absent grants produce an empty explanation.
origin: services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-11 Final acceptance)
calculationservicetest
services-platform:modules/security/tests/integration/services/membership/effective-permissions.integration.spec.js#leaves out a key the role's own deny takes back, although its policy still names it
12must prove
Confirmed
Staff-only roles and roles outside the customer cannot be assigned to customer memberships and are presented as not found.
permissionservicetest
services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#refuses a staff-only role for a customer's user as not found, by its key or its id, and grants nothing
13must prove
Confirmed
Assignment creation, withdrawal and scope changes produce both assignment and membership history entries.
origin: services-platform:docs/security/security-administration.md#2. Capability checklist (U8, DEF-CRM-0553)
invariantservicetest
services-platform:modules/security/tests/integration/services/membership/grant-history.integration.spec.js#lists the grant, the move and the withdrawal, each naming the grant it was about
14
Confirmed
Role-member pagination includes only reached people holding the role and presents each assignment’s scope.
origin: services-platform:docs/security/security-administration.md#14 Acceptance checkpoints (2026-10-11 Final acceptance)
policyapi, servicetest
services-platform:modules/security/tests/e2e/definitions.e2e.spec.js#lists the people who hold a role, which is whoever the caller reaches and not every customer's

Scenarios

IdGivenWhenThenProvenance
01A colleague needs access to two of the customer’s five workspaces.The administrator changes the Standard User assignment to selected workspaces.The role applies to those two workspaces and the membership history records the change.test
react-console:e2e/mock/security-admin.mock.spec.ts#Edit on a role restores its saved tenants and saves All, Selected and All again
02An investigator needs access to a particular custom record type.An authorized administrator grants the investigator role at that record-type scope.The scoped assignment can be inspected and withdrawn, while a duplicate assignment is refused.test
react-console:e2e/mock/security-scoped-roles.mock.spec.ts#grant Investigators on Enforcement Actions, see it listed with its scope, and remove it

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.