Skip to main content

Notification API Authorization

Summary​

No authorization is registered or declared on the native surface. The compatibility surface enforces caller-scoped access in handler code rather than through policies. No role or policy name governs any Notification endpoint in the reviewed backend source.

Audience​

Security reviewers, engineers, architects, QA and support.

Native surface​

Program.cs contains no AddAuthorization call and no UseAuthorization middleware call. No native endpoint declares a policy, a role requirement, a scope check or a RequireAuthorization call.

Object-level access: every native handler that operates on a single record loads it by identifier alone. The read-state action, the single-message read, the attempts query, the retry action and both template mutations perform no ownership, recipient or tenant check before acting. Knowledge of an identifier is sufficient.

Collection-level access: the failed queue, the audit trail and the statistics endpoints apply no tenant predicate, so they return data spanning every tenant.

Administrative separation: administrative operations share the /notifications path prefix with the recipient-facing inbox and are distinguished only by a Swagger tag. Nothing in the route structure separates operator functions from employee functions.

Compatibility surface​

Authorization on the monolith is enforced imperatively inside each action rather than declaratively.

Verified checks: the notification actions resolve the caller to a user record and then constrain every query and mutation to that user's rows. The read action matches both the row identifier and the caller's user identifier before updating, so an identifier belonging to another user yields 404 rather than a successful write. The read-all action updates only rows belonging to the caller. This is genuine object-level ownership enforcement.

The template controller declares only the authenticate requirement; the reviewed actions apply no role check, so any authenticated caller may list, save, preview or reset templates.

Frontend-declared permissions​

The portal navigation declares permission and role hints for the notification views — a self-service view gated on a self-scoped permission, and administration and template views gated on an administrative permission and an HR administrator role.

These are client-side navigation hints only. They control which menu entries render. No corresponding server-side check exists in either the native service or the reviewed template controller, so they must not be treated as an access-control boundary.

Missing enforcement (verified)​

  • No authorization services or policies are registered in the native service.
  • No native endpoint declares any authorization requirement.
  • No ownership check exists on any native single-record operation.
  • No tenant predicate exists on the native cross-tenant collection endpoints.
  • The monolith template operations carry no role requirement.
  • Portal permission hints have no verified server-side counterpart.

Classification​

Partial — ownership enforcement is Implemented on the compatibility notification actions; authorization is Not implemented on the native surface and on the compatibility template actions.

Requires confirmation​

Whether an upstream component enforces role separation for administrative notification routes, and whether in-service policies are planned, require confirmation.

See Also​

Keywords​

  • Notification API
  • Authorization
  • Draft API documentation

Source References​

  • microservices/src/notification-service/Program.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • Controllers/NotificationsController.cs
  • Controllers/NotificationTemplatesController.cs
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx

Revision Information​

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