Skip to main content

Employee API Authentication and Context

Summary

Employee Service registers Bearer-token validation, authentication middleware, authorization middleware, tenant-context resolution, and correlation handling. The reviewed Employee endpoint groups do not attach an authentication or authorization policy, so endpoint enforcement remains Requires confirmation.

Audience

  • API integrators and QA engineers
  • Security engineers and solution architects
  • Support engineers interpreting context failures

Confirmed boundary

Clients are expected to authenticate at the platform boundary and send requests through the gateway. The gateway forwards the request downstream. Employee Service can validate supported Bearer tokens and derives tenant and user context from the authenticated request. Exact token signing details, sensitive configuration names, and non-production context mechanisms are intentionally excluded.

Authentication and authorization findings

ConcernConfirmed behavior
Bearer supportRegistered by the Employee Service host.
Authentication middlewareRuns before endpoint mapping.
Authorization policiesNamed Employee policies are registered.
Policy attachmentNo direct, compatibility, or foundation route mapping calls RequireAuthorization; effective endpoint requirement is Requires confirmation.
Unauthorized / forbidden bodiesNo Employee-specific 401 or 403 contract is declared; gateway or framework behavior is Requires confirmation.

Tenant, user, and correlation context

Direct command/query handlers require a tenant identifier for scoped operations. Missing tenant context is translated by direct endpoints to HTTP 400 with an ApiResponse failure. Compatibility operations use tenant-filtered data and tenant-aware services, but their missing-context outcome is not uniform and is Requires confirmation. Foundation endpoints do not consume tenant context.

The tenant context supports a confirmed super-admin bypass of tenant query filters when an authenticated super-admin context is present. Which public callers may use that capability is Requires confirmation; clients must not assume cross-tenant access.

User context is used for safe audit attribution when present. Direct responses propagate the incoming correlation identifier or the server trace identifier. The public correlation header is X-Correlation-Id.

Source References

  • microservices/src/employee-service/Program.cs
  • microservices/src/employee-service/Infrastructure/Persistence.cs
  • microservices/src/employee-service/Api/EmployeeDirectEndpoints.cs
  • microservices/src/gateway-api/Program.cs

See Also

Keywords

  • Bearer token
  • Tenant context
  • Correlation ID

Revision Information

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