Hello! Sorry for the late reply A single OIDC config means sharing the same IdP, not the same tenant. One Keycloak instance can serve multiple tenants perfectly well using a custom *fineract_tenant* claim in the token.
The implementation already handles multi-tenancy correctly *OidcTenantAwareFilter* resolves the tenant from the JWT claim before any authentication happens, and *OidcAppUserResolutionService* maps the identity to a per-tenant *AppUser*, just like Basic Auth does today. Per-tenant IdP configuration (different realms/providers per tenant) is a valid but significantly more complex feature — it would require storing OIDC config per tenant in the database and dynamic issuer resolution at request time. That deserves its own JIRA, not a blocker on this PR. What do you think? Thanks and regards Alberto On Wed, Jun 3, 2026 at 3:01 AM Arnold Galovics <[email protected]> wrote: > 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 >>>> >>>> >>>>
