Hello Alberto,
Thanks for working on this OIDC Federation feature, it enables SSO within a
financial institution which is better for user management.
I think the auto-creation feature should not be included given the sensitive
nature of a core banking application (CBA) in a bank.
Implementing it can violate the Principle of Least Privilege (PoLP)
(https://www.paloaltonetworks.com/cyberpedia/what-is-the-principle-of-least-privilege).
To enforce optimal cybersecurity hygiene, access to the CBA should be
restricted only to required personnel, regardless of their SSO status.
Preventing the creation of superfluous accounts minimizes the bank's attack
surface far more effectively than relying solely on least-privilege role
assignments.
SSO users can be setup via the Mifos UI or bulk import. I have seen financial
institutions implement this approach in other applications.
Regards
Anu Omotayo
On Thursday, May 28, 2026 at 06:30:51 PM GMT+1, Jose Alberto Hernandez
<[email protected]> wrote:
Adam, thanks for the feedback and comments.
About the Auto User creation, one suggestion, we can allow the User creation,
but someone else will need to enable the user, as kind of approve control.
And for the IdP options for now It was tested with Google and KeyCloak, we can
test more, the main idea on this implementation is try to be IdP agnostic, to
avoid to have custom implementations
BTW. We can Include in the Vote the initial list of the IdP vendors to be
avallable
Thanks Best RegardsAlberto
On Thu, May 28, 2026 at 5:24 AM Ádám Sághy <[email protected]> wrote:
Hi Alberto,
Thank you for the proposal and the initial information.
Before we proceed with voting, I’d like to clarify a few points:
Automated User and Role Assignment
I’m not particularly fond of the idea of automating user creation and role
assignments.
I can’t help but wonder how it could be abused if enabled or why we should even
have something like that for Fineract.
I understand the convenience it offers, but I believe we need to be strict and
explicit in implementing multiple validations to prevent accidental privilege
escalation or ensuring those who shouldn’t have access are not granted access
to Apache Fineract.
Considering Fineract is a core financial system, access and roles should be
limited and strictly audited. I simply don’t see the need for automation in
registering users and providing access.
I wonder what the community thinks about this.
Lookup by username vs email address
This part looks fine, we can have multiple unique identifiers to look up and
map JWT token holder to Fineract user account, but again, we need to make sure
the validation and look up methods are straightforward and explicit.
Multiple providers are listed
While I am okay to support multiple providers, but implementation wise, I don’t
think we should target more than 1 or 2 at first, and the rest can be
implemented based on need. I don’t want to introduce custom implementations
into the system without maintainers who are interested in keeping up to date
and using it in production.
What do you think?
Regards,
Adam
On May 26, 2026, at 3:22 AM, Jose Alberto Hernandez <[email protected]>
wrote:
Hello Fineract community,
I would like to open a vote on FINERACT-2616: OIDC Federation Support for
External Identity Providers
This allows organizations with an existing corporate IdP (Keycloak, Google
Workspace, Azure AD, Okta, Auth0) to enable SSO without forking authentication
logic or maintaining a parallel user database. The feature is fully opt-in
(fineract.security.oidc-federation.enabled=true) and does not affect existing
Basic Auth or OAuth2 deployments.
Fineract PR raised
---
The core of this contribution is OidcAppUserResolutionServiceImpl, which
bridges an external OIDC identity to a Fineract AppUser using a three-step
strategy on every authenticated request:
1. Lookup by username — using the configured usernameClaim (default:
preferred_username)
2. Fallback by email — matches users pre-existing in Fineract by their
corporate email
3. Auto-creation — when enabled via
fineract.security.oidc-federation.auto-create-user=true, provisions a new
AppUser on first login, assigned to the head office with the configured
defaultRoles merged with any roles extracted from the OIDC token. Throws
OidcUserNotFoundException when auto-create is disabled and no match is found.
---
Please vote:
[ ] +1 approve
[ ] +0 no objection
[ ] -1 object because:
Thank you,
Jose Alberto Hernandez
