Currently with this implementation not, yet... The idea is to have one IdP per tenant, so we can get this
Let me update the PR with this and I'll back... Thanks! Alberto On Thu, Jun 4, 2026 at 4:11 AM Arnold Galovics <[email protected]> wrote: > Hi Alberto, > > I think this is a good start but in my opinion is still not enough. > > I think this is just one way to run Keycloak but we cannot assume Keycloak > and the way it's issuer is configured. > > One tenant could be hooked into Keycloak, another one with Google Login > directly and so on. > > Can we support that? > > Best, > Arnold > > Arnold Gálovics > > *CEO, Co-Founder* > > *+36 30 904 1885* > > https://docktape.com > > Docktape Technologies > > > > > On Wed, Jun 3, 2026 at 11:46 PM Aleksandar Vidakovic <[email protected]> > wrote: > >> ... still looking through the PR, but this approach sounds reasonable >> to me. >> >> On Wed, Jun 3, 2026 at 8:08 PM Jose Alberto Hernandez < >> [email protected]> wrote: >> >>> Considering that, you're right, and this is a design gap worth fixing >>> >>> The standard pattern for multi-tenant resource servers is issuer-based >>> tenant resolution, which Spring Security supports natively via >>> *JwtIssuerAuthenticationManagerResolver*. Each Keycloak realm has a >>> unique iss value in its JWTs. That issuer URL is a stable >>> (cryptographically-scoped identifier for the realm) no custom claims >>> needed, no shared realm, no coordination between tenants. The resource >>> server just maps *iss → tenant-id* and builds a per-issuer *JwtDecoder* >>> that validates tokens against the correct JWKS endpoint. >>> >>> The result is a three-tier resolution hierarchy: >>> >>> iss → issuer map (realm-per-tenant, zero custom claims) >>> → tenant-claim-name (single-realm, claim-based) >>> → Fineract-Platform-TenantId header / query param (tooling/CI >>> fallback) >>> >>> This covers the full deployment without forcing any particular IdP >>> topology. >>> >>> Does this direction align with what you had in mind? If so, I can update >>> the PR with these changes >>> >>> Best regards >>> Alberto >>> >>> >>> On Wed, Jun 3, 2026 at 11:16 AM Arnold Galovics < >>> [email protected]> wrote: >>> >>>> Hi Alberto, >>>> >>>> Thanks for the reply. >>>> >>>> I still think this is not enough. Having a separate custom claim in the >>>> JWT is fine for really really small deployments where you own everything. >>>> >>>> In slightly bigger deployments maybe one Keycloak instance is the one >>>> serving as an auth server but multiple realms are there (with separate >>>> clients at this point). >>>> >>>> The way you describe separation would mean the only option is to have >>>> one Keycloak instance with a single Realm and with a single client and >>>> within that realm, all users get JWTs with their respective tenant IDs. I'd >>>> hardly call that separation and wouldn't fly in any medium deployments. >>>> >>>> I'd hold off your PR before people start utilizing and depending on >>>> this singular OIDC configuration because migration in the future might be >>>> more costly than doing it the proper way at the starting line. >>>> >>>> Thanks. >>>> Best, >>>> Arnold >>>> >>>> >>>> Arnold Gálovics >>>> >>>> *CEO, Co-Founder* >>>> >>>> *+36 30 904 1885* >>>> >>>> https://docktape.com >>>> >>>> Docktape Technologies >>>> >>>> >>>> >>>> >>>> On Wed, Jun 3, 2026 at 2:25 PM Jose Alberto Hernandez < >>>> [email protected]> wrote: >>>> >>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>>
