Banfico had meetings with many of the financial institutions in KSA on the Open Banking implementation in accordance with SAMA mandates. Banfico found many financial institutions leveraged IBM API Connect (APIC) using the standard OIDC Provider and deployed APIs based on the Open Banking UK Standards. These deployments also worked well in the ecosystem with partner fintechs (TPPs). Banks felt confident that they are ready for the Saudi Open Banking implementation.
However, with the publication of Open Banking Framework (OBF) by SAMA, the APIC-based implementation was not compliant with FAPI security standards and didn’t cater for various authorisation methods like web redirect, app-to-app redirect and decoupled redirect using QR code.
This article sheds light on the preparedness of Open Banking delivery using IBM API Connect.
KSA Open Banking Framework
SAMA has mandated the below security standards for the Open Banking implementation
Note: In future, FAPI 2 is likely to be mandated by SAMA. Only a handful of vendors have so far invested resources in building the FAPI–grade authorisation server.
IBM API Connect (APIC)
APIC comes with the below components
- Management System – Administer the APIs, Products, Organisations, Catalogues
- Analytics – collects metrics and produces reports on the API usage
- Developer Portal – Includes both backend and frontend components. The Frontend is Drupal based Content Management System. This is ok to be customised for simpler needs.
- API Gateway (DataPower) – gateway with high performance
APIC is not FAPI Certified
APIC supports standard OAuth2.0 and OpenID Connect. DataPower works well as the standard OIDC Resource server. However, despite strong demand for industry standards, IBM API Connect has failed to get FAPI/CIBA certification according to the OpenID Foundation certification page.
IBM recommends integrating IBM Security Verify Access (ISVA) with APIC for FAPI conformance. However, Banfico would highly recommend RedHat Keycloak because of the strong community support to develop modern security protocols.
IBM Security Verify Access (ISVA)
Let’s consider the below for our discussion
- IBM Application Gateway (IAG) – a reverse proxy or gateway to protect web/API resources
- IBM Security Verify Access (ISVA) – OpenID Connect Provider (Identity Provider) for the IAG
ISVA is FAPI Certified
ISVA has been FAPI certified to support MTLS, Private Key with Pushed Authorisation Request (PAR) support. It is still missing support for FAPI 1.0 Advanced profiles like JWT-Secured Authorisation Response Mode (JARM) in its certification.
Integrating IBM Security Verify Access with IBM API Connect
IBM revamped IBM Security Access Manager (ISAM) into IBM Security Verify Access (ISVA), which has obtained OpenID FAPI Certification. But the integration between ISVA and APIC has its limitation which needs to be overcome by custom development. We need to bear in mind that APIC supports external Identity Providers (IdP) to complete user authentication but not external Authorisation Servers!
APIC Developer Portal module has not demonstrated out-of-the-box integration with external OIDC Providers like IBM Security Verify Access. The OAuth clients of the ISVA need to be synchronised with IBM APIC and its product subscriptions.
We have seen the deployments which don’t use the Drupal frontend of the APIC Developer Portal while still being able to use the Developer Portal Backend service. This seems to be moderately complex.
The other option of using the APIC Developer Portal Frontend and customising the Developer Portal Backend Service is a little more complex without expert advice from IBM. The maintenance of this customisation is expensive when upgrading across APIC versions.
In terms of enterprise architecture, this is a bit convoluted because, when TPP Clients are provisioned, APIC takes the master role but when TPP Clients are authenticated, ISVA takes the master role. Ideally, all Identity and Access Management responsibilities should be taken over by the ISVA. Please refer to our blog on “Separation of concerns – IAM and APIM” we produced in 2018 during the early European PSD2 Implementation phase.
Deployment
Deploying APIC and ISVA is again redundant in certain aspects and needs to be managed with bespoke customisation.
- There are two gateways – ISVA’s web proxy is FAPI compliant and is expected to do the MTLS termination. However, DataPower is also an API Gateway which does the Product/Subscription validation in addition to the API Analytics capture. The API traffic is expected to pass through both gateways. Questions remain on which order to deploy these gateways in DMZ / Public Subnet. If the organisation also considers the WAF gateway, should it be deployed before the MTLS termination or after ISVA? What about traffic to non-open-banking applications using the same APIC? All these need to be well thought out.
- There are 2 instances of TPP Developer Application persistence – one in ISVA as FAPI compliant OAuth2 client and the other in APIC Developer Portal Service as developer apps. Making sure the synchronisation is maintained is an overhead and needs customisation.
Typically, IBM software deployments come with their own complexity in terms of hardware requirements, migration across versions, automation, DR plan and supporting customisation.
What should an organisation do to overcome the limitations of APIC in Open Banking
- Choose an external OIDC Provider to achieve FAPI Conformance – e.g., RedHat Keycloak, IBM Security Verify Access, Authlete, Curity AB, Ping Identity
- Choice of these requires customer reference to existing production deployment in another financial institution & that their deployment is FAPI certified. Building the integration for the first time is a high delivery risk.
- The same authorisation server should also be leveraged to handle customer authentication with existing Identity Providers inside the bank. Such integration is also a key aspect to open banking delivery and is likely to be one of the high risks to the project.
- Consider an out-of-the-box solution from vendors like Banfico.
- Our solution is fully compliant with KSA Open Banking Framework including FAPI/CIBA
- Our solution’s IAM capability can readily integrate with the bank’s identity provider (IdP)
Banfico’s APIC experience in Open Banking
Banfico has deployed in production APIC in major banks along with external Authorisation Servers such as RedHat Keycloak and Ping Identity PingFederate in the Open Banking implementations. Some of these banks are large financial institutions based in the Middle East.
Separately Banfico developed the OB API Platform using RedHat Keycloak and Nginx-OpenResty API Gateway (without the use of APIC). Banfico is also an open-source contributor to building FAPI standards into Keycloak since 2019 along with well-respected enterprise solution providers.
Recommendation
Financial institutions in KSA should consider Banfico’s out-of-the-box solution to meet the imminent regulatory deadline. Our typical timeline for delivery is around 4-6 weeks in a SaaS setup. Btw, Banfico can support replacing its API Gateway with IBM API Connect in future.
Open Banking mandates from SAMA also cover more than FAPI Conformance and require the financial institutions to meet various other requirements, which is offered readily by Banfico solution – a one-stop to OB Compliance.