--- id: FAS-PFM-SEC-04 title: Access Definitions and Authorization acceptance feature: FEAT-PFM-SEC-04 product_area: platform module: security revision: 1 status: proposed product_intent: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-PFM-SEC-012 - CAP-PFM-SEC-013 - CAP-PFM-SEC-014 - CAP-PFM-SEC-015 scenarios: - id: FAS-PFM-SEC-04-01 title: A custom role remains usable through its full administrative life kind: behaviour exercises: - CAP-PFM-SEC-012 relies_on: - ATS-PFM-SEC-012-13 preconditions: A customer administrator can compose an unreferenced custom role. steps: - do: >- Create the role, search for it, edit it, reload it, and archive it after removing its holders. expect: >- The saved definition persists and its archived identity leaves the active list. provenance: proposed source: &ref_0 - >- react-console:e2e/security/roles.spec.ts#is created from a name and a permission - >- react-console:e2e/security/roles.spec.ts#is on the Roles list, searchable, and marked custom - >- react-console:e2e/security/roles.spec.ts#is edited, and the change survives a reload - >- react-console:e2e/security/roles.spec.ts#is given to a person, who then shows on its Members tab - >- react-console:e2e/security/roles.spec.ts#is archived once nobody holds it, and leaves the active list - >- react-console:e2e/security/roles.spec.ts#refuses to archive a role somebody still holds, and names them - >- react-console:e2e/security/roles.spec.ts#shows a built-in role read-only, and duplicates it into one that can be changed expected: >- The saved definition persists and its archived identity leaves the active list. negative: false data_needs: >- A disposable customer and workspace with run-owned memberships, assignments and definitions; clock-controlled expiry fixtures where needed. bound_to: [] provenance: proposed source: *ref_0 executable_candidate: TST-PFM-SEC-034 binding_gap: FND-PFM-SEC-078 - id: FAS-PFM-SEC-04-02 title: Role composition changes effective request authority kind: interaction exercises: - CAP-PFM-SEC-012 - CAP-PFM-SEC-013 - CAP-PFM-SEC-015 relies_on: - ATS-PFM-SEC-012-05 - ATS-PFM-SEC-013-05 - ATS-PFM-SEC-015-06 preconditions: A role references a policy and an active member holds it. steps: - do: >- Change an owned policy permission, read impact, and issue fresh allowed and denied operations after cached authority expires. expect: >- The new materialized permissions constrain requests while shared definitions retain their ownership. provenance: proposed source: &ref_1 - >- services-platform:modules/security/tests/integration/services/definitions/manage-roles.integration.spec.js#refuses a reference to another customer's policy, and writes no role at all - >- services-platform:modules/security/tests/integration/services/catalog/reconcile-catalog.integration.spec.js#grants a newly shipped built-in to nobody: no role references it - >- services-platform:modules/security/tests/unit/authorizer/authorize.spec.ts#lists only the tenants a grant could reach, not every tenant of the customer expected: >- The new materialized permissions constrain requests while shared definitions retain their ownership. negative: false data_needs: >- A disposable customer and workspace with run-owned memberships, assignments and definitions; clock-controlled expiry fixtures where needed. bound_to: [] provenance: proposed source: *ref_1 - id: FAS-PFM-SEC-04-03 title: A withdrawn built-in returns with the same identity kind: lifecycle exercises: - CAP-PFM-SEC-012 - CAP-PFM-SEC-013 - CAP-PFM-SEC-015 relies_on: - ATS-PFM-SEC-012-02 - ATS-PFM-SEC-013-06 - ATS-PFM-SEC-015-05 preconditions: A published built-in has holders and a separate customer copy. steps: - do: >- Withdraw the built-in in one release and republish it in the next, inspecting holders, copy and fresh authority. expect: >- The built-in identity returns, the customer copy stays separate, and fresh requests follow the currently published content. provenance: proposed source: &ref_2 - >- services-platform:modules/security/tests/e2e/definitions.e2e.spec.js#refuses a write against a built-in as read-only rather than as a record that is not there - >- services-platform:modules/security/tests/integration/services/catalog/reconcile-catalog.integration.spec.js#renames a key through formerKeys, keeping the row and every reference to it - >- services-platform:modules/security/tests/unit/authorizer/registry-manifest.spec.ts#refuses a staffOnly key below a system route expected: >- The built-in identity returns, the customer copy stays separate, and fresh requests follow the currently published content. negative: false data_needs: >- A disposable customer and workspace with run-owned memberships, assignments and definitions; clock-controlled expiry fixtures where needed. bound_to: [] provenance: proposed source: *ref_2 - id: FAS-PFM-SEC-04-04 title: Customer edits cannot alter staff or source-owned authority kind: permission exercises: - CAP-PFM-SEC-012 - CAP-PFM-SEC-014 - CAP-PFM-SEC-015 relies_on: - ATS-PFM-SEC-012-12 - ATS-PFM-SEC-014-04 - ATS-PFM-SEC-015-04 preconditions: >- A customer administrator can edit customer roles and has a derived assignment in view. steps: - do: >- Attempt staff-role composition, direct derived withdrawal and HQ access. expect: Each operation is refused within its distinct authority boundary. provenance: proposed source: &ref_3 - >- services-platform:modules/security/tests/e2e/definitions.e2e.spec.js#lists every role but the staff-only ones, the built-ins a customer assigns among them - >- services-platform:modules/security/tests/integration/services/persistence/assignments.derived.integration.spec.js#refuses an amendment 409 derived_assignment, naming where to change it - >- services-platform:modules/security/tests/e2e/staff-separation.e2e.spec.js#refuses the widest grant Rhythm holds, every one of them expected: Each operation is refused within its distinct authority boundary. negative: true data_needs: >- A disposable customer and workspace with run-owned memberships, assignments and definitions; clock-controlled expiry fixtures where needed. bound_to: [] provenance: proposed source: *ref_3 - id: FAS-PFM-SEC-04-05 title: Expired derived access cannot survive in an earlier context kind: regression exercises: - CAP-PFM-SEC-014 - CAP-PFM-SEC-015 relies_on: - ATS-PFM-SEC-014-05 - ATS-PFM-SEC-015-07 preconditions: >- A portal contact has a derived assignment whose end precedes the retained context expiry. steps: - do: >- Capture authorization before the assignment ends, advance past its end, and evaluate the operation with that context. expect: >- The stored validity boundary stops derived authority even while the context remains otherwise valid. provenance: proposed source: &ref_4 - >- services-platform:modules/security/tests/e2e/derived-assignments.e2e.spec.js#refuses the same still-unexpired context once valid_until has passed, because validity is read per request - >- services-platform:modules/security/tests/unit/authorizer/authorize.spec.ts#the context expires at iat + the gateway TTL + 30 s and carries no IP address expected: >- The stored validity boundary stops derived authority even while the context remains otherwise valid. negative: true data_needs: >- A disposable customer and workspace with run-owned memberships, assignments and definitions; clock-controlled expiry fixtures where needed. bound_to: [] provenance: proposed source: *ref_4 evidence: - >- specs/platform/security/planning/capabilities/CAP-PFM-SEC-012-define-a-customer-s-own-roles-and-policies.md - >- specs/platform/security/planning/capabilities/CAP-PFM-SEC-013-ship-rhythm-s-built-in-roles-and-policies-with-each-release.md - >- specs/platform/security/planning/capabilities/CAP-PFM-SEC-014-grant-roles-automatically-from-appointments-and-eligibility.md - >- specs/platform/security/planning/capabilities/CAP-PFM-SEC-015-decide-every-request-against-the-caller-s-grants.md - >- Capability test scenario references identify the outcomes this suite relies on. The complete feature chains remain proposed until a suite executes every step. --- # Access Definitions and Authorization: Feature Acceptance Suite ## What the Feature Must Do as a Whole The suite connects owned definitions, release-managed built-ins, derived assignments and enforced requests. It establishes a regression baseline for how changes in permission sources reach the final authorization decision. ## Interactions Between Capabilities A definition change can alter every holder’s fresh request result. A derived assignment can expire independently of the signed context that previously carried it. The interaction rows identify the participating capabilities and the detailed proofs they assume. A complete feature chain needs its own executable evidence even when its individual outcomes already have bindings. ## Regression Record | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | all | Establish cumulative feature coverage and the first regression baseline. |