Hi A little heads up on this front.
The final nail in the coffin of self-service functionality (inside Fineract) is here: Story https://issues.apache.org/jira/browse/FINERACT-2480 PR https://github.com/apache/fineract/pull/5498 Regards, Adam > On May 14, 2025, at 5:18 PM, James Dailey <[email protected]> wrote: > > Victor - These are important requirements that you raised. So far, I think > some people are on board with these things but I don't yet see a strong > effort on this. > What would you advise as the sequence and prioritization? > > How does this relate to the ongoing FSIPs? > > Do we need to create some tickets to work on? > > James Dailey > > > > On Thu, Mar 13, 2025 at 9:19 PM VICTOR MANUEL ROMERO RODRIGUEZ > <[email protected] <mailto:[email protected]>> wrote: >> Hello, >> >> The Apache Fineract APIs must be deprecated because there are more efficient >> and secure ways to allow end users to access its financial services. >> >> The Apache Fineract must continue to include financial products on its core >> modules and it has to promote the ecosystem around it through interfaces >> that allow third party systems based on open standards the interchange of >> information in a secure manner. >> >> Don't worry there are already plugins (Open sourced which are compatible >> with the current Apache Fineract version) >> >> A self service APi Architecture and Implementation is not limited to the >> technologies that I have mentioned before (On Wed, 31 Jan 2024). Grab a cup >> of coffee and start reading.... >> >> For a more detailed explanation about how to design a secure Self-Service >> API REST architecture with access/identity management, OTP, and >> best-in-class security for the Self Service APIs we must design and >> implement: >> >> >> 1. Authentication & Identity Management >> OAuth 2.0/OpenID Connect : >> Use Keycloak, Zitadel, Gluu or Auth0 as an identity provider (IdP) for >> token-based authentication. >> Example: Secure endpoints with @PreAuthorize("hasRole('USER')") in Spring >> Boot. >> Enforce PKCE (Proof Key for Code Exchange) for public clients (mobile apps). >> JWT Tokens : >> Use short-lived access tokens (e.g., 5 minutes or less) and refresh tokens. >> Validate JWT signatures, issuer (iss), audience (aud), and expiration (exp). >> Password Policies : >> Enforce strong passwords (min 12 characters, mix of symbols/numbers). >> Hash passwords with BCrypt or Argon2 (and never ever store it using >> plaintext). >> >> 2. Multi-Factor Authentication (MFA) with OTP >> TOTP (Time-Based OTP) : >> Integrate with Aegis, Google, Azure, Authenticator or Twilio Authy. >> Use Keycloak, Zitadel, Gluu built-in OTP policies for user >> registration/login. >> OTP Delivery : >> Send OTPs via secure channels (e.g., SMS, email, or authenticator apps). >> Avoid SMS for high-security scenarios (vulnerable to SIM swaps). >> Rate Limiting : >> Limit OTP requests (e.g., 3 attempts per hour) to prevent brute-force >> attacks using an API Gateway (Kong, Gravitee, ApiSix) . >> >> 3. Authorization & Access Control >> RBAC (Role-Based Access Control) : >> Define roles like USER, ADMIN, and SUPPORT with granular permissions. >> Example: Restrict /self/clients/{id} to the owning user only. >> Scope-Based Access : >> Use OAuth2 scopes (e.g., read:profile, write:loans) to limit API actions. >> Attribute-Based Access Control (ABAC) : >> Restrict access based on user attributes (e.g., country, client_type). >> >> 4. Data Protection >> Encryption : >> In Transit : Enforce HTTPS (TLS 1.3+) using . >> In Transit: Make sure to use secure CipherSpecs and CipherSuites >> At Rest : Encrypt sensitive fields (e.g., PII) in the database. >> Masking Sensitive Data : >> Log/display masked data (e.g., accountNumber: "CL-****123"). >> Use @JsonView in Spring to control data exposure. >> >> 5. API Security Best Practices >> Input Validation : >> Sanitize inputs to prevent SQLi/XSS (e.g., use Hibernate/Apache/Spring >> Validator annotations). >> Token Binding : >> Bind tokens to specific devices/IPs to prevent token theft. >> >> 6. Secure OTP Workflow >> Step-Up Authentication : >> Require OTP for sensitive actions (e.g., changing passwords or transferring >> funds). >> Secure OTP Storage : >> Store OTPs in encrypted form (e.g., AES-256) and expire after 5 minutes (or >> less). >> Anti-Phishing Measures : >> Display partial user information (e.g., last 4 digits of the mobile number >> or masked name) during OTP entry. >> >> 7. Audit & Monitoring >> Audit Logs : >> Log all sensitive actions (e.g., login failures, password resets). >> Monitoring : >> Track failed OTP attempts and unusual login patterns with Prometheus/Grafana >> or ELK Stack . >> >> 8. Third-Party Integrations >> Secure Webhooks : >> Sign payloads with HMAC for webhook notifications. >> External Services : >> Use mutual TLS (mTLS) for critical integrations (e.g., payment gateways). >> >> 9. Compliance >> GDPR/CCPA : >> Allow users to export/delete their data via /self/data-export and >> /self/delete-account. >> PCI-DSS : >> Tokenize payment data and avoid storing raw card details. >> >> >> 10. PKI >> >> For making financial transactions the payment payloads can be >> encrypted/decrypted using X.509, this is the standard that we use in México >> for Real Time Payments (QR and Push) >> >> 10.a. Strong Client Authentication >> Mutual TLS (mTLS) : >> X.509 enables mutual authentication (client and server validate each other), >> ensuring only trusted devices/users can access payment APIs. >> Example: A mobile banking app uses a client certificate to authenticate API >> requests, preventing unauthorized access even if credentials are compromised. >> >> 10.b End-to-End Encryption >> Data Integrity & Confidentiality : >> Encrypt API communication using TLS certificates, protecting sensitive >> payment data (e.g., account numbers, transaction details) from interception >> or tampering. >> >> 10.c. Non-Repudiation >> Digital Signatures : >> Transactions signed with X.509 certificates provide irrefutable proof of >> origin, critical for dispute resolution in real-time payments. >> Example: A payment request signed by a client certificate cannot be denied >> by the sender. >> >> 10.d. Compliance with Financial Regulations >> PSD2, PCI DSS, and Open Banking : >> X.509 certificates meet strict regulatory requirements for secure >> communication and strong customer authentication (SCA). >> Example: PSD2 mandates certificate-based authentication for payment service >> providers (PSPs). >> >> 10.e. Granular Access Control >> Role-Based Permissions : >> Embed roles (e.g., merchant, user, admin) in certificates to enforce >> fine-grained authorization. >> Example: A merchant certificate grants access to /payments but not /admin >> endpoints. >> >> 10.f. Protection Against MITM Attacks >> Certificate Pinning : >> Prevent man-in-the-middle attacks by binding API clients to specific server >> certificates. >> Example: Mobile apps pin the server’s X.509 certificate to reject fake >> certificates. >> >> 10.g. Scalability for High-Volume Transactions >> Efficient Handshake : >> TLS session resumption reduces latency for repeated API calls, ideal for >> real-time payments. >> Example: A payment gateway processes thousands of transactions/sec with >> minimal overhead. >> >> 10.h. Automated Certificate Management >> Short-Lived Certificates : >> Use tools like Let’s Encrypt or HashiCorp Vault to automate certificate >> rotation, reducing manual errors. >> Example: Certificates expire every 90 days and auto-renew without downtime. >> >> 10.i. Integration with Hardware Security Modules (HSMs) >> Secure Key Storage : >> Store private keys in HSMs to protect against server-side breaches. >> Example: Payment APIs use HSM-backed certificates for signing transactions. >> >> 10.j. Auditability >> Certificate Transparency : >> Track certificate issuance and usage via logs, enabling forensic analysis of >> suspicious transactions. >> Example: Audit logs show which certificate initiated a payment at >> 2024-03-05T10:00:00Z. >> Key Considerations about using PKI >> Certificate Revocation : Use CRL or OCSP to revoke compromised certificates. >> Performance : Optimize certificate validation to avoid latency in real-time >> transactions. >> User Experience : Automate certificate issuance (e.g., via mobile app >> integration). >> Key Tools >> Tool >> Purpose >> Keycloak, Zitadel, Gluu or Auth0 >> Identity and access management >> Spring Security >> OAuth2/JWT integration >> OWASP ZAP >> API vulnerability scanning >> HashiCorp Vault >> Secrets management >> Prometheus/Grafana >> Monitoring and alerting >> >> By combining these practices, tools, technologies we ensure a secure, >> user-friendly self-service API architecture but if we focus our efforts on >> this the innovation on financial products could be slower. >> >> Regards >> >> Victor Romero >> >> P.S 1. Maybe it is time to look at post-quantum cryptography (PQC) >> algorithms (NIST has some references) for the Apache Fineract itself. >> P.S. 2. By the way this text is a part of a long detailed architecture for >> Self Service APIs. >> P.S. 3. I encourage all of you to start looking at the PRs and Jira ticker >> and help us with improvements, reading the tickets, code will help to have a >> good understanding about the project :) >> P.S. 4. The Apache Fineract source code is as secure as its weakest line of >> code. >> P.S. 5. Tools and purpose are broader.... >> >> El jue, 13 mar 2025 a las 22:09, James Dailey (<[email protected] >> <mailto:[email protected]>>) escribió: >>> All - >>> >>> To be clear, the design concerns about the existing Self Service component >>> have existed from before it came over from MifosX to Fineract, so this is a >>> long standing problem. The design suffers from simply being the wrong >>> technical approach, but the concept of "self service" whereby the end-user >>> gains access to the backend for authenticated and authorized activities is >>> - of course - a key functionality. >>> >>> In the near very near term, our intention at the PMC is to address some >>> security model concerns (being non-specific here) and then to figure out >>> the right kind of component going forward. We should not rule out a >>> separate component at the Apache Fineract community to handle this >>> functionality. I think we actually should consider different design >>> options. >>> >>> Mifos has offered and I think Ed just mentioned it for the first time >>> publicly on this list, to build a "stand in" for the existing functionality >>> that currently sits inside the fineract authorization model. This will >>> hopefully address some short term concerns. I will leave it to them to >>> explain their approach else-thread. >>> >>> In the Apache approach, mifos is a vendor bundling up their solution on top >>> of the fineract project. I mention this because really any vendor is >>> welcome to attempt what Mifos is doing and offer that to the community of >>> users or to bring a proposal of the same to Fineract. I would argue that >>> for the reasons articulated around open banking, that we will need to >>> address the architectural elements of this set of functionality in the >>> longer term within the fineract project, but I think people should vote >>> with their feet. >>> >>> I'll also use this as a plug for getting involved in the project, >>> particularly if you have API security framework or open banking expertise. >>> Or to be involved in the Fineract Security team. There's a lot to do on >>> this front. We're not giving up on "self service" we just need to address >>> it in phases. >>> >>> Thank you, >>> James >>>
