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 Regards Alberto 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 > <https://issues.apache.org/jira/browse/FINERACT-2616> > > 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 <https://github.com/apache/fineract/pull/5883> > > --- > 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 > > >
