You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Jose Alberto Hernandez <jo...@gmail.com> on 2026/05/26 02:22:38 UTC
[VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
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
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
Hello!
The Fineract PR has been updated with the case to have an IdP setup for
each Tenant, even we can to define a fallback (default setup in the
application properties)
Here is an image to show how It works
[image: architecture.png]
Please let us know any comment or feedback
Thanks in advance
Best regards
Alberto
On Thu, Jun 4, 2026 at 9:06 AM Arnold Galovics <ar...@docktape.com>
wrote:
> Alright, thanks Alberto.
>
> Best,
> Arnold
>
> Arnold Gálovics
>
> *CEO, Co-Founder*
>
> *+36 30 904 1885*
>
> https://docktape.com
>
> Docktape Technologies
>
>
>
>
> On Thu, Jun 4, 2026 at 3:59 PM Jose Alberto Hernandez <
> josealbertohm@gmail.com> wrote:
>
>> 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 <
>> arnold_galovics@docktape.com> 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 <al...@apache.org>
>>> 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 <
>>>> josealbertohm@gmail.com> 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 <
>>>>> arnold_galovics@docktape.com> 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 <
>>>>>> josealbertohm@gmail.com> 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 <
>>>>>>> arnold_galovics@docktape.com> 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 <
>>>>>>>> arnold_galovics@docktape.com> 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 <
>>>>>>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>>>>>>> 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 <
>>>>>>>>>>> josealbertohm@gmail.com> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
Alright, thanks Alberto.
Best,
Arnold
Arnold Gálovics
*CEO, Co-Founder*
*+36 30 904 1885*
https://docktape.com
Docktape Technologies
On Thu, Jun 4, 2026 at 3:59 PM Jose Alberto Hernandez <
josealbertohm@gmail.com> wrote:
> 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 <
> arnold_galovics@docktape.com> 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 <al...@apache.org>
>> 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 <
>>> josealbertohm@gmail.com> 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 <
>>>> arnold_galovics@docktape.com> 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 <
>>>>> josealbertohm@gmail.com> 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 <
>>>>>> arnold_galovics@docktape.com> 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 <
>>>>>>> arnold_galovics@docktape.com> 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 <
>>>>>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>>> josealbertohm@gmail.com> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
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 <ar...@docktape.com>
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 <al...@apache.org>
> 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 <
>> josealbertohm@gmail.com> 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 <
>>> arnold_galovics@docktape.com> 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 <
>>>> josealbertohm@gmail.com> 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 <
>>>>> arnold_galovics@docktape.com> 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 <
>>>>>> arnold_galovics@docktape.com> 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 <
>>>>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>>>>> 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 <
>>>>>>>>> josealbertohm@gmail.com> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
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 <al...@apache.org>
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 <
> josealbertohm@gmail.com> 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 <
>> arnold_galovics@docktape.com> 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 <
>>> josealbertohm@gmail.com> 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 <
>>>> arnold_galovics@docktape.com> 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 <
>>>>> arnold_galovics@docktape.com> 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 <
>>>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>>>> 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 <
>>>>>>>> josealbertohm@gmail.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Aleksandar Vidakovic <al...@apache.org>.
... still looking through the PR, but this approach sounds reasonable to me.
On Wed, Jun 3, 2026 at 8:08 PM Jose Alberto Hernandez <
josealbertohm@gmail.com> 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 <
> arnold_galovics@docktape.com> 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 <
>> josealbertohm@gmail.com> 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 <
>>> arnold_galovics@docktape.com> 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 <
>>>> arnold_galovics@docktape.com> 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 <
>>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>>> 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 <
>>>>>>> josealbertohm@gmail.com> 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
>>>>>>>
>>>>>>>
>>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
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 <
arnold_galovics@docktape.com> 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 <
> josealbertohm@gmail.com> 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 <
>> arnold_galovics@docktape.com> 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 <
>>> arnold_galovics@docktape.com> 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 <
>>>> josealbertohm@gmail.com> 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 <ad...@gmail.com>
>>>>> 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 <
>>>>>> josealbertohm@gmail.com> 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
>>>>>>
>>>>>>
>>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
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 <
josealbertohm@gmail.com> 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 <
> arnold_galovics@docktape.com> 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 <
>> arnold_galovics@docktape.com> 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 <
>>> josealbertohm@gmail.com> 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 <ad...@gmail.com> 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 <
>>>>> josealbertohm@gmail.com> 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
>>>>>
>>>>>
>>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
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 <ar...@docktape.com>
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 <
> arnold_galovics@docktape.com> 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 <
>> josealbertohm@gmail.com> 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 <ad...@gmail.com> 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 <
>>>> josealbertohm@gmail.com> 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
>>>>
>>>>
>>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
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 <
arnold_galovics@docktape.com> 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 <
> josealbertohm@gmail.com> 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 <ad...@gmail.com> 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 <
>>> josealbertohm@gmail.com> 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
>>>
>>>
>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
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 <
arnold_galovics@docktape.com> 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 <
> josealbertohm@gmail.com> 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 <ad...@gmail.com> 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 <
>>> josealbertohm@gmail.com> 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
>>>
>>>
>>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Arnold Galovics <ar...@docktape.com>.
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 <
josealbertohm@gmail.com> 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 <ad...@gmail.com> 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 <
>> josealbertohm@gmail.com> 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
>>
>>
>>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Anu Omotayo via dev <de...@fineract.apache.org>.
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 <jo...@gmail.com> 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 <ad...@gmail.com> 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 <jo...@gmail.com> 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
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
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 <ad...@gmail.com> 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 <
> josealbertohm@gmail.com> 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
>
>
>
Re: [VOTE] FINERACT-2616: OIDC Federation — Auto-resolution of Fineract users from external IdP identities
Posted by Ádám Sághy <ad...@gmail.com>.
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 <jo...@gmail.com> 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