Hey guys, Just putting a ping here.
Best, Arnold Arnold Gálovics *CEO, Co-Founder* *+36 30 904 1885* https://docktape.com Docktape Technologies On Fri, May 29, 2026 at 9:03 AM Arnold Galovics < [email protected]> wrote: > Hi guys, > > I'm still digesting this, but one thing we for sure need: tenant-based > OIDC configuration. > > I think it's naive to think that a single OIDC configuration will be fine > for all tenants at once. We need to be able to configure the different OIDC > providers (even if they are different Keycloak realms) based on tenants. > If you think about it, this is the same thing as we have today with > Fineract with the internal user authentication. The users are different for > each tenant. > > Alberto, does your change account for this? > > Thanks, > Best, > Arnold > > Arnold Gálovics > > *CEO, Co-Founder* > > *+36 30 904 1885* > > https://docktape.com > > Docktape Technologies > > > > > On Thu, May 28, 2026 at 7:30 PM 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 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 >>> >>> >>>
