Skip to main content
InternalMarkdown

Authorization

IAM roles may name broad personas. PlayerPal permissions name business operations. Fine-grained authorization stays server-side.

Long-form: spec §5.3, §17. v1 is application-native Nest checks (ADR 0029). A policy engine waits until a second service shares the same PlayerPal permissions or non-engineers must author those rules.

Personas (IAM)​

player
operator_admin
provider_admin
affiliate_admin
playerpal_support
playerpal_platform_admin

These are not the complete authorization model. Never treat IAM roles as sufficient for alias, ledger or report access.

Permissions (PlayerPal)​

loyalty.self.read
operator.player.loyalty.read
operator.player.alias.issue
provider.activity.write
provider.batch.status.read
reports.aggregate.read
reports.player.read
campaign.read
campaign.manage
integration.read
integration.manage
identity.connection.revoke
support.session.create

Every decision must evaluate principal, organisation, integration, audience, resource owner, permission, data-sharing agreement, and any support or delegated-access context.

Rules​

  • Partners may only use aliases issued to their audience. Cross-audience attempts return the same response as an unknown alias (spec §37).
  • Provider/operator scope comes from authenticated integration configuration, credentials, certificate or upload location, not a free-text payload field (ADR 0014).
  • Support impersonation and cross-operator access are explicit, audited capabilities, not UI tricks.
  • Portal UI hiding a nav item is not enforcement.

Capability gating by assurance level (A0-A3) is described in linking-and-bootstrap.md and ADR 0020.