Skip to main content

Tenant Context

Audience​

Developers, QA engineers, support engineers, security engineers, solution architects, and implementation partners.

Reference Content​

This page records source-verified Workforce Scheduling API behavior and boundaries.

Summary​

Application commands require a positive tenant context before processing. Queries depend on tenant-scoped persistence. Tenant identity can be derived from authenticated claims or incoming request headers; a tenant key can also be propagated.

Enforcement layers​

  1. HTTP tenant context resolves tenant and caller metadata.
  2. Commands call the required-tenant guard before writes.
  3. EF Core global query filters constrain tenant-owned scheduling records.
  4. Privileged administrator context can bypass query filters.
  5. Missing tenant context is translated to a bad-request response by the API adapters or outer middleware.

Security boundary​

Header-derived tenant identity is trustworthy only if the edge removes caller-supplied values and adds verified context. Such edge sanitization was not verified. Because scheduling endpoints do not explicitly require authentication, tenant presence must not be treated as proof of caller identity.

Classification​

Tenant filtering is Implemented. Trusted propagation and privileged cross-tenant authorization require confirmation.

Source References​

  • microservices/src/attendance-service/Infrastructure/Persistence.cs
  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Application/Services/ShiftPolicyCommands.cs

See Also​

Keywords​

  • Workforce Scheduling API
  • Shift endpoints
  • Attendance policy API

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Next review: 2026-10-20