Quickstart Private Sandbox for

Open Banking & PSD2

In a previous blog post, I described how the Ping Identity IAM platform was used to pass the Open Banking Security Profile conformance testing. In order to help banks accelerate and simplify the deployment of an environment that conforms with the OB Security Profile, Ping Identity has developed a Quickstart Private Sandbox for Open Banking & PSD2.

Set up a private PSD2 & Open Banking test environment in minutes

Ping Identity has automated the production of a fully working test environment for PSD2 & Open Banking conformance on your own virtual machine—not just a hosted one. We give your bank the automated scripts (built in conjunction with PSD2 Enabler, and based on Vagrant and Ansible) to build your own private sandbox that allows your team to be in charge of your own testing environment. The automation script takes Ping Identity software and sample APIs and deploys it all in a test environment of your choice, ready to demonstrate payments and account aggregation use cases.

Keep control of your sandbox

Essentially, if you give us a virtual machine, we're ready to give you a sandbox. It would have been a lot easier to just spin up a test environment in the cloud and expect banks to pay a visit to a hosted multi-tenant sandbox environment. But we realized that to get this into the hands of identity and access management (IAM) and security professionals at the largest enterprise banks, it’s important to go beyond a one-size-fits-all solution. Our Quickstart Private Sandbox provides banks a better way to achieve realistic, hands-on testing for the magnitude, type and and scale of transactions at your specific bank.

A sandbox that’s actually useful

We chose this scripted delivery method so that you not only have more hands-on control, but also because it is entirely possible that you may want to reconfigure this sandbox and eventually enable it for production use. After you have fully demonstrated the working solution, examined your connections to existing customer directories, and built your own FAPI-conformant APIs for accounts and payments, our best estimate is that it would only take a few days to hook the sandbox into your actual environment. In an ideal world, within a few weeks the system could be moved into production, and even accounting for the challenges of change management, a few months is within grasp for most committed teams.

In this blog post, I will describe the automation scripts and how these can be used to deploy the Ping Reference architecture.

The reference architecture

In order to quickly deploy a fully working environment and enable payment and account aggregation use cases, the automation scripts deploy:

1. the Ping Identity IAM Stack: PingAccess, PingFederate, PingDirectory and PingID, correctly configured to test the use cases and in a conformant way
2. a sample PISP e-commerce web site, named Limitless Ambition
3. a sample AISP money management web site called Unify
4. a sample implementation of the account aggregation and payment API

The logical architecture is depicted below:

For a description of the components and their role in the architecture, please refer to the Conformance Testing blog.

A Script to Accelerate Sandbox Deployment

The automation script is designed to deploy the PSD2 reference architecture to a single Linux machine or to multiple machines, depending on how it is configured. For local testing, the script can also be configured to start the virtual machines in a local environment using VirtualBox. In the rest of this blog, I will describe the local testing scenario with all the software components deployed on a single local machine created in VirtualBox.

The script relies on Vagrant to spin up the virtual machines and on Ansible to deploy and configure the software.

The scripts assume that:

• the Ping software, the sample APIs and the sample applications are provided in a folder on the machine used to run the script (the “control node”)
• the correct certificates are available on the control node
• the Ping license files are available on the control node
• the Ansible configuration properties (fully qualified domain names, certificates, etc.) are set in the control node

The script does the following:

1. It creates one or more virtual machines in VirtualBox to host the software.
2. It installs basic operating system utilities and Java to enable the Ping software to run.
3. It installs Tomcat and deploys the sample web applications (PISP and AISP), the sample Open Banking APIs and the Authorization Module.
4. It deploys PingFederate and configures:
   • first-factor authentication against PingDirectory
   • second-factor authentication with PingID and the authentication policies that determine when to step up authentication
   • the OAuth clients for the two sample applications
   • the OpenID Connect policies
   • the integration with PingAccess
5. It deploys PingAccess and configures:
   • the integration with PingFederate
   • the integration with the account aggregation and payment API and the necessary authorization policies
   • mutual TLS with the sample applications
   • the integration with the authorization dashboard
6. It deploys PingDirectory and creates sample users in the directory to test the use cases.
    

Running the script

Once the environment properties are configured in the Ansible configuration properties file, and the local host file DNS entries are updated, a simple vagrant up command on the control node starts the deployment. For a local deployment, a virtual machine in Virtual Box is created and a fully working Open Banking demo environment is deployed and ready to demonstrate payment and account aggregation use cases.

The following screenshot shows the start of the provisioning process, with the deployment of an Ubuntu machine in VirtualBox.

The next screenshot shows the end of the automatic configuration process, with the script completing the PingAccess configurations and providing information on how to access the demo applications and the management console of PingAccess, PingFederate and PingDirectory.

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.