Role Based Access Control for Consent Portal #77

Requirement

Conditionally show pages and actions based on the authenticated user's permissions:

• Administrators can manage elements and purposes and view all consents.
• DPOs can view all consents and will later access grievances.
• End users can view and manage only their own consents.

Backend APIs must enforce the same permissions independently of UI visibility (It already does as at now).

Reference: APIM Portals

APIM maps roles to OAuth scopes. The frontend does not communicate directly with the identity provider. It calls APIM’s backend introspection endpoint, which reconstructs the access token and sends it to the identity provider for introspection (introspect.jsp).

The backend returns the introspection result to the frontend. The frontend extracts the granted scopes and stores them on the current user (AuthManager.js).

UI elements are wrapped with ScopeValidation, which compares the user’s scopes with those required by the API operation. For example, the Delete API button is conditionally displayed using this component (DeleteApiButton.jsx).

The APIs independently enforce the same scopes. UI visibility is therefore a usability feature rather than the security boundary.

Suggested approach

Use the existing API scopes as the common permission model for frontend visibility and backend authorization. Avoid checking role names such as Admin or DPO directly in the frontend.

The frontend should call the backend /me endpoint and must not interact directly with the identity provider. The backend should:

1. Reconstruct the access token from its split-token storage.
2. Validate the JWT signature using the identity provider’s JWKS.
3. Validate claims such as issuer, audience, expiry, subject, and organization.
4. Extract the granted scopes from the validated token.
5. Return a minimal current-user response:

{
  "authenticated": true,
  "userId": "user-123",
  "organizationId": "org-1",
  "scopes": [
    "portal:consents:read:any",
    "portal:elements:read"
  ]
}

The frontend should load /me during application initialization and provide reusable authorization utilities for:

• Hiding inaccessible navigation items.
• Protecting routes from direct navigation.
• Hiding or disabling create, edit, delete, and revoke actions.
• Checking whether the user has any or all required scopes.

Use the following role-to-scope mappings:

• Administrator: consent read/write-any and element/purpose read/write scopes.
• DPO: consent read-any and future grievance scopes.
• End user: consent read/write-self scopes.

Every backend endpoint must continue enforcing its required scope using the validated principal. Frontend checks are only for presentation and navigation and are not the security boundary.

Reuse API scopes when a page represents access to the corresponding API capability. Add a new scope only for a genuinely distinct permission, such as grievance access, rather than introducing separate UI-only scopes.