Aman-Mittal commented on issue #370:
URL: 
https://github.com/apache/fineract-backoffice-ui/issues/370#issuecomment-5306813731

   ## The open question is answered: **no, OIDC does not disable password 
authentication**
   
   With a configuration present and `enabled: true`, `GET /v1/offices` still 
answers **200** to Basic
   auth. Upstream confirms this is the design — Bearer tokens route to the OIDC 
chain, Basic
   credentials fall through to the existing one, and both run simultaneously.
   
   So this issue is **inert rather than dangerous**: the configuration does 
nothing, but nothing
   breaks either. That is a materially lower severity than #369, where enabling 
two-factor
   authentication takes the whole deployment offline. **#369 should go first.**
   
   ## Upstream context
   
   OIDC federation is 
[FINERACT-2616](https://issues.apache.org/jira/browse/FINERACT-2616)
   ([apache/fineract#5883](https://github.com/apache/fineract/pull/5883), 
merged 10 June 2026),
   **resolved with fix version 1.15.0**, under the still-in-progress
   [FINERACT-1908](https://issues.apache.org/jira/browse/FINERACT-1908) modular 
security architecture.
   
   It is a **resource-server** design: Fineract validates a JWT that an 
identity provider issued. It
   never performs the authorization-code exchange. Getting the token is the 
client's job — which is
   precisely the part missing here, so the scope in this issue stands.
   
   Enabling properties are documented in 
`fineract-doc/src/docs/en/chapters/security/oidc-federation.adoc`:
   
   | Property | Default |
   |---|---|
   | `fineract.security.oidc-federation.enabled` | `false` |
   | `fineract.security.oidc-federation.tenant-claim-name` | `fineract_tenant` |
   | `fineract.security.oidc-federation.username-claim` | `preferred_username` |
   | `fineract.security.oidc-federation.auto-create-user` | `false` |
   | `fineract.security.oidc-federation.provider` | `generic` |
   
   ## This is blocked
   
   **Enabling federation stops Fineract from starting.** With
   `FINERACT_SECURITY_OIDC_FEDERATION_ENABLED=true` on `apache/fineract:latest`:
   
   ```
   The dependencies of some of the beans in the application context form a 
cycle:
     oidcFederationSecurityConfig
      ↑     ↓
     dynamicJwtIssuerAuthenticationManagerResolver
   ```
   
   `OidcFederationSecurityConfig` `@Autowired`s 
`DynamicJwtIssuerAuthenticationManagerResolver`, which
   resolves back into it. Spring prohibits circular references by default, so 
the context aborts and
   `APPLICATION FAILED TO START`.
   
   Nothing in this issue can be built or tested until that is fixed upstream, 
or a Fineract version
   without it is pinned. **That is the first task here**, ahead of any client 
work.
   
   Two further platform defects, also unreported upstream:
   
   - **Writes to the tenant OIDC config always fail on PostgreSQL** —
     `ERROR: column "enabled" is of type smallint but expression is of type 
boolean`, from
     `TenantOidcConfigRepositoryJdbc.insert` binding `setBoolean` to a 
`smallint` column. Reads and
     deletes work; a configuration has to be inserted with SQL.
   - **`MANAGE_TENANT_OIDC_CONFIG`**, which upstream documents as required for 
this endpoint, is not
     among the 698 permissions the platform seeds — which is why 
`/system/oidc-config` stays in the
     route drift check's `UNRESTRICTED` list.
   
   All three need FINERACT tickets. I have not filed them.
   
   ## Partial progress
   
   #371 fixes the configuration screen itself, which turned out to be sending 
field names Fineract has
   never recognised (`issuer`, `authorizationEndpoint`, `tokenEndpoint`, 
`jwksUrl`) — so a configured
   tenant opened it to a blank form. The schemaless request body (`{"type": 
"string"}` in the OpenAPI
   document) meant nothing could catch that at compile time.
   
   It does **not** implement sign-in. That remains this issue, and remains 
blocked.
   
   Full write-up in 
[`DOCS/OIDC.md`](https://github.com/apache/fineract-backoffice-ui/blob/main/DOCS/OIDC.md)
   once #371 lands.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to