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
>
>
