Skip to main content

Recruitment Identity and Security

Summary​

JWT authentication middleware and tenant context exist, but active native Recruitment authorization policies and endpoint enforcement are not implemented.

Audience​

Backend and frontend engineers, architects, QA, support, security reviewers, and operators responsible for Recruitment.

Overview​

Confirmed boundaries​

  • Authentication accepts configured identity sources and maps email/role claims.
  • Tenant context resolves tenant, actor, and user evidence from identity or forwarded context.
  • EF global filters isolate most tenant-owned reads, with an explicit super-administrator bypass.
  • Purpose-built public flows use an open-position identifier or opaque token and bypass ambient tenant filters.
  • Portal navigation and route protection check feature/permission/role candidates.

The service policy catalog is empty and endpoints do not attach Recruitment policies. UI visibility, gateway authentication, tenant filtering, and lifecycle validation are not substitutes for authorization. Ownership checks, compensation/document scope, self-approval prevention, token expiry/revocation, callback authentication, and native/compatibility parity require confirmation.

Requires confirmation​

Production ownership, authorization policy, operational thresholds, and future design decisions require confirmation.

Source References​

  • microservices/src/recruitment-service/Program.cs
  • microservices/src/recruitment-service/Api/Policies.cs
  • microservices/src/recruitment-service/Infrastructure/Persistence.cs
  • UI/salary-ui/apps/client-hrms-portal/src/utils/ProtectedRoute.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx

See Also​

Keywords​

  • Recruitment technical architecture
  • Recruitment Service
  • Identity and Security

Revision Information​

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