Aman-Mittal opened a new issue, #367:
URL: https://github.com/apache/fineract-backoffice-ui/issues/367
## Summary
The application has a permission model, a permission-aware sidebar, and a
`*appHasPermission`
directive — but nothing enforces permissions at the router. `authGuard`
answers *"is this user
signed in?"*. Nothing answers *"may this user open this feature?"*.
All 324 routes carry `authGuard` and nothing else:
```
$ grep -rn "canActivate\|canMatch" src/app --include=*.ts | grep -v spec
# authGuard (authentication) and developerToolsGuard (backend Spring
profile) only
```
So a signed-in user with `READ_CLIENT` and nothing else can type
`/accounting/chart-of-accounts`,
`/security/users` or `/system/permissions` into the address bar and the
screen opens. The sidebar
hides those entries; the URL hands them straight back. There is also no
Access Denied page — a 403
from the API surfaces only as a toast
(`core/interceptors/error.interceptor.ts:61`).
Navigation gating is thin for the same reason: 21 permission gates across
115 routed nav entries,
so most menu entries are visible to every authenticated user regardless of
their role.
## Business Value
- **Least privilege becomes real rather than cosmetic.** An institution that
configures a
teller role today cannot demonstrate that the teller is confined to teller
screens — the
confinement is a menu, and a menu is not a control. Restricting the router
is what makes the
role configuration mean something operationally.
- **Removes a class of support and audit findings.** A user who reaches a
screen they have no
permission for sees a page of failed requests and empty tables. That is
indistinguishable from
a broken deployment, and it generates support load and audit questions
that cost real time to
close.
- **Needed for release readiness.** A core-banking back office that cannot
show URL-level
authorization is difficult to put in front of an institution's own
security review, whatever
the server does. `security.md` still opens with "not release-ready"; this
is one of the items
standing behind that sentence.
- **Stops the gap widening.** New screens are added continuously. Without a
declared requirement
per route and a check that keeps navigation and routing in agreement,
every feature added
enlarges the surface and the drift is invisible until someone goes looking.
## What this is not
Client-side RBAC is **defence-in-depth**. Fineract Core performs its own
permission check on every
request and remains the authoritative security boundary. The value here is
that a user is not led
into a screen whose every request will 403, and that the URLs a user can
reach agree with the
navigation they are shown. Any fix should say so plainly rather than imply
the client is the
boundary.
## Scope
- A permission guard reading a declared requirement from each route,
delegating evaluation to the
existing `AuthService.hasPermission()` — `ALL_FUNCTIONS` and
`ALL_FUNCTIONS_READ` must keep
working unchanged, and there must not be a second permission
implementation.
- A real Access Denied destination, accessible and keyboard-reachable. A
guard that fails the
route match instead falls through to `path: '**' → redirectTo: ''` and
silently deposits the
user on the dashboard, which reads as a broken link rather than a decision.
- Read and write screens must declare *different* codes, or
`ALL_FUNCTIONS_READ` hands a read-only
user a form they cannot submit.
- Navigation gates brought into agreement with route requirements, plus a
check that keeps them
there — the two are declared separately and drift silently in both
directions.
- Permission codes taken from `GET /v1/permissions` on a running instance.
Codes must not be
invented: a gate on a code Fineract does not define can never be satisfied
by any role, which is
worse than no gate.
- Coverage for the permission matrix, including a genuinely restricted
Fineract user, asserting
that the platform refuses what the UI refused.
- `rbacEnabled: false` must continue to restore the pre-RBAC behaviour for
deployments mid-rollout.
## Related
Route authorization was previously deferred because it is a behaviour change
rather than a
refactor: routes that are reachable today would stop being reachable. That
is a genuine breaking
change and should be stated as one.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
