Open Banking Conformance Testing
Ping Identity Passed with Zero Warnings or Errors
The PSD2 directive in Europe is requiring financial institutions to open their APIs to allow access by third-party providers. In the UK, the Competition and Markets Authority (CMA) has specified the use of OpenID Connect and OAuth 2.0 to secure API access via the Open Banking Security Profile.
In order to ensure interoperability between parties in the Open Banking ecosystem, Account Servicing Payment Service Providers (ASPSPs), including banks and building societies, must comply with the Open Banking Security Profile. To test and certify conformance, ASPSPs should follow the Open Banking Conformance Certification Process. As part of the process, ASPSPs have to run a set of tests defined by the Open Banking OIDC Conformance Suite and submit the results to Open Banking Ltd, formally the Open Banking Implementation Entity (OBIE), for certification.
ASPSPs can comply with the Open Banking Security Profile via the Ping Identity identity and access management (IAM) platform, which has recently passed the Open Banking Conformance testing. In this blog post, I will describe the Ping Identity PSD2 reference architecture used to run the tests, and I will briefly describe the certification process and comment on the results of the testing.
PSD2 Reference Architecture
To test conformance, Ping Identity has deployed a reference environment, connected to the Open Banking Directory (a trusted third-party register that runs on the Ping Identity Platform) and to the Conformance Test Suite. The logical architecture is depicted below and a description of the Ping components and their interactions follows.
- PingAccess: Ping Identity access gateway used to securely expose the Open Banking APIs (via MTLS), the token endpoints (via MTLS), the authorization dashboard and the OIDC endpoints. All the calls made by the Conformance Testing Suite to the APIs and to the token endpoints will go through PingAccess and will be validated by the PingAccess access policies.
- PingFederate: the components work as the OIDC provider and OAuth authorization server. It is responsible for:
- issuing OAuth and OIDC tokens to the end user
- issuing OAuth tokens to the Conformance Testing Suite
- exposing the client registration APIs (not used by the Conformance Testing Suite)
- orchestrating the user authentication journeys (first factor and Strong Customer Authentication)
- exposing the OIDC well-known endpoints that are tested by the Conformance Testing Suite
- connecting to the Open Banking directory to download the keys used to validate the JWTs sent by the Conformance Testing Suite
- PingDirectory: high performance directory used to:
- expose the Authorization API used by the Authorization module
- store the following data:
- End user identity data and accounts
- End user authorization data
- OAuth client data. In this case, the OAuth client data used by the Conformance Testing Suite to run the flows and to simulate TPPs.
- PingID: cloud-based multi-factor authentication (MFA) and transaction authorization solution. Integrated with PingFederate, this is used in PSD2 scenarios for compliant Strong Customer Authentication (SCA).
- Authorization Module: custom web application used to gather user authorization before issuing tokens and to enable end users to centrally manage and revoke previous authorizations given via an Authorization Dashboard. It uses the Directory Authorization APIs to store and manage fine-grained authorization in PingDirectory, and it is protected via PingAccess to ensure that only authenticated users can access the authorization dashboard.
- Open Banking APIs: sample implementation of conformant Open Banking APIs, used to deliver payment and account aggregation use cases. The testing suite calls a subset of the APIs to simulate an account aggregation flow and test all the security aspects.
Running the tests
In order to be able to submit the test results to Open Banking for conformance, the hosted Conformance Testing Suite must be used. The configuration steps needed to run the tests are briefly described below:
- Register the test ASPSP with the Open Banking Directory and obtain the network and signing certificates that will be used in the Ping reference architecture to configure the ASPSP side.
- Register a test TPP against the Open Banking Directory and obtain the network and signing certificates that will be used to configure the Conformance Testing Suite to simulate the TPP behavior.
- Deploy into the Ping software platform (on the ASPSP side) the certificates obtained in 1. and configure the jwks_uri parameter in the OpenID Connect well-known endpoint to reference the public keys hosted by Open Banking for our environment.
- Create in the Ping platform the OAuth clients that will be used by the Conformance Testing Suite to run the tests. To pass the tests with all the client authentication methods supported, we created six OAuth clients (two clients for each authentication method - to enable the Conformance Testing Suite to test against tokens swaps) with the following characteristics:
- Client Secret: this client shares an ID and Secret with the Conformance Testing Suite in order to enable testing of client secret basic and client secret post, both over a mutually authenticated channel.
- MTLS: this client is configured to validate the authentication certificate presented by the Conformance Testing Suite, which is obtained from the registration carried out in 2.
- Private key JWT: this client is configured to receive a private key JWT from the Conformance Testing Suite and to validate the signature of the JWT with a public key hosted by the Open Banking Directory.
- All the clients are configured:
- to enforce OIDC request object validation with a jwks endpoint hosted by Open Banking and associated to the client defined in 2.
- with a redirect URI that points to the hosted Conformance Testing Suite for those tests that require a redirect to the OP.
- configure, by providing JSON configuration files (described here), the various test plans on the Conformance Testing Suite. For our environment we configured all the available Open Banking test plans, as depicted below:
Once the above configurations are complete, both the ASPSP and the Conformance Testing Suite are ready. An end user can now run individually the test plans; some of the tests will not require any user interactions, whereas others will require interactions like authentication at the ASPSP site and screenshot uploads with relevant error messages from the ASPSP.
Open Banking UK certification
Once the test plans are run, logs of the tests can be gathered and submitted to the Open Banking Implementation Entity. Results are inspected and the certification result is published on the Open Banking Security Profile Conformance page.
The following screenshot shows the certification of our reference implementation, which at the time of writing is the only implementation to have passed the latest version of the Conformance Testing Suite (v2.0.2) and to have certified against all the available client authentication methods and response types.
The software components of the Ping Platform used to obtain the certification are:
- PingFederate 9.1.1
- PingAccess 5.0.3
- PingDirectory 6.0.1
For more information on how Ping Identity can address the technical challenges of securing access to Open Banking APIs, watch the Open Banking Solution Architecture video or visit www.pingidentity.com/psd2.