On 14th December 2017, Federico Carbone, Regional Solutions Architect at Ping Identity, ran a live demonstration webinar showing how the Ping Identity Platform addresses the technical challenges of securing access through open APIs to process financial information and transactions. (Click here to watch the replay.)
Federico presented both the Payment Initiation Service Provider (PISP) and Account Information Service Provider (AISP) use cases, showing how the Ping Identity Platform:
- Utilises OAuth 2 and OpenID Connect token services to support financial institutions and third parties to complete a direct payment transaction and account information aggregation.
- Gathers, manages and enforces customer-driven consent.
- Enforces Strong Customer Authentication (SCA).
The components of the architecture demonstrated during the webinar are as follows:
Ping Identity Components
- PingFederate (deployed at AnyBank): the OpenID connect provider, responsible for customer authentication and token issuance.
- PingAccess (deployed at AnyBank): API access control gateway, deployed in front of the payment and account information API to validate tokens and enforce consent.
- PingDirectory (deployed at AnyBank): directory used to store user accounts, OAuth client data and consent data.
- PingDataGovernance (deployed at AnyBank): connected to the directory, this component is used to manage the directory data via a SCIM API.
- PingID (provided as a Service): multi-factor authentication (MFA) solution used for strong customer authentication for the payment use case.
- Authorization Module (deployed at AnyBank): custom module used to present to end users the authorisation pages (for the payment and account information use cases).
- AnyCharity: sample PISP application developed to demonstrate a payment use case (to complete a direct payment with AnyBank).
- AnyMoneyManagement: sample AISP application developed to demonstrate the account information use case (to aggregate transaction data from multiple accounts).
- Payment APIs: sample implementation of the payment API as defined by the Open Banking UK specification.
- Account APIs: sample implementation of the account information API as defined by the Open Banking UK specification.
- Open Banking UK Directory: Directory hosted by Open Banking that acts as the trusted authority by all the parties in the ecosystem.
During the webinar, Federico fielded a number of questions. To follow are many of these with their corresponding answers. I've also included frequently asked questions and answers to enhance your understanding of how the Ping Identity Platform solves for PSD2 and Open Banking.
Q. What does Ping propose to ASPSPs to secure access?
A: In general, Ping Identity proposes the following components of the Ping Identity Platform:
The components are loosely coupled and can be used together or with equivalent third-party solutions. For example, some Ping customers have decided to deploy the full software stack mentioned above and others have replaced PingAccess with existing API gateways.
Q: Where is the SCA step up defined (in which policy)?
A: Strong customer authentication is defined in a PingFederate authentication policy that evaluates the requested scope. When a third-party provider (TPP) needs to complete a payment on behalf of the user, the TPP requests an OAuth access token with the "payment" scope. The authentication policy evaluates the requested scopes and enforces the PingID strong authentication.
Q: Is PingAccess an API gateway? If yes, what is the delivery model? Cloud, in-house?
A: PingAccess is an access control solution that can be used to protect rest APIs and web applications. Being an access control solution, it provides powerful access control policies but does not provide the API lifecycle management that an API gateway typically provides. It's provided as "software," which means that customers acquire the software component and deploy it either in their private data center or in cloud data centers. PingAccess is not provided as a service presently.
Q: Do I understand correctly that the consent has to be given separately for a payment and an AnyMoneyManagement analysis request? Or does AnyMoneyManagement consent have to be pre-given separately?
A: Yes, consent/authorisation has to be given separately for payments and for account information transactions. Currently, the Open Banking UK specification does not support recurring payments, therefore consent/authorisation must be given for every payment, whereas the consent/authorisation given for account information can be reused over time.
Q: AnyCharity accesses PingFederate directly to initiate the transaction. Shouldn't the TPP be accessing PingFederate through PingAccess?
A: PingFederate is designed to be exposed directly to end users and clients or to be exposed via PingAccess. Both models are supported and adopted. In the current demo environment, PingFederate is directly exposed (technically, it sits behind an Apache reverse proxy to simulate MTLS termination typically carried out with network devices). In future versions of the demo, we will most likely expose PingFederate via PingAccess to be able to enforce access policies on the token requests carried out by the TPPs.
Q: Will the PISP need certificates for two-way TLS when connecting to PingAccess? Or will the authentication of the PISP be done solely by the mentioned token?
A: MTLS 1.2 is mandatory. The Open Banking UK Security Profile (section 6) states, "The resource server with the FAPI endpoints:
- shall mandate mutually authenticated TLS 1.2 or later as defined in RFC5246 with the usage following the best practice in RFC7525;
- shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to."
Q: Is it possible for the AISP or PISP to be intermediaries/aggregators for other third parties that essentially collate the data from people and then share this (with user consent) with other third parties so those third parties only need one integration?
A: Our understanding is that this is possible. Chapter 6 of the Open Banking UK Consent Model Guidelines provides some details of how to manage consent when multiple TPPs are involved.
Q: How will recurring payments work?
A: Recurring payments are not supported in the first release of the UK's Open Banking Standard, but our understanding is that recurring payments will be supported in the future. We expect that the flow will be very similar to the current account information use cases where TPPs obtain an access token and a refresh token, and can use the refresh token to obtain fresh access tokens and complete multiple payments.
Q: How is the consent management authorised to access the AISP/PISP APIs? Is it using an SSO token of PingFederate?
A: The consent management application does not access the TPP APIs. During authorisation, the user is redirected to the ASPSP, and the consent management application stores the authorisation in PingDirectory. When a user revokes the authorisation, the authorisation application deletes the authorisation from PingDirectory. The presence of valid authorisation is checked by PingAccess when the TPP calls the APIs. If the authorisation is not valid, PingAccess denies access, and the TPP should react to that. Our understanding is that ASPSPs are not obliged to communicate to TPPs that authorisation was revoked. This might change in the future, but nothing has been standardised for now.
Q: Is the authorisation module part of the authentication journey, like an authentication adapter chaining?
A: Yes. The redirection to the authorisation module happens before the user tokens are issued to the TPP. Within PingFederate, this happens via an authentication policy that chains first factor authentication, strong customer authentication and a redirection to the authorisation module via the "reference ID adapter." The adapter redirects the user to the authorisation module with a reference value. The authorisation module then makes a back channel API call to PingFederate, passing the reference value to obtain the necessary data around the transaction. The authorisation module displays the data to the user, gets the authorisation, makes a back channel API call to PingFederate to confirm the authorisation and finally redirects the user back to PingFederate.
Q: On the authentication for different TPPs, can they share the session context, so an exemption can happen for a second TPP?
A: Our understanding is that there is nothing in the PSD2/Open Banking UK specification that prevents a bank from sharing the session context among different TPPs. The demo currently allows for this session sharing, but the behaviour can be easily modified via configurations of the session. The session could be global (as it is now), per TPP or no session at all.
Q: How is identity management used here? Is PingDataGovernance used for it?
A: PingDataGovernance is used to manage the consent in the directory (to store and update consent records). It exposes a SCIM API that allows the authorisation module to create and delete consent records in the directory. In the demo, PingDataGovernance is not used to manage the identity of the users, but in general it can. Also, in this case, PingDataGovernance would expose a SCIM API to manage the identity records in the directory.
Q: Is there any threat detection mechanism involved in the PISP use case?
A: This is not included in the demo at the moment. Ping Identity has technology partnerships with third-party vendors to include threat detection controls when users are authenticated and authorised.
Q: Strong customer authentication was not used to confirm consent for AnyMoneyManagement. Is that compliant?
A: Our understanding is that SCA is mandatory for payment use cases. ASPSPs can define whether they want to enforce strong customer authentication for account information use cases. In PingFederate, this behaviour can be configured via authentication policies.
Q: Does the Ping Identity Platform cover transaction monitoring and signs of malware in an authentication session?
A: We provide these capabilities via integration with third-party vendors.
Q: Does Ping Identity handle SCA exemptions?
A: Strong customer authentication exemptions are supported via authentication policies. For example, policies can look at the amount of the transaction to decide whether to trigger SCA. PingFederate can also integrate with external transaction risk analysis tools in order to request an evaluation of the risk of the transaction. Based on the outcome, it can enforce SCA. PingFederate could also, for example, look up a list of trusted beneficiaries and not enforce SCA.
Q: Does PingID utilize RASP (Runtime Application Self-Protection Security)?
A: Although RASP is not implemented, many other security controls are part of the PingID application. Customers under NDA can have access to the PingID security guide, which describes all the controls and protections in place.
Q: Can the first factor authentication be delegated to an existing authentication application?
A: Yes, PingFederate can redirect a user to an external authentication application. The redirection to the authentication application would happen via a standard OIDC transaction or via the "reference ID adapter." The adapter redirects the user to the authentication application with a reference value. The authentication application makes a back channel API call to PingFederate, passing the reference value to obtain the necessary data around the transaction. The authentication application authenticates the user, makes a back channel API call to PingFederate to confirm that the authentication was successful and finally redirects the user back to PingFederate.
Q: Can the authorisation be externalised to a business application managed by the ASPSP?
A: Yes, the authorisation can be externalised via custom rules defined in PingAccess. Custom rules can be created via the Java SDK or via Groovy scripts. The rule is triggered by PingAccess when the TPP makes a call to the protected APIs and receives from PingAccess:
- the information about the resource being accessed
- all the attributes attached to the OAuth access token (e.g., intent id, scopes, user identity, etc.)
- context information (e.g., the authentication method used, the source address of the user, etc.)
It can then make a call to an API exposed by the business application. Depending on the result of this call, PingAccess can allow access, deny access or request a stronger authentication.
Q: Can you explain how the TPP should request a token to the ASPSP?
A: TPPs need to first register an intent with the bank (payment or account information) via an API call and obtain an intent ID from the call. At this point, the TPP needs to create a signed JWT that includes the intent ID and starts an OpenID connect flow with the ASPSP passing the JWT just created. The JWT is named request object and is defined in section 6 of the OpenID Connect specification.
Q: How do I get started? Is there a startup guide or tutorial?
A: Visit www.pingidentity.com/psd2 for a wealth of material, including an in-depth PSD2 and Open Banking solution guide. Also subscribe to our blog to receive our forthcoming "how to" articles, which will provide all the details you need to get started.