The tale of how the ICD connected to the OBI (and what does OpenAPI have to do with it)
From this it becomes clear why the Central Bank sees OpenAPI as the future standard in the industry. Banks use different solutions, and the new specification will make it possible to switch to a single standard, according to which it will be convenient for everyone to exchange information. The “openness” of the solution in this case will not be a problem, but rather, on the contrary, contributes to the speedy closing of vulnerabilities.
OpenAPI in the future should become not just a standard, but a whole philosophy based on unification. It will allow the use of general legal regulations and test certification regulations. The key benefit for banks will be a reduction in value, both in terms of time to develop a solution, and in terms of ensuring quality and security.
Why can’t you just take it and do it
When you want to deploy a complex information system within an organization, there are several ways you can go. The first way is internal development. To do this, you can use either employees with the necessary competencies, or invite new specialists. But a state that expands without limits is not the smartest business model. Endlessly transferring employees from a project where they already work to something new will also fail. And, although we all love new challenges, sometimes we need to recognize that development should not come at the expense of strategic goals. Therefore, there is a second way.
It is more flexible and involves hiring an integrator team. On the market, you can find professionals who have already succeeded in solving a specific problem or have experience in related areas. We took this path by placing an application for the implementation of an OpenAPI-based solution that would allow us to join the OBI environment of the Bank of Russia. The company responded eKassirsoftware developer for banks and credit organizations.
What did eKassir offer?
eKassir was the only company that offered us a ready-made “boxed” solution. Such software is usually “cut in place” to meet the needs of the customer, but frees you from the need to go into custom development. Pros of the solution: run-in on other projects and cost. Their full product is called eKassir OpenAPI Adapter.
This software supports the Security Standard STO BR FAPI.SEC-1.6-2020 Bank of Russia, as well as two applied standards: “Open banking interfaces. Obtaining information about a client’s account by a third party” and “Open banking interfaces. In addition, the same solution is used as the authorization server of the Open API Adapter as in the certification stand of the FinTech Association – eKassir Access Manager.
OpenAPI Adapter has been carefully evaluated by internal and external experts. We were more than satisfied with the results of the audit.
You can’t easily pull out Docker in Kubernetes
The pilot project started in March 2022. According to the plan, by May 31, all the components of the OpenAPI Adapter should have been introduced into the infrastructure of the MKB, and the bank should have successfully passed certification at the stand of the FinTech Association. All work can be conditionally divided into 3 stages: prototype assembly, implementation, final testing and certification at the stand.
The first stage: we collect a working config at the contractor’s booth
There was no point in starting work right away at the MKB stands: firstly, it was not so easy for a third-party developer to start doing something inside the bank’s circuit, and secondly, this did not carry any semantic load. All the “rough” work could be done on their servers. The infrastructure at the same time had to emulate the ICD. To do this, eKassir used the API platform Postman.
After the preparatory work was completed, the solution was submitted for internal audit, and then problems were revealed: vulnerabilities were discovered in several .NET and JavaScript libraries used in the OpenAPI Adapter. This happened due to the fact that several months passed between the launch of the certification stand of the Fintech Association and the pilot project in the ICD, during which the OpenAPI standard managed to change. He also now required a transition to the Secure SDLC software development process. In short, it is a methodology aimed at producing software that is safe from hacks. According to this methodology, finding a bug at the development stage will cost several times less than fixing a vulnerability after the release. It also took time to adjust our processes to the new requirements.
Stage two: the container ship arrives at the port
A problem that was not given sufficient attention at the start was revealed. The eKassir team handed over the configured Docker containers to colleagues from the MKB, but that’s bad luck: Kubernetes was already used in the MKB. It took time to adapt different containerization environments to each other, but in the end the task was solved, although some of the configuration settings were lost.
After unpacking the containers, it was necessary to work a little more with the network infrastructure: set up a proxy, issue certificates, and finish setting up cryptography. The timing of the pilot project, you guessed it, had to be extended.
Stage three: knock on the test stand, hear knocks in response
So, after setting up everything that was included in the solution package, we had to pass tests at the certification stand of the FinTech Association (AFT). It is built on the basis of the “Access Manager” solution from the eKassir vendor and is part of the AFT technology sandbox. The stand is needed in order to test banking open APIs and applications for compliance with the standards of the Central Bank of the Russian Federation. Access to this booth is given to all organizations that have joined the “observance of OBI standards agreement”.
The “sandbox” module consists of 2 parts: “sandbox 0” and “sandbox”. The first part can be accessed by any organization that has registered on the OBI portal. There you can test APIs and applications with a limited set of scenarios without checking information security settings. Access to the second part is given only to organizations that have signed an agreement “on observance of OBI standards”.
For data protection, the standard suggests the use of OIDC for identification and authentication, a compact format for passing claims between JWT parties, and a cryptographic protocol for mutual authentication. mTLSwhich allows the client and server side to verify each other’s certificates.
When passing tests for to the standard of the Bank of Russia STO BR FAPI.SEK-1.6-2020 we had problems due to incorrect settings mTLS. The protocol itself did not cause difficulties, but the configuration of the associated WAF required adjustments. eKassir experts quickly clarified all the nuances and mTLS worked as expected.
To pass the official testing procedure, you must send a request to the FinTech Association through the bank account on the website openbankingrussia.ru. After that, a time window of 7 days will be opened, during which it is necessary to complete all tests with logging the result. When testing in the “combat” module, scenarios similar to real life occur, that is, both positive and negative. OpenAPI Adapter successfully coped in just 2 hours, while without it testing takes from 1 to 7 days.
What’s under the hood of the OpenAPI Adapter
In the previous sections, we referred to a whole layer of various regulatory documents, technologies, protocols, and so on. Now let’s show how the security mechanisms of OpenAPI work.
The basic thing is that services inside the infrastructure cannot constantly communicate over complex protocols with permanent authentication. Agree, it would be strange if you locked every room in your apartment with a key – you have a good front door and walls to protect against thieves. For the eKassir OpenAPI adapter, such a door is two Identity Gateways (IG), which act as an API Gateway. All this pile of words acts as a gateway that separates the external network from the Intranet (INT), the local network.
One IG is located in the network segment DMZ. This segment is available for calls from both the Internet and the Intranet. It serves as a kind of buffer zone – let’s consider it a dressing room in our metaphor, an additional security line. IG INT communicates with him from the local network. The connection was initiated from a trusted zone using the protocol WSS and always open.
The Identity Gateway enriches the account access application API with the consent resource information and sends the enriched request to the Account Service. IG performs the work of FAPI.SEC, including binding the transport certificate to the access token, checking for idempotency, validating the digital signature of the application request body, and so on.
Now IBC is a member of the OBI
As you already understood, the project was successfully completed. MKB became a full-fledged participant in the OBI environment as a payment service provider for the scenario “Obtaining information about a client’s account by a third party” and gained experience in working with a security standard FAPI.SEC-1.6-2020.
On the one hand, we did not meet the initial deadlines. But, as with any integration, and even more so with the banking regulator, this was to be expected. We solved the problems promptly, and the only thing that could be foreseen was the inconsistency of the contractor’s containerization mechanism with that adopted at the bank.
OpenAPI Adapter proved to be an excellent tool for solving a specific problem in a clear timeframe. Perhaps there is a way to optimize something specifically for us or write a completely custom application, but the speed of development and implementation would definitely be lower. We didn’t find any pitfalls, the solution passed a strict audit: there is no other way in banks. I will be glad to know your opinion about the implemented solution and discuss alternative scenarios in the comments.
