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 <
victor.rom...@fintecheando.mx> 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
>
> 1.
>
> Step-Up Authentication :
> -
>
> Require OTP for sensitive actions (e.g., changing passwords or
> transferring funds).
> 2.
>
> Secure OTP Storage :
> -
>
> Store OTPs in encrypted form (e.g., AES-256) and expire after 5
> minutes (or less).
> 3.
>
> 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 (<jdai...@apache.org>)
> 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
>>
>>
