Skip to main content

Tenant Isolation

Audience

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

Reference Content

This page records source-verified technical behavior and boundaries for the workforce-scheduling capability.

Summary

Tenant isolation is implemented through an HTTP-derived tenant context, application-level tenant requirements for writes, and EF Core global query filters for tenant-owned records.

Context derivation

Tenant identity can be resolved from principal claims and from request headers. A privileged administrator flag is derived from role claims. Audit actor information and related employee/user references are also derived from request identity context.

Persistence enforcement

Scheduling, attendance, profiles, snapshots, audit, and timeline entities use global query filters. Ordinary requests see the current tenant. Privileged administrator context bypasses those filters. New scheduling aggregates receive the required tenant identity from the application service.

Risks

  • Accepting tenant identity from request headers is safe only when a trusted edge removes untrusted values and supplies verified context; that trust enforcement was not verified in this service.
  • Privileged bypass applies broadly at the context level.
  • Unannotated scheduling endpoints weaken assurance that claims and headers came from an authenticated caller.
  • Compatibility identity is globally unique rather than tenant-composite, reflecting migration needs.

Explicit authorization, trusted-edge validation, cross-tenant negative tests, and audit coverage are required before treating isolation as production-proven.

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
  • Shift policy
  • Attendance integration

Revision Information

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