Skip to main content

Employee Identity Integration

Summary​

Employee Service integrates with Identity through accepted authenticated token context, not through a direct service client or shared data store.

Audience​

  • Backend developers and QA engineers
  • DevOps engineers, solution architects, and security engineers

Purpose​

Keep account security ownership separate from workforce ownership while documenting the confirmed request-context dependency.

Confirmed integration​

  • Employee host accepts bearer authentication for both transitional and Identity token authorities.
  • Validated claims provide actor, role, and tenant context used by Employee application and audit components.
  • Identity owns users, credentials, roles, permissions, tokens, and sessions.
  • Employee owns employee profile, employment, organization references, status, and history.
  • Employee has no project reference to Identity Service and registers no Identity HTTP client.
  • No Identity event consumer is implemented in Employee Service.

Requires confirmation​

  • One-to-one mapping and synchronization between an Identity user and Employee record.
  • Automatic account provisioning during joining.
  • Account disablement or access revocation during termination.
  • Complete permission-policy enforcement across all Employee presentation surfaces.
  • Final retirement of transitional authentication authority/context.

No key material, signing implementation, token lifetime, configuration values, or internal trust mechanism is documented.

Source References​

  • microservices/src/employee-service/Program.cs
  • microservices/src/employee-service/Infrastructure/Persistence.cs
  • microservices/src/identity-service/Program.cs
  • microservices/src/identity-service/Domain/Entities/

See Also​

Keywords​

  • Identity boundary
  • Authenticated context
  • Account separation

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-15
  • Review cycle: Quarterly