KRYSTALM7 opened a new issue, #153:
URL: https://github.com/apache/fineract-loan-origination/issues/153
## Problem
The LOS API currently relies on authentication in several places without
consistently enforcing whether the authenticated principal is a customer or
staff member.
The security configuration should enforce a clear separation between:
- Customer APIs
- Staff APIs
- Administrative APIs
Currently, the staff security chain uses `authenticated()` and the customer
chain does not consistently require `ROLE_CUSTOMER`.
This creates authorization gaps across multiple endpoints.
## Affected Areas
Potentially affected staff endpoints include:
- `GET /api/v1/loan-applications`
- `GET /api/v1/loan-applications/{ref}`
- `GET /api/v1/loan-applications/{ref}/credit-score`
- `POST /api/v1/loan-applications`
- `POST /api/v1/loan-applications/{ref}/submit`
- Staff endpoints under `/api/v1/staff/**`
Customer endpoints under `/api/v1/customer/**` should likewise require a
customer principal.
## Root Cause
`SecurityConfig` currently relies heavily on:
`anyRequest().authenticated()`
instead of enforcing the role appropriate for each API boundary.
In addition, authorization is distributed across individual controller
methods rather than being consistently enforced at the route/controller level.
## Additional Concern
The staff loan creation endpoint accepts `fineractClientId` from the request
body.
Customer application creation correctly derives the Fineract client identity
from the authenticated customer principal.
The staff/customer separation should therefore ensure that a customer cannot
reach the staff creation endpoint and select another customer's Fineract client
ID.
## Impact
A customer may potentially access staff functionality, while staff
principals may potentially reach customer-only routes.
The inconsistent authorization model also makes it difficult to audit and
maintain the application's security boundary.
## Proposed Fix
- Require `ROLE_CUSTOMER` for `/api/v1/customer/**`.
- Require `ROLE_STAFF` for `/api/v1/loan-applications/**` and
`/api/v1/staff/**`.
- Require `ROLE_ADMIN` for administrative endpoints where applicable.
- Add class-level authorization to staff controllers.
- Remove unused duplicate staff application creation/submission endpoints if
the customer-specific flow is now authoritative.
- Ensure Fineract client identity cannot be selected by a customer through
request payload manipulation.
- Add a centralized authorization-matrix integration test.
## Acceptance Criteria
- [ ] Customer JWT receives `403` for all staff-only endpoints.
- [ ] Staff JWT receives `403` for customer-only endpoints.
- [ ] Anonymous requests are rejected.
- [ ] Customer application creation always derives the Fineract client
identity from the authenticated customer.
- [ ] A customer cannot create an application for another Fineract client.
- [ ] Duplicate unused staff application endpoints are removed or explicitly
justified.
- [ ] Existing customer and staff flows continue to work.
## Regression Tests
- [ ] Anonymous × all protected endpoints
- [ ] Customer × staff endpoints
- [ ] Loan Officer × customer endpoints
- [ ] Branch Manager × customer endpoints
- [ ] Customer cannot create an application for another Fineract client
- [ ] Full authorization matrix integration test
--
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]
