Open Mercato Roles, Permissions, and Access Governance

Eighteen access-governance terms

Name its principal, scope, decision owner, evidence and excluded meanings before relying on it.

• 1. identity
• 2. authentication
• 3. authorization
• 4. role
• 5. feature
• 6. wildcard grant
• 7. Role ACL
• 8. User ACL override
• 9. effective access
• 10. tenant scope
• 11. organization scope
• 12. delegation boundary
• 13. superadmin or break-glass access
• 14. machine identity
• 15. joiner, mover, leaver lifecycle
• 16. segregation of duties
• 17. access review
• 18. acceptance evidence

Effective-access reasoning map

Use this model to trace the stages. It does not show that every current route executes every stage uniformly.

Record the current mechanism, possible gap, acceptance evidence, accountable owner and native, configurable, custom, integration or deployment state.

1. 1

   principal

2. 2

   authenticated context

3. 3

   tenant

4. 4

   organization

5. 5

   global superadmin check

6. 6

   User ACL if present, otherwise assigned roles

7. 7

   role ACL aggregation

8. 8

   enabled-module filter

9. 9

   wildcard match

10. 10

    all required route features

11. 11

    route and domain scope guard

12. 12

    data query

13. 13

    allow or deny

Role aggregation and user-override precedence

Without a User ACL, current source unions unique role features, ORs superadmin, and combines organization reach. One unrestricted role can make the aggregate unrestricted. When a User ACL exists, current loadAcl exclusively uses its features, organizations and superadmin flag. Role grants are omitted. Current documentation contains additive wording, so this source-first conflict is dated and must be rechecked on upgrade.

The current user ACL route removes the row when no effective feature and no superadmin remain, so an organization-only override is not persisted through that route. Submitted user features replace the stored list.

Compare a reusable role with a sparse, reviewed and time-bounded replacement override. Record retained and intentionally lost role grants.

• reuse
• clarity
• exceptions
• review cost
• drift risk
• revocation
• organization reach
• debugging
• recommended use

Permission and data isolation are separate controls

Keep feature permission, tenant context, organization ACL, selected organization, route-specific scope helper, domain ownership rule and actual query filter separate. Current TC-AUTH-049 demonstrates a narrow caveat: a stored role organization list round-trips while the tested directory organization listing remains tenant-scoped. This test does not show how every other route handles that list.

Route feature arrays are normally all-of. Global and compatible module wildcards reduce administration but widen future-feature exposure; a module wildcard does not grant another module. Enabled-module filtering also matters. Hidden navigation affects user experience. It does not provide server authorization.

Name feature, tenant check, organization or data filter, target ownership, allow and denial cases, privileged exception, evidence and owner.

• 1. page navigation
• 2. API list
• 3. API item
• 4. create
• 5. edit
• 6. delete
• 7. bulk action
• 8. import
• 9. export
• 10. search
• 11. report or dashboard
• 12. attachment
• 13. background job
• 14. scheduler
• 15. webhook
• 16. integration
• 17. portal
• 18. AI tool
• 19. support or admin tool
• 20. custom route

Six hypothetical role archetypes

Define responsibility, permitted and prohibited action families, data reach, approval authority, human or machine status, sensitive combinations, review prompt, emergency handling and acceptance evidence. These are not shipped defaults.

Defaults, upgrade and delegation

Setup can seed superadmin, admin and employee while enabled modules contribute defaultRoleFeatures, including custom role names. Setup history determines the effective result. auth sync-role-acls adds missing declared defaults idempotently; it does not revoke extra or stale grants or reconcile a desired policy. Review source, decide intended roles, sync or migrate, diff, run positive and negative tests, approve, retain evidence and review again.

Record the actor-held grant and organization boundary, protected target and tenant checks, residual risk, approval, monitoring and stop condition. auth.acl.manage alone does not authorize wider access.

• 1. assign an existing low-risk role
• 2. edit exact grants
• 3. grant a module wildcard
• 4. grant unrestricted organization reach
• 5. grant ACL-management authority
• 6. grant tenant administration
• 7. grant global wildcard or superadmin

Privileged access, lifecycle and review

Current source recognizes global superadmin behavior. Treat it as exceptional break-glass authority: minimum holders, separate daily and admin identities, strong authentication, controlled custody, scope selection, logging, alerts, review, revocation, recovery and no shared accounts. Time-bound activation remains project-specific unless implemented and proven.

Record trigger, requester, approver, identity action, tenant and organization, role, override, sessions, evidence, deadline, exception and reviewer. Current core has create, update, password, session and transactional delete cleanup, but no general isActive user property. Do not invent a deactivate step.

• joiner
• mover
• leaver

Segregation-of-duties prompts

• requester and approver
• order and credit or refund
• catalog and price approval
• import and reconciliation
• role design and role assignment
• key creation and key use
• audit review and audit administration
• deployment and production access
• project-specific conflicts

Review users, role assignments, Role ACL, User ACL, organization reach, superadmins, ACL managers, dormant identities, sessions, keys, IdP mappings, portal roles, AI delegation and custom guards. The reviewed core contains no universal SoD engine or review scheduler.

Machine identities and separate trust domains

Assign an accountable decision and acceptance evidence for the exact machine credential.

• 1. owner
• 2. purpose
• 3. tenant
• 4. organization
• 5. roles
• 6. exact inherited features
• 7. creator
• 8. one-time secret custody
• 9. expiry
• 10. last use
• 11. rotation
• 12. revocation
• 13. incident response
• 14. cache invalidation
• 15. evidence
• 16. review trigger

Current API keys store a hashed secret and public prefix with tenant, optional organization, roles, creator, last use, optional expiry and soft deletion. The full secret is returned at creation; authentication rejects deleted or expired keys, resolves current scope, and key deletion invalidates relevant caches. Creation is grant-bounded. Current source defines no defaults for source IP restriction, vault integration, automatic rotation, dual control, anomaly detection or service-account separation. The deployment decides these controls.

Record provisioning, authentication, authorization mapping, scope, session or key revocation, evidence and the owner of the trust handoff. Enterprise SSO, SCIM and MFA are optional, edition and configuration dependent.

• staff auth
• customer portal
• API keys
• AI session keys
• enterprise SSO and SCIM
• enterprise MFA

Three synthetic access scenarios

Load the structural row to challenge widening, replacement, custody, expiry, denial evidence and accountable ownership.

Manager acceptance pack

State setup, principal, tenant and organization, operation, required features, expected result and data scope, evidence, prohibited result, induced failure, cleanup, owner and pass criterion.

• 1. no-role denial
• 2. single exact grant
• 3. all-of with one missing grant
• 4. module wildcard
• 5. global wildcard
• 6. disabled-module grant
• 7. multiple-role feature union
• 8. multiple-role organization widening
• 9. user override replacement
• 10. user override removal
• 11. organization-only override attempt
• 12. same-tenant assignment
• 13. cross-tenant denial
• 14. cross-organization data denial
• 15. protected superadmin target
• 16. bounded delegator
• 17. out-of-scope wildcard
• 18. unrestricted-organization escalation
• 19. stale ACL edit
• 20. cache invalidation
• 21. role deletion with users
• 22. joiner
• 23. mover
• 24. leaver and session revocation
• 25. API-key create
• 26. API-key use
• 27. API-key expiry
• 28. API-key revoke
• 29. API-key rotation
• 30. custom route
• 31. hidden navigation with server denial
• 32. background capability helper
• 33. SSO role mapping
• 34. SCIM deprovisioning
• 35. MFA and break-glass
• 36. portal separation
• 37. AI delegated key
• 38. upgrade sync
• 39. periodic access review

Stop or defer

• no accountable policy owner.
• unknown critical route guard.
• feature-only check with unproven data filter.
• cross-tenant denial not tested.
• cross-organization denial not tested.
• unexplained wildcard.
• user override without expiry or review.
• superadmin used for daily work.
• unbounded or unreviewed ACL manager.
• shared machine key.
• unknown secret custody.
• no leaver and session process.
• stale default grants after upgrade.
• unowned segregation conflict.
• optional SSO or MFA represented as active without proof.
• audit evidence too weak for the stated need.