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
| Concern | Confirmed behavior |
|---|---|
| Bearer support | Registered by the Employee Service host. |
| Authentication middleware | Runs before endpoint mapping. |
| Authorization policies | Named Employee policies are registered. |
| Policy attachment | No direct, compatibility, or foundation route mapping calls RequireAuthorization; effective endpoint requirement is Requires confirmation. |
| Unauthorized / forbidden bodies | No 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.csmicroservices/src/employee-service/Infrastructure/Persistence.csmicroservices/src/employee-service/Api/EmployeeDirectEndpoints.csmicroservices/src/gateway-api/Program.cs
Related Articles
See Also
Keywords
- Bearer token
- Tenant context
- Correlation ID
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly