nitesh
a83806062e
Endpoints that need to be reachable by a third-party integration without a Fineract username/password used to have no supported way to do that other than the heavyweight IMPS/NPCI pattern (RSA-signed JWT envelopes, built for one specific bank-switch protocol). This adds a general-purpose one: mint an X-Api-Key credential, hand it to the partner, done. New table m_api_client lives in the tenant-STORE database (fineract_tenants), not any one bank's own tenant database. That is deliberate: a key identifies a CALLER, independent of which bank's data a given request asks for, so one minted key keeps working against every tenant that exists now and every one provisioned later -- a per-tenant copy would need a manual re-insert on every new bank and a row per tenant per key, which is exactly what storing it once, centrally, avoids. Fineract-Platform-TenantId keeps doing what it always did: routes the rest of a request to the right bank's database. This table only decides who is allowed to make the request at all. ApiClientCredentialService.authenticate() is what an endpoint calls in place of PlatformSecurityContext#authenticatedUser() when it sees an X-Api-Key header. Security properties: - Only a SHA-256 hash of the key is ever stored -- same reason Fineract never stores a user's plaintext password. The raw key is returned exactly once, at creation (POST /v1/apiclients), and cannot be retrieved again. - Every failure path (key doesn't exist, is deactivated, caller's IP isn't on its allowlist) raises the identical 401 message, so a probing caller can't use the response to tell a wrong key apart from a valid-but-blocked one. - allowedIps is a plain comma-separated exact-match list, adequate for a small set of known partner integrations, not CIDR ranges. ApiClientAdminApiResource (create/list/deactivate/reactivate a key) is itself gated by an ordinary Fineract login restricted to a super user (ALL_FUNCTIONS) -- issuing a credential that skips login is not something to hand out casually. SecurityConfig gets one new permitAll() matcher, narrowly scoped to GET /api/*/clientaccounts/** -- the same posture this fork already uses for the IMPS and NPCI receivers: the outer Spring Security gate stays open for one specific path, and the resource itself is what actually authenticates the caller. A normal logged-in SPA user hitting that same path is unaffected -- Basic Auth still runs for any request that carries an Authorization header, permitAll only stops an anonymous one from being rejected before the handler gets a chance to check for a key instead.