Workflow Authentication and Authorization
Summary
JWT bearer authentication is configured and authentication/authorization middleware runs. Workflow endpoints do not require authorization, and the policy catalog is empty. Backend access control is therefore Not implemented at the endpoint boundary.
Authentication
The bearer handler can validate tokens against configured issuer, audience and signing-key sets. Email and role claims are configured as identity sources. Validation switches depend on whether corresponding configuration is present.
Authorization
No policy names are registered because the policy collection is empty. The Workflow route group and individual endpoints have no authorization requirement. Task-decision commands also do not compare the actor with user/role assignment.
Presentation-layer controls
The portal route and navigation apply permission/role checks. These are user-experience controls and do not replace backend enforcement.
Security boundary
Tenant filtering restricts data selection when valid tenant context is supplied, but tenant context can also be derived from request metadata independently of authenticated identity.
Limitations
Anonymous callers with accepted tenant metadata can reach the direct endpoints. Authoring, observability and decision operations have no verified backend permission separation.
Requires Confirmation
Production ingress controls, mandatory-token configuration, trusted tenant-metadata injection and the intended permission matrix require confirmation.
Source References
microservices/src/workflow-service/Program.csmicroservices/src/workflow-service/Api/Policies.csmicroservices/src/workflow-service/Api/WorkflowEndpoints.csmicroservices/src/workflow-service/Infrastructure/Persistence.csUI/salary-ui/apps/client-hrms-portal/src/utils/ProtectedRoute.tsx
Related Articles
See Also
Keywords
Workflow architecture, approval engine, Workflow Service, technical foundation.
Revision Information
- Status: Draft
- Last reviewed: 2026-07-20
- Next review: 2026-10-20