Skip to main content

Roles and Permissions

Summary​

The extracted identity model assigns users to roles and roles to permissions, then emits the resulting roles and permissions as JWT claims for downstream evaluation.

Audience​

  • Platform and customer administrators
  • Implementation partners
  • Developers and QA engineers
  • Solution architects and security engineers

Purpose​

Roles provide manageable access groupings, while permissions allow downstream applications to express more specific access requirements.

Architecture​

Permission evaluation​

The exact order and combination of checks are downstream-specific; the diagram shows the confirmed concepts, not a universal policy implementation.

Business concepts​

  • A user can have multiple role assignments.
  • A role can grant multiple permissions.
  • A permission can be included in multiple roles.
  • Roles can carry portal and tenant scope.
  • Effective claims are de-duplicated from all assigned roles at token issuance.

Technical implementation​

Confirmed identity-service role names are deliberately limited:

RoleConfirmationCurrent meaning
SuperAdminConfirmedPlatform account required for super-admin portal login; recognized by downstream platform and tenant-aware boundaries.
AdminConfirmed in development seeding and active-monolith administrationClient-HRMS administrator role. Production provisioning through identity-service APIs is Requires confirmation.
PlatformAdmin / Platform AdminTransitionalAccepted by platform-service access checks, but identity-service creation and assignment are Requires confirmation.
EmployeeTransitionalUsed by active-monolith/client behavior, but an identity-service provisioning and assignment workflow is Requires confirmation.

Other tenant-defined or legacy role names may exist because the active monolith supports role administration. They are not declared as canonical identity-service roles in this page. A consolidated production role catalog is Requires confirmation.

The identity data model supports tenant/portal-scoped roles and many-to-many role/permission assignments. Identity-service currently exposes no role or permission administration endpoints; those operations remain Transitional in the monolith.

Confirmed source references​

  • microservices/src/identity-service/Domain/Entities/Role.cs
  • microservices/src/identity-service/Domain/Entities/Permission.cs
  • microservices/src/identity-service/Domain/Entities/UserRole.cs
  • microservices/src/identity-service/Domain/Entities/RolePermission.cs
  • microservices/src/identity-service/Data/IdentityDevelopmentSeeder.cs
  • Controllers/UserManagementController.cs
  • microservices/src/platform-service/Api/PlatformAdminEndpoints.cs

See Also​

Keywords​

  • Role hierarchy
  • Effective permissions
  • Canonical roles

Revision Information​

  • Last reviewed: 2026-07-14
  • Owner: identity-team
  • Status: Draft