Skip to main content

Leave Security Boundaries

Summary

Leave security depends on authenticated identity, trusted gateway context, tenant isolation, scoped authorization, external-service trust, and auditability.

Audience

Security engineers, developers, architects, QA, and support.

Overview

Authentication middleware validates caller identity. Tenant context is required by commands and EF query filters. Compatibility behavior confirms self, team/approver, and tenant-wide scopes; final authorization parity in extracted service ownership requires confirmation and is Transitional.

Downstream calls forward the minimum available tenant/actor context needed by Attendance and Workflow. Workflow completion is correlated to the Leave request and can be checked against Workflow state. Attendance is trusted as conflict authority. Employee projection data should be minimized, protected, and treated as potentially stale.

Global filters, authentication, and audit records are defense layers, not universal authorization guarantees. Privileged contexts, callbacks, gateway forwarding, external clients, and administrative operations require least privilege and explicit ownership. Sensitive internal policy details are intentionally excluded.

Source References

  • microservices/src/leave-service/Program.cs
  • microservices/src/leave-service/Infrastructure/Persistence.cs
  • Controllers/LeaveRequestsController.cs
  • microservices/src/leave-service/Infrastructure/WorkflowServiceClient.cs

See Also

Keywords

  • Leave Service
  • Leave Security Boundaries
  • Technical architecture

Revision Information

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