technical solution guide - ping identity · psd2 & open banking technical solution guide 4 1...

PSD2 & OPEN BANKINGTECHNICAL SOLUTION GUIDE

PSD2 & Open Banking Technical Solution Guide 2

Table of Contents

INTRODUCTION

OPEN BANKING REFERENCE ARCHITECTURE

CONFIGURATION OVERVIEW

CONFIGURATION DETAILS

Prerequisites

Basic Configurations

Customer Authentication (CA & SCA) Configurations

API Gateway Security Configuration

Consent Authorization Integration

TPP Clients Configurations

APPENDIX A: PINGFEDERATE POLICY TREE

Authentication Policy: OB Payment Authn Policy

Authentication Policy: OB Account Authn Policy

APPENDIX B: USING THE PINGDIRECTORY CONSENT RESTFUL API

APPENDIX C: USING THE PINGFEDERATE RESTFUL API TO REVOKE GRANTS LINKED TO OPEN BANKING INTENT ID

Access Grant Lookup and Revocation

03

03

06

07

28

30

37


The PSD2 directive in Europe and the Open Banking Standard in the UK are requiring financial institutions to open APIs to allow access

by third-party providers.

In the UK, the Competition and Markets Authority (CMA) has already specified the use of OpenID Connect and OAuth 2.0 to secure API

access via the Open Banking Security Profile. The Open Banking Security Profile defines how Third Party Provider (TPP) applications

shall obtain and use OAuth and OpenID Connect tokens in a secure way, suitable for financial transactions.

The purpose of this guide is to show how Ping Identity enables ASPSPs to comply with the UK Open Banking Specification through

the Ping Identity software platform, via a detailed explanation of how to deploy and configure the solution to obtain a fully conformant

Open Banking Solution. Although the specific configurations described in this document are specific to the Open Banking standard and

needed to pass the conformance testing (Security Profile version v1.1.2 - Suite Version v2.0.2), the Ping Identity reference architecture

described is well suited to address the broader PSD2 landscape, regardless of the specific standard adopted.

The guide is intended for administrators with the following background understanding:

• PingFederate, PingAccess, PingID and PingDirectory administration concepts

• Open Banking, OpenID Connect and OAuth knowledge

The Ping Identity Platform provides four capabilities that can be effectively used to address the PSD2 challenges: single sign-on

(SSO), multi-factor authentication (MFA), access security and directory. In a PSD2 scenario, the platform can:

1. Issue Open Banking conformant tokens based on strong customer authentication and consent.

2. Store identity, policy and consent data necessary to issue properly scoped access tokens to TPPs.

3. Facilitate dynamically linked customer authentication.

4. Securely expose the Open Banking APIs validating the submitted access tokens, supplying necessary identity and scoping

contexts to payments and accounts APIs.

Each of the capabilities corresponds to a software component, as described in the following table, and the components can be

deployed individually or loosely coupled in combination, thanks to the standard-based architecture.

Introduction

Open Banking Reference Architecture


1 This document describes the deployment and configuration of PingID, since the PingID mobile app is publicly available in the Apple Store and Play Store and can be used for quickly testing the Open Banking flows. In a production environment, organizations will most likely want to use the PingID SDK to authorize transactions from their existing mobile apps and to be SCA compliant.

CAPABILITY SOFTWARE COMPONENT

MINIMUM REQUIRED PRODUCT VERSION

Multi-factor Authentication PingID1 NA

Single Sign-on PingFederate 9.1.1

Access Security PingAccess 5.0.0

Directory PingDirectory 7.0.0

The following diagram describes our PSD2 reference architecture, where all the components work to provide an Open Banking

conformant solution.

SCA

Policy Enforcement

Token Validation

Identity Store

Consent Management

Open BankingDirectory

TPPs

Cloud

MTLS HTTP HTTPS LDAPS

Reference Environment (ASPSP)

Authentication Authority

Client Registration

OIDC Provider & OAuth AZ Server

Authorization Gathering

Authorization DashboardAccount API

Payment APIs

Open Banking APIsAUTHORIZATION

MODULE


• 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 end points. All the calls made by TPPs to the APIs

and to the token endpoints will go through PingAccess and will be validated by the PingAccess access policies.

• PingFederate: the component works as the OIDC provider and OAuth authorization server. It is responsible for:

• issuing OAuth and OIDC tokens to end users

• issuing OAuth tokens to TPPs

• exposing the client registration APIs

• orchestrating the user authentication journeys (first factor and Strong Customer Authentication)

• connecting to the Open Banking directory to download the keys used to validate the JWTs sent by TPPs

• 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 (TPP OAuth clients)

• PingID: cloud-based multi-factor authentication 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

• 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.


Configuration Overview

In order to obtain a fully conformant environment, the following configuration tasks (described in detail in the remainder of this

document) must be carried out:

1. Basic configurations:

a. Directory initialization, OAuth storage configuration and Consent storage configuration

b. PingFederate and PingAccess network and signing certificates installation and FAPI ciphers restrictions configurations

c. PingFederate and PingAccess hostnames and virtual hosts configurations

d. PingFederate and PingAccess OIDC & OAuth setup

2. Protected resources configurations:

a. PingAccess is configured to securely expose the following endpoints:

i. Payment and Account Info API

ii. Token Endpoint

iii. Authorization Endpoint

b. PingAccess is also configured to enforce the correct access policies for the APIs and the token endpoint

3. Strong Customer Authentication:

a. PingFederate authentication policies are created to orchestrate the first-factor authentication against PingDirectory and

SCA with PingID

b. PingID is configured to enable transaction authorization via mobile push notifications

4. Authorization configuration

a. PingFederate is configured to redirect the user to the Authorization Module as part of the token issuance process

b. PingAccess is configured to securely expose the Authorization Dashboard

c. The sample Authorization Module is deployed and connected to PingFederate and PingDirectory

5. TPP OAuth clients are configured to enable third-party providers to obtain tokens from PingFederate


We will assume that PingFederate, PingAccess and PingDirectory have already been installed and are running with valid licenses,

as described in the official documentation:

1. PingFederate

2. PingAccess

3. PingDirectory

We will also assume that a PingID account is available and licensed.

The sample Authorization Module and the sample Open Banking APIs will be made available on our GitHub page with the

installation instructions.

Several endpoints must be available and configured in the system DNS to enable TPPs to connect to the APIs and to the OAuth

servers, as well as to enable internal communications. The following DNS entries must be created:

1. Public API endpoint, pointing to the PingAccess server (e.g., api.anybank.com)

2. Public Authorization endpoint, pointing to the PingAccess server (e.g., sso.anybank.com)

3. Public Token endpoint, pointing to the PingAccess server (e.g., token-endpoint.anybank.com)

4. Internal API endpoint, pointing to the API server (e.g., internal-api.anybank.com)

5. Internal Authorization and Token endpoint, pointing to the PingFederate server (e.g., pingfederation.anybank.com)

6. Internal directory (e.g., directory.anybank.com)

In order to be part of the Open Banking ecosystem, ASPSPs need to register against the Open Banking UK directory and obtain

signing and network certificates. Throughout this guide we will assume that the registration has been carried out, as described

in the Open Banking website, and that network and signing certificates are available.

PREREQUISITESSOFTWARE INSTALLATION

DNS CONFIGURATIONS

OPEN BANKING DIRECTORY REGISTRATION

Configuration Details

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#gettingStartedGuide/concept/installation.html

https://docs.pingidentity.com/bundle/pa_sm_InstallPingAccess_pa51/page/pa_c_InstallPA.html

https://documentation.pingidentity.com/pingdirectory/7.0/adminguide/index.shtml#adminguide/install/concept/installingtheserver.html

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/37749198/Open+Banking+Directory+Usage+Live+Proving+-+Draft


After installation, PingDirectory is available and accessible for the initial data setup. We will assume that the directory has been

installed with a base dn dc=anybank,dc=com and the first step is to create the following OUs:

1. test users: this OU will store the accounts of the test users. We will assume that the OU is ou=users,dc=anybankc,dc=com

2. authorization: this OU will store the authorization entries according to the authorization provided by the end users. The OU will

be ou=authorizations,dc=anybank,dc=com

3. OAuth client data: this OU will store the OAuth client data. The OU will be ou=oauth-clients,dc=anybank,dc=com

A service account must be created to enable PingFederate to connect to PingDirectory. We will create the account uid=pf-

admin,dc=anybank,dc=com.

The directory schema must then be prepared to store OAuth clients as described in Configure an LDAP directory for client storage.

The following configurations must be carried out in PingFederate to use the correct certificates and signing keys, to connect to

PingDirectory and to correctly expose the PingFederate authorization endpoint:

1. The server base URL must be configured with the public authorization endpoint configured in the DNS (in our example

https://sso.anybank.com). From the PingFederate admin UI Server Configuration -> Server Settings -> Federation Info -> BASE URL

2. The incoming proxy settings must be validated for MTLS connections

a. Navigate to Server Configuration -> Server Settings -> System Options

b. Ensure that Client Certificate Header Name is set to LEAF_CERT

c. Ensure that Client Certificate Chain Header Name is set to CHAIN

d. Save the configuration

3. OAuth and OIDC must be enabled in PingFederate. Navigate to Server Configuration -> System Settings -> Server Settings -> Roles &

Protocol and ensure the following items are selected: OAuth (role) and OpenID Connect (protocol)

4. The Token Endpoint Base URL must be configured with the public token endpoint configured in DNS (in our example

https://token-endpoint.anybank.com). This can be done from the PingFederate admin UI: OAuth Server -> Authorization Server

Settings -> Refresh Token and Persistent Grant Settings

5. A server SSL certificate must be imported. Since PingFederate is never directly exposed to TPPs, the certificate can be an internal

certificate not issued by Open Banking. This is achieved via the admin UI in Server Configuration -> SSL Server Certificate -> Import

6. The Open Banking CA certificate must be imported to enable X509 OAuth client authentication. This is achieved via Server

Configuration -> Trusted CAs -> Import

7. The ASPSP’s signing certificate, obtained from the Open Banking Directory, must be imported and configured to sign the issued ID

tokens. To do so, first import the certificate via Server Configuration -> Signing & Decryption Keys & Certificates -> Import and then

select it to sign the tokens in Server Configuration -> OAuth & OpenID Connect Keys -> ENABLE STATIC KEYS -> P-256

BASIC CONFIGURATIONS

DIRECTORY SETUP

PINGFEDERATE SYSTEM CONFIGURATIONS

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#adminGuide/pf_t_configureLdapDirectoryForClientStorage.html


8. PingFederate must be connected to the Ping Directory. This is achieved by creating a new data store of LDAP type via

the PingFederate admin UI: Configuration -> Data Store -> Add New Data Store. The following picture shows a sample

configuration screen for the data store

9. PingFederate must be configured to store the OAuth client data in PingDirectory as described in the official documentation

“Configure an LDAP directory for client storage”

10. Configure PingFederate to always return the scopes from the Token endpoint. To do so, modify the file

[PF_HOME]/pingfederate/server/default/data/config-store/oauth-scope-settings.xml

and set the variable always-return-scope-for-authz-code to true, as depicted below

11. Configure the well-known endpoint to reflect the OpenBanking Directory JWKS URL, remove the userinfo_endpoint line and

enable the claims required by Open Banking specifications. To do so, modify the file at:

[PF_HOME]/pingfederate/server/default/conf/template/openid-configuration.template.json

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#adminGuide/pf_t_configureLdapDirectoryForClientStorage.html


The following configurations must be carried out in PingAccess:

1. The network server SSL certificate issued by the Open Banking CA must be imported. This is achieved via the admin UI

in Security -> Key Pairs -> Import

2. The Open Banking CA certificate must be imported to enable MATLS with TPPs. In the admin UI, select Security ->

Certificates -> + icon. Once the certificate has been imported, a new Trusted Certificate group must be created and the

Open Banking CA certificate added to the group. The Trusted Group will be later bound to the virtual hosts that require

MTLS

3. To comply with the FAPI specification, TLSv1.0 and TLSv1.1 must be rejected by ASPSPs. To do so, the properties

engine.ssl.protocols, tls.default.protocols and tls.default.cipherSuites in the file [PA_HOME]/conf/run.properties must

be modified as depicted below

4. To ensure all above changes take effect, restart PingAccess

PINGACCESS SYSTEM CONFIGURATIONS

12. Ensure that the userinfo_endpoint line is also removed from the file, and save

13. Enable OGNL expressions by following the steps detailed in the PingFederate server guide - Enable and Disable Expressions

14. Enable the Secondary port, used for MTLS connections, by following the steps detailed in the PingFederate server guide -

Configure PingFederate Properties

15. Download the latest Agentless Integration Kit from the Ping Identity website and install the ReferenceID adapter according

to the bundled documentation. To support Open Banking use cases, it is recommended to use version 1.4 or above of the

Agentless Integration Kit

16. To ensure all above changes take effect, restart PingFederate

Change the highlighted line values as shown in the image below:

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#concept_enablingAndDisablingExpressions.html

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#adminGuide/concept/changingConfigurationParameters.html

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#adminGuide/concept/changingConfigurationParameters.html

https://www.pingidentity.com/en/resources/downloads/pingfederate.html


In the PingFederate admin UI:

1. Navigate to Identity Provider -> Adapters -> Create New Instance

2. Provide an Instance Name (e.g., Form) and an Instance ID (e.g., Form)

3. From the Type dropdown, select the HTML Form IdP Adapter type

4. Proceed to the IdP Adapter screen and click Add a new row to ‘Credential Validators’

5. In the resulting dropdown list of available PCVs, select the PCV created earlier and click Update

6. Ensure that the Session State field is set to Globally or Per Adapter

7. Configure the remaining adapter fields as required

8. Proceed to the Extended Contract screen and extend the contract with a new attribute,

org.sourceid.saml20.adapter.idp.authn.authnCtx

9. Proceed to the Adapter Attributes screen and ensure the Pseudonym tickbox next to the username attribute is ticked

10. Proceed to the Adapter Contract Mapping screen and click Configure Adapter Contract

a. Proceed to the Adapter Contract Fulfillment screen

b. Map the adapter contract as described in the table below:

c. Click Done to complete the adapter contract mapping

11. Click Done to complete the adapter configuration

12. Click Save on the Manage IdP Adapter Instances screen to save the new adapter configuration

FIRST-FACTOR AUTHENTICATION

CUSTOMER AUTHENTICATION (CA & SCA) CONFIGURATIONS

CONTRACT SOURCE VALUE

org.sourceid.saml20.adapter.idp.authn.authnCtx Text urn:openbanking:psd2:ca

policy.action Adapter N/A

username Adapter N/A



1. Navigate to Identity Provider -> Adapters -> Create New Instance

2. Provide an Instance Name (e.g., PingID) and an Instance ID (e.g., PingID)

3. From the Type dropdown, select the PingID Adapter 2.2 type

4. Proceed to the IdP Adapter screen and upload the PingID properties file from the PingOne web portal

5. Proceed to the Adapter Attributes screen and ensure the Pseudonym tickbox next to the subject attribute is ticked

6. Proceed to the Adapter Contract Mapping screen and click Configure Adapter Contract

a. Proceed to the Adapter Contract Fulfillment screen

b. Map the adapter contract as described in the table below:

c. Click Done to complete the adapter contract mapping

7. Click Done to complete the adapter configuration

8. Click Save on the Manage IdP Adapter Instances screen to save the new adapter configuration


org.sourceid.saml20.adapter.idp.authn.authnCtx Text urn:openbanking:psd2:ca

pingid_state Adapter N/A

subject Adapter N/A

SECOND-FACTOR AUTH CONFIGURATION

1. Compile and deploy the custom adapter code in Gitlab - Link to retrieve the openbanking_intent_id and acr claims

from the request object. Instructions for compiling and deploying custom adapters can be found in the PingFederate

administration guide : Build and deploy with Ant

2. In the PingFederate admin UI, create a new adapter instance for the custom adapter

a. Navigate to Identity Provider -> Adapters -> Create New Instance

b. Provide an Instance Name (e.g., OB Request Object Claims Extractor) and an Instance ID (e.g.,

OBROClaimsExtractor)

c. From the Type dropdown, select the custom adapter OB Request Object Claims Extractor type

d. Proceed to the Adapter Attributes screen, and tick the Pseudonym tickbox for the openbanking_intent_id

attribute

e. Proceed to the Adapter Contract Mapping screen and click Configure Adapter Contract

f. On the Adapter Contract Fulfillment page, ensure that the openbanking_intent_id and acr have their source

mapped to the Adapter

g. Click Done to finish adapter contract configuration for the instance

h. Click Done to finish adapter instance configuration

i. Click Save on the Manage IdP Adapter Instances page

SUPPORTING ADAPTERS AND SELECTORS

https://github.com/pingidentity/open-banking-cookbook

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#sdkDevelopersGuide/task/buildingAndDeployingWithAnt.html

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#sdkDevelopersGuide/task/buildingAndDeployingWithAnt.html


3. In the PingFederate admin UI, create a new adapter instance for the consent application integration

a. Navigate to Identity Provider -> Adapters -> Create New Instance

b. Provide an Instance Name (e.g., Consent) and an Instance ID (e.g., Consent)

c. From the Type dropdown, select the ReferenceID Adapter type

d. Proceed to the IdP Adapter screen

e. In the Authentication Endpoint text field, enter the full URL of the consent application to which the user should be

redirected

f. Provide a username in the User Name field and a password in the Pass Phrase field. These are the credentials that the

consent application will use to connect to the reference ID adapter instance during user consent capture to get the

openbanking_intent_id value and the user subject identifier

g. Proceed to the Extended Contract page, and extend the contract with a new attribute openbanking_intent_id

h. Proceed to the Adapter Attributes page and ensure that the subject is set as the Pseudonym

i. Proceed to the Adapter Contract Mapping screen and click Configure Adapter Contract

j. On the Adapter Contract Fulfillment page, ensure that the openbanking_intent_id and subject have their source mapped to

the Adapter

k. Click Done to finish adapter contract configuration for the instance

l. Click Done to finish adapter instance configuration

m. Click Save on the Manage IdP Adapter Instances page

4. In the PingFederate admin UI, create a new selector for the Payments scope to enforce SCA

a. Navigate to Identity Provider -> Selectors -> Create New Instance

b. Provide an Instance Name (e.g., Payment) and an Instance ID (e.g., Payment)

c. From the Type dropdown, select the OAuth Scope Authentication Selector type

d. Proceed to the Authentication Selector screen and ensure the PAYMENTS and OPENID scopes are ticked

e. Click Done to finish selector instance configuration

f. Click Save on the Manage Authentication Selector Instances page

5. In the PingFederate admin UI, create a new selector for the Accounts scope to enforce CA and optionally SCA

a. Navigate to Identity Provider -> Selectors -> Create New Instance

b. Provide an Instance Name (e.g., Account Request) and an Instance ID (e.g., AccountRequest)

c. From the Type dropdown, select the OAuth Scope Authentication Selector type

d. Proceed to the Authentication Selector screen and ensure the ACCOUNTS and OPENID scopes are ticked

e. Click Done to finish selector instance configuration

f. Click Save on the Manage Authentication Selector Instances page



1. Create an Authentication Policy Contract to support authentication policies

a. Navigate to Identity Provider -> Authentication Policies -> Policy Contracts -> Create New Contract

b. Provide a suitable contract name (e.g., Open Banking) and proceed to the next page

c. On the Contract Attributes page, extend the contract with the following two new attributes (enter the attribute

name and click Add)

i. openbanking_intent_id

ii. SAML_AUTHN_CTX

d. Click the Done button for the new contract and then on the resulting Authentication Policy Contracts screen,

click Save

2. Enable authentication policies

a. Navigate to Identity Provider -> Authentication Policies -> Policies

b. Tick the IDP AUTHENTICATION POLICIES checkbox and click Save

3. Create a new authentication policy to support the ‘Payments’ request flow, to meet consent capture, Customer

Authentication (CA) and Secure Customer Authentication (SCA) requirements

a Navigate to Identity Provider -> Authentication Policies -> Policies -> Add Policy

b Provide a suitable policy Name (e.g., PSD2 Payment Authn Policy)

c Drop down the Policy list, and select the Payment selector created earlier in the process

d Click Done to initiate the policy tree

e In the resulting policy creation screen, for the ‘Yes’ result of the Payment selector, select the OB Request Object

Claims Extractor custom adapter created earlier in the process

f. Define the policy tree as shown in Appendix A: PingFederate Policy Tree

g. For the PingID adapter and Consent adapter, map the username to the adapter:

i. Click the Options link under the adapter

ii. Map the Source as Adapter (Form) and the Attribute as username

iii. Click Done to return to the policy

h, For each Success mapped to the Open Banking policy contract:

i Click Contract Mapping

ii. On the Contract Fulfillment tab, map the contract values as follows:

i. Click Done to complete the policy


SAML_AUTHN_CTX Text urn:openbanking:psd2:sca

openbanking_intent_id Adapter (Consent) openbanking_intent_id

subject Adapter (Form) username

AUTHENTICATION POLICIES CONFIGURATION


4. Create a new authentication policy to support the ‘Accounts’ request flow, to meet consent capture, Customer Authentication (CA)

and optional Secure Customer Authentication (SCA) requirements

a. Navigate to Identity Provider -> Authentication Policies -> Policies -> Add Policy

b. Provide a suitable policy Name (e.g., PSD2 Account Authn Policy)

c. Drop down the Policy list, and select the Account Request selector created earlier in the process

d. Click Done to initiate the policy tree

e. In the resulting policy creation screen, under the OB Request Object Claims Extractor adapter, click the Rules link

f. Ensure Default to Success is ticked and configure the rule as shown in the table below:

g. Click Done to apply the rule to the policy tree

h. Define the policy tree as shown in Appendix A: PingFederate Policy Tree

i. For each PingID adapter and Consent adapter, map the username to the adapter:

i. Click the Options link under the adapter

ii. Map the Source as Adapter (Form) and the Attribute as username

iii. Click Done to return to the policy

j. Repeat for each Consent and PingID adapter

k. For the Success under the PingID adapter (in the URN:OPENBANKING:PSD2:SCA rule tree branch), mapped to the

Open Banking policy contract:

i. Click Contract Mapping


l. For the Success under the Consent adapter, mapped to the Open Banking policy contract:

i. Click Contract Mapping


iii. Click Done to complete the policy

5. Click Save on the Authentication Policies screen to save the policy configuration









ATTRIBUTE CONDITION VALUE RESULT

acrequal to (case

insensitive)urn:openbanking:

psd2:scurn:openbanking:

psd2:sca



1. Add the following common scopes:

a. accounts

b. payments

2. Create an access token that is used to grant access and control access parameters:

a. Navigate to OAuth Settings -> Token Mapping -> Access Token Management -> Create New Instance

b. Specify an Instance Name (e.g., OB Access Token) and Instance ID (e.g., OBAT)

c. In the Type list, select “Internally Managed Reference Tokens”

d. On the Instance Configuration page, add a new certificate corresponding to the public/private key pair that has

been signed by OpenBanking as part of ASPSP enrollment

e. Set the JWS Algorithm as RSA using SHA-256

f. Set the Active Signing Certificate Key ID to the certificate that was selected earlier

g. On the Access Token Attribute Contract page, in the Extend the Contract field, add the following extended

attributes (enter the attribute name and click Add):

i. cnf

ii. openbanking_intent_id

iii. sub

h. On the Summary page, click Save

3. Create an OpenID Connect Policy that is used to issue the ID Token to TPPs alongside the Access Token

a. Navigate to OAuth Settings -> Token Mapping -> OpenID Connect Policy Management -> Add Policy

b. Specify a Policy ID and Policy Name

c. In the Access Token Manager list, select the access token manager that was previously created

d. Tick the Include Session Identifier in ID Token, Include User Info in ID Token and Include state hash in ID token

e. In the Attribute Contract page, extend the contract with the attribute openbanking_intent_id

f. In the Attribute Scopes page, select the accounts scope previously added and tick the openbanking_intent_id

attribute checkbox, and click Add

g. In the Attribute Scopes page, select the payments scope previously added and tick the openbanking_intent_id

attribute checkbox, and click Add

h. In the Contract Fulfillment page, map the following attributes:

i. sub : Map to sub from Access Token source

ii. openbanking_intent_id : Map tp openbanking_intent_id from Access Token source

i. Save the OIDC Policy

4. Create an Access Token Mapping from the Authentication Policy to the Access Token instance

a. Navigate to OAuth Server -> Token Mapping -> Access Token Mapping

b. In the Context dropdown, select Authentication Policy Contract: [Contract Name] (example, Authentication Policy

Contract: PSD2AUTHN)

c. In the Access Token Manager dropdown, select the Access token manager name provided earlier (e.g., OB Access

Token)

PINGFEDERATE AUTHORIZATION SERVER OPENID CONNECT & OAUTH 2.0 CONFIGURATION


d. Click the Add Mapping button and the access token mapping configuration pages will appear. Proceed through

the configuration

e. In the Contract Fulfillment page, set the following contract values:

f. Click Save

5. Map the Authentication policy contract to the persistent grant

a. Navigate to OAuth Server -> Grant Mapping -> Authentication Policy Contract Mapping

b. From the Authentication Policy Contract dropdown, select the authentication policy contract created earlier (e.g.,

PSD2AUTHN) and click Add Mapping

c. Continue to the Contract Fulfillment page. Set the following contract values:

d. Click Save


subAuthenticaton Policy

Contractsubject

openbanking_intent_idAuthentication Policy

Contractopenbanking_intent_id

cnf Expression #req = #this.get(“context.

HttpRequest”).getObjectValue(),

#certs = #req.getAttribute(“javax.

servlet.request.X509Certificate”),

#done = (#certs == null) ?

null : @java.util.Collections@

singletonMap(“x5t#S256”, @java.

util.Base64@getUrlEncoder().

withoutPadding().encodeToString(@

java.security.MessageDigest@

getInstance(“SHA-256”).

digest(#certs[0].getEncoded())))


USER_KEYAuthenticaton Policy

Contractsubject

USER_NAMEAuthentication Policy

Contractsubject

To configure PingAccess as a resource server to validate tokens with PingFederate, follow the instructions at:

1. Import Certificates and Create a Trusted Certificate Group

2. Configure the Token Provider

PINGACCESS RESOURCE SERVER OPENID CONNECT & OAUTH 2.0 CONFIGURATION

https://docs.pingidentity.com/bundle/pa_sm_ProtectAnApplication_pa51/page/pa_c_PAProtectApplicationPingAccess.html#concept_kch_g4y_f1b__section_imy_wjb_h1b

https://docs.pingidentity.com/bundle/pa_sm_ProtectAnApplication_pa51/page/pa_c_PAProtectApplicationPingAccess.html#concept_kch_g4y_f1b__section_grf_xjb_h1b


In the PingAccess administration UI:

1. Navigate to Security -> Certificates

2. Import the Open Banking CA certificate to the certificate list:

a. (+) next to the Certificates header. Provide an alias (e.g., openbankingca)

3. Add a new Trusted Certificate Group:

a. (+) next to the Trusted certificate groups header.

b. Drag the imported Open Banking CA Certificate to the new trusted certificate group

c. On the popup dialog, provide the name OBClientAuth and click Save

4. Import the Internal CA signing certificate, used to sign the PingFederate runtime certificate, to the certificate list:

a. (+) next to the Certificates header. Provide an alias (e.g. internalca)

5. Add a new Trusted Certificate Group:

a. (+) next to the Trusted certificate groups header.

b. Drag the imported Internal CA certificate to the new trusted certificate group

c. On the popup dialog, provide the name SiteTrustGroup and click Save


1. Navigate to Access -> Virtual Hosts

2. Create the following virtual hosts as listed in the below table:

CONFIGURE CERTIFICATES FOR OPEN BANKING TRUST AND MTLS

DEFINE VIRTUAL HOSTS

HOST PORT CLIENT CERTIFICATE AUTHENTICATION

TRUSTED CERTIFICATE GROUP

api.anybank.com 3000 Enabled OBClientAuth

sso.anybank.com 3000 Disabled

token-endpoint.anybank.com 3000 Enabled OBClientAuth

API GATEWAY SECURITY CONFIGURATION



1. Navigate to Access -> Identity Mappings

2. Create the following Identity Mappings as shown:

DEFINE IDENTITY MAPPINGS



1. Navigate to Rules

2. Create the following rules of type OAuth Scope

3. Create the following rules of type OAuth Groovy Script (for API)

4.. Create the following rules of type Groovy Script (for Web App)

DEFINE AUTHORIZATION POLICY RULES

RULE NAME SCOPE NEGATE

Scope accounts accounts Unticked

Scope payments payments Unticked

RULE NAME GROOVY SCRIPT

MTLS Validate Client Certificate Chain (API) See Github

MTLS Validate Client Certificate SNI (API) See Github

MTLS Validate Token Binding (API) See Github

RULE NAME GROOVY SCRIPT

MTLS Validate Client Certificate Chain (Web) See Github

MTLS Validate Client Certificate SNI (Web) See Github

In the PingAccess UI:

1. Navigate to Sites

2. Create the following sites according to the table below:

Note: No sites require a Site Authenticator

DEFINE REQUIRED BACKEND RESOURCES & AUTHENTICATORS (SITES)

SITE NAME TARGETS SECURE TRUSTED CERTIFICATE GROUP

PingFederate Token Endpoint

pingfederation.anybank.com:9032

Yes SiteTrustGroup

PingFederatepingfederation.anybank.

com:9031Yes SiteTrustGroup

Bank APIsinternal-api.anybank.

com:80802 Yes SiteTrustGroup

2 The API port of 8080 is an example. This must be changed to match the API deployment







In the PingAccess UI:

1. Navigate to Applications

2. Create the PingFederate application

a. Click Add Application

b. Provide the following information

3. Create the PingFederate Token Endpoint application

a. Click Add Application


c. Click the Save button. No additional resources or policies are required.

c. Click the Save and Go To Resources button and click the Web Policy tab to add new policies to the application

d. Drag the rules MTLS Validate Client Certificate Chain (Web) and MTLS Validate Client Certificate SNI (Web) to the

right side of the screen, under Web Application Policy

DEFINE PROTECTED API RESOURCES (APPLICATIONS)

PROPERTY NAME EXAMPLE VALUE

Name PingFederate

Context Root /

Virtual Host(s) sso.anybank.com:3000

Application Type Web

Web Session None

Web Identity Mapping None

Destination Site radio button selected

Site PingFederate

Require HTTPS Checkbox ticked

Enabled Checkbox ticked


Name PingFederate Token Endpoint

Context Root /

Virtual Host(s) token-endpoint.anybank.com:3000

Application Type Web

Web Session None

Web Identity Mapping PFTokenEndPoint

Destination Site radio button selected

Site PingFederate Token Endpoint

Require HTTPS Checkbox ticked

Enabled Checkbox ticked


Starting from release 7.0, PingDirectory includes a Consent Service, comprising pre-defined schema elements and APIs useful for

managing Open Banking transaction authorization records at the ASPSP.

The Consent Service must be configured as a first step.

1. Create an OAuth Scopes and an OAuth Client within PingFederate for the Directory to use when validating Access Tokens.

a. Navigate to OAuth Server -> Scope Management

b. Add the following scopes:

c. Navigate to OAuth Server -> Clients -> Create New

d. Provide the following information

2. Create a container within the LDAP directory to store consent records. We will use ou=authorizations,dc=anybankc,dc=com

as an example.

a. Locate the consent-service-base-entries.ldif file in [PD_HOME]/resource/consent

b. Modify the file as follows:

CONSENT AUTHORIZATION INTEGRATION

CONFIGURING THE PINGDIRECTORY CONSENT SERVICE

SCOPE VALUE SCOPE DESCRIPTION

urn:pingdirectory:consent Manage my Consents

urn:pingdirectory:consent_admin Manage Consents


Client ID pd_token_introspection

Name PingDirectory Token Introspection Client

Client Authentication Client secret radio button selected

Secret **************

Allowed Grant Types“Access Token Validation (Client is a Resource Server)” checkbox ticked.

# Copyright 2019 Ping Identity Corporation# All Rights Reserved.## The Consent Service base DN, which contains consent records.#dn: ou=authorizations,dc=anybank,dc=comobjectClass: topobjectClass: organizationalUnitou: authorizations

https://documentation.pingidentity.com/pingdirectory/7.0/consentguide/index.shtml#consentguide/intro/concept/chappage.html


c. Import the file using a command similar to the following:

3. Use the provided Ping Directory configuration script to enable and configure the consent service

a. Locate the consent-service-cfg.dsconfig.ldif file in [PD_HOME]/resource/consent

b. Edit the file as applicable for the environment, paying particular attention to entries that are marked “CHANGE-ME”.

i. in the section “dsconfig create-identity-mapper” be sure to update match-base-dn to the appropriate user

container (such as ou=users,dc=anybank,dc=com)

ii. assuming PingFederate has been correctly configured with a TLS server certificate issued by a trusted CA

(not self-signed), remove the configuration relating to blind trust provider by deleting the command that

starts “dsconfig set-trust-manager-provider-prop --provider-name “Blind Trust”

iii. in the section “dsconfig create-external-server” provide the PingFederate hostname and remove the “--set

hostname-verification-method:allow-all“ and “--set “trust-manager-provider:Blind Trust”” parameters from the

command

iv. in the section “dsconfig create-access-token-validator” include the client_id and client_secret values defined

in step 1

v. in the section “dsconfig set-consent-service-prop” update the base-dn to the container created in step 2 (e.g.,

ou=authorizations,dc=anybank,dc=com)

vi. Find the section that begins “#dsconfig create-topology-admin-user --user-name “Open Banking”” and

uncomment the lines that follow. Set an appropriate password for the privileged user

c. Import the file using a command similar to the following:

[PD_HOME]/bin/ldapmodify -D [PD_ADMIN_USER_DN] -w [PD_ADMIN_USER_PASSWORD] -h [PD_HOSTNAME] -p [PD_PORT] --defaultAdd --filename consent-service-base-entries.ldif

[PD_HOME]/bin/dsconfig --no-prompt -j [FILE_CONTAINING_ROOT_PASSWORD] --batch-file consent-service-cfg.dsconfig


Each type of consent or authorization record that we wish to store in the Directory must be specified in terms of a Consent

Definition and one or more Localizations.

We can use the following dsconfig commands to create the necessary consent definitions and localization for the Payment

and Account Information authorization objects:

The Consent Definitions and Localizations appear as follows in the PingDirectory Administration UI:

CREATING CONSENT DEFINITIONS FOR OPEN BANKING

[PD_HOME]/bin/dsconfig create-consent-definition --definition-name payment --set “display-name:OpenBanking Payment” --set “description:An Authorization for the OpenBanking PIS flow”

[PD_HOME]/bin/dsconfig create-consent-definition-localization --definition-name payment --localization-name en-GB --set version:1.0 --set “data-text:Payment” --set “purpose-text:To authorize an Open Banking payment”

[PD_HOME]/bin/dsconfig create-consent-definition --definition-name accountInfo --set “display-name:OpenBanking Account Information” --set “description:An Authorization for the OpenBanking AIS flow” [PD_HOME]/bin/dsconfig create-consent-definition-localization --definition-name accountInfo --localization-name en-GB --set version:1.0 --set “data-text:Account Information” --set “purpose-text:To authorize an Open Banking account information request”



1. Create an OAuth Client for use by a TPP client that uses a client_id and client secret to authenticate to PingFederate

a. Navigate to OAuth Server -> Clients -> Create New


TPP CLIENTS CONFIGURATIONS

OAUTH CLIENT WITH CLIENT SECRET AUTHENTICATION


Client ID tpp_client_secret

Name TPP Client using Client Secret

DescriptionA sample TPP OAuth Client that uses the

Client Secret authentication method

Client Authentication Client secret radio button selected

Secret **************

Require Sgned Requests Checkbox ticked

JWKS URLhttps://jwks.openbanking.org.uk/

<org_id>/<software_id>.jkws

Redirect URIs https://tpp-app.tpp.com/OIDC/callback

Bypass Authorization Approval Checkbox ticked

Restrict Common Scopes“Restrict” checkbox ticked. Also check

“accounts, “openid”, “payments”

Allowed Grant Types

“Authorization Code” checkbox ticked. “Refresh Token” checkbox ticked.“Implicit” checkbox ticked. “Client

Credentials” checkbox ticked

Default Access Token ManagerSelect the Access Token Manager

defined in this step

OpenID Connect ID Token Signing AlgorithmSelect “ECDSA using P256 Curve

and SHA-256”

OpenID Connect PolicySelect the TPP OIDC Policy defined

in this step



1. Create an OAuth Client for use by a TPP client that uses a Private Key JWT to authenticate to PingFederate



OAUTH CLIENT WITH PRIVATE KEY JWT AUTHENTICATION


Client ID tpp_client_jwt

Name TPP Client using Private Key JWT

DescriptionA sample TPP OAuth Client that uses the Private Key JWT authentication method

Client Authentication Private Key JWT radio button selected

Require Signed Requests Checkbox ticked

JWKS URLhttps://jwks.openbanking.org.uk/

<org_id>/<software_id>.jkws



Restrict Common Scopes“Restrict” checkbox ticked. Also check

“accounts, “openid”, “payments”

Allowed Grant Types

“Authorization Code” checkbox ticked. “Refresh Token” checkbox ticked.“Implicit” checkbox ticked. “Client

Credentials” checkbox ticked



OpenID Connect ID Token Signing Algorithm Select “ECDSA using P256 Curve

and SHA-256”


in this step



2. Create an OAuth Client for use by a TPP client that uses a client certificate and Mutual TLS to authenticate to PingFederate



OAUTH CLIENT WITH MUTUAL TLS AUTHENTICATION


Client ID tpp_client_mtls

Name TPP Client using MTLS

DescriptionA sample TPP OAuth Client that uses the Mutual

TLS authentication method

Client Authentication Client TLS Certificate radio button selected

Issuer

Select the certificate issuer for the client certificate that identifies this TPP. This will be the

OpenBanking Issuing CA or appropriate eIDAS certificate issuer.

Subject DN

Enter the exact Distinguished Name included in the client certificate that identifies this TPP (e.g., CN=5juDcG9DsFr9ir56ACaarl,

OU=t8ZfZzjyoYfaqzAhRQ, O=Open Banking Limited, C=GB)

Require Signed Requests Checkbox ticked

JWKS URLhttps://jwks.openbanking.org.uk/<org_

id>/<software_id>.jkws



Restrict Common Scopes“Restrict” checkbox ticked. Also check “accounts,

“openid”, “payments”

Allowed Grant Types“Authorization Code” checkbox ticked. “Refresh

Token” checkbox ticked. “Implicit” checkbox ticked. “Client Credentials” checkbox ticked



OpenID Connect ID Token Signing Algorithm Select “ECDSA using P256 Curve

and SHA-256”


in this step


Appendix A: PingFederate Policy Tree

AUTHENTICATION POLICY: OB PAYMENT AUTHN POLICY


Appendix B: Using the PingDirectory Consent RESTful APIThe PingDirectoy Consent API provides RESTful API endpoints for querying consent definitions and localizations, as well as for

performing full CRUD operations on consent records. The Developer Guide for the Consent Service is a necessary starting point for

developing against these APIs and should be read before proceeding.

Please consult the API reference for a full description of all supported endpoints and operations. The content that follows is

intended to supplement, rather than replace, the product documentation.

For the purposes of simplicity in these examples, we will use basic authentication as a privileged user when invoking the APIs.

We can use the “cn=Consent Service Account” user with the password defined during the setup phase above. A CURL example

looks as follows:

We can query our Consent Definitions through the RESTful API as follows:

curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/

{“_links”:{“localizations”:[{“href”:”https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB”,”hreflang”:”en-GB”}],”self”:{“href”:”[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment”}},”id”:”payment”,”displayName”:”OpenBanking Payment”,”description”:”An Authorization for the OpenBanking PIS flow”}

curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/

{ “_links”: { “localizations”: [ { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB”, “hreflang”: “en-GB” } ], “self”: { “href”: “https:/[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment” } }, “id”: “payment”, “displayName”: “OpenBanking Payment”,

API AUTHENTICATION

VIEWING CONSENT DEFINITIONS

https://apidocs.pingidentity.com/pingdirectory/consent/v1/api/guide/

https://apidocs.pingidentity.com/pingdirectory/consent/v1/api/reference/


“description”: “An Authorization for the OpenBanking PIS flow”}

curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB

{ “_links”: { “parent”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB” } }, “id”: “en-GB”, “locale”: “en-GB”, “version”: “1.0”, “dataText”: “Payment”, “purposeText”: “To authorize an Open Banking payment”}

curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo

{ “_links”: { “localizations”: [ { “href”: “https://PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo/localizations/en-GB”, “hreflang”: “en-GB” } ], “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo” } }, “id”: “accountInfo”, “displayName”: “OpenBanking Account Information”, “description”: “An Authorization for the OpenBanking AIS flow”}

curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo/localizations/en-GB

{ “_links”: { “parent”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo/localizations/en-GB” } }, “id”: “en-GB”, “locale”: “en-GB”, “version”: “1.0”, “dataText”: “Account Information”, “purposeText”: “To authorize an Open Banking account information request”}


Here is an example of how we can use a POST request to create a consent representing an OpenBanking Payment:

The response is as follows:

curl -X POST --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents -H ‘Content-Type: application/json’ -d ‘{ “status”: “pending”, “subject”: “user.1”, “actor”: “AnyBank Authorization Application”, “audience”: “payment:1514988993”, “definition”: { “id”: “payment”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Payment intent 1514988993”, “purposeText”: “To approve the one-time payment”,

“data”: { “intentID”:”payment:1514988993”, “amount”:10.0, “currency”:”GBP”, “status”:”AcceptedTechnicalValidation”, “accountID”:null, “recipient”:”AnyCharity”, “amountFormatted”:”10.00”

} }’

{ “_links”: { “localization”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB”, “hreflang”: “en-GB” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents/546b8415-fcf6-4c25-b563-ac425bf8e8d9” }, “definition”: { “href”: “https://rob.ping-eng.com:9443/consent/v1/definitions/payment” } }, “id”: “546b8415-fcf6-4c25-b563-ac425bf8e8d9”, “status”: “pending”, “subject”: “user.1”, “subjectDN”: “uid=user.1,ou=People,dc=anybank,dc=com”, “actor”: “AnyBank Authorization Application”, “audience”: “payment:1514988993”, “definition”: {

CREATING A CONSENT RECORD


“id”: “payment”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Payment intent 1514988993”, “purposeText”: “To approve the one-time payment”, “data”: { “intentID”: “payment:1514988993”, “amount”: 10, “currency”: “GBP”, “status”: “AcceptedTechnicalValidation”, “accountID”: null, “recipient”: “AnyCharity”, “amountFormatted”: “10.00” }, “createdDate”: “2018-10-22T10:32:35.942Z”, “updatedDate”: “2018-10-22T10:32:35.942Z”}

curl -X POST --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents -H ‘Content-Type: application/json’ -d ‘{ “status”: “pending”, “subject”: “user.1”, “actor”: “AnyBank Authorization Application”, “audience”: “accountRequest:1512132410”, “definition”: { “id”: “accountInfo”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Account Information intent 1512132410”, “purposeText”: “To approve the account information request”,

“data”: { “clientId”:”AnyMoneyManagement”, “accountRequestId”:”accountRequest:1512132410”, “status”:”AwaitingAuthorisation”, “permissions”:[“ReadAccountsDetail”, “ReadBalances”, “ReadBeneficiariesDetail”, “ReadDirectDebits”, “ReadProducts”, “ReadStandingOrdersDetail”, “ReadTransactionsCredits”, “ReadTransactionsDebits”, “ReadTransactionsDetail”], “expirationDateTime”:”Sat Dec 01 07:46:49 EST 2018”, “transactionFromDateTime”:”Mon Oct 22 07:46:49 EST 2007”, “transactionToDateTime”:”Sat Dec 01 07:46:49 EST 2018”, “creationDateTime”:”Mon Oct 22 07:46:49 EST 2017”} }’

Here is an example of how we can use a POST request to create a consent representing an OpenBanking Account Information request:


{ “_links”: { “localization”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo/localizations/en-GB”, “hreflang”: “en-GB” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents/fdced376-cf93-45f1-af94-af82bacac216” }, “definition”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/accountInfo” } }, “id”: “fdced376-cf93-45f1-af94-af82bacac216”, “status”: “pending”, “subject”: “user.1”, “subjectDN”: “uid=user.1,ou=People,dc=anybank,dc=com”, “actor”: “AnyBank Authorization Application”, “audience”: “accountRequest:1512132410”, “definition”: { “id”: “accountInfo”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Account Information intent 1512132410”, “purposeText”: “To approve the account information request”, “data”: { “clientId”: “AnyMoneyManagement”, “accountRequestId”: “accountRequest:1512132410”, “status”: “AwaitingAuthorisation”, “permissions”: [ “ReadAccountsDetail”, “ReadBalances”, “ReadBeneficiariesDetail”, “ReadDirectDebits”, “ReadProducts”, “ReadStandingOrdersDetail”, “ReadTransactionsCredits”, “ReadTransactionsDebits”, “ReadTransactionsDetail” ], “expirationDateTime”: “Sat Dec 01 07:46:49 EST 2018”, “transactionFromDateTime”: “Mon Oct 22 07:46:49 EST 2007”, “transactionToDateTime”: “Sat Dec 01 07:46:49 EST 2018”, “creationDateTime”: “Mon Oct 22 07:46:49 EST 2017” }, “createdDate”: “2018-10-22T10:46:10.830Z”, “updatedDate”: “2018-10-22T10:46:10.830Z”}



Here is an example of using a PATCH request to update the above Payment Authorization, e.g., once the user has accepted the

request and specified an account for settlement.


curl -X PATCH --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents/546b8415-fcf6-4c25-b563-ac425bf8e8d9 -H ‘Content-Type: application/json’ -d ‘{ “status”: “accepted”, “data”: { “status”:”Approved”, “accountID”:”23465475687” } }’

{ “_links”: { “localization”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB”, “hreflang”: “en-GB” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents/546b8415-fcf6-4c25-b563-ac425bf8e8d9” }, “definition”: { “href”: “https://rob.ping-eng.com:9443/consent/v1/definitions/payment” } }, “id”: “546b8415-fcf6-4c25-b563-ac425bf8e8d9”, “status”: “accepted”, “subject”: “user.1”, “subjectDN”: “uid=user.1,ou=People,dc=anybank,dc=com”, “actor”: “AnyBank Authorization Application”, “audience”: “payment:1514988993”, “definition”: { “id”: “payment”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Payment intent 1514988993”, “purposeText”: “To approve the one-time payment”, “data”: { “intentID”: “payment:1514988993”, “amount”: 10, “currency”: “GBP”, “status”: “Approved”, “accountID”:”23465475687”, “recipient”: “AnyCharity”, “amountFormatted”: “10.00” }, “createdDate”: “2018-10-22T10:32:35.942Z”, “updatedDate”: “2018-10-22T10:32:35.942Z”}

UPDATING AND QUERYING CONSENT RECORDS


Here is an example of using a query filter to obtain the consent record for a given intent ID (this is something the PingAccess

Gateway would need to do in order to validate the presence of the consent):


curl -X GET --user “cn=Consent Service Account”:[PASSWORD] https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents?audience=payment:1514988993&actor=AnyBank%20Authorization%20Application

{ “_links”: { “localization”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/definitions/payment/localizations/en-GB”, “hreflang”: “en-GB” }, “self”: { “href”: “https://[PD_HOST]:[PD_HTTPS_PORT]/consent/v1/consents/546b8415-fcf6-4c25-b563-ac425bf8e8d9” }, “definition”: { “href”: “https://rob.ping-eng.com:9443/consent/v1/definitions/payment” } }, “id”: “546b8415-fcf6-4c25-b563-ac425bf8e8d9”, “status”: “accepted”, “subject”: “user.1”, “subjectDN”: “uid=user.1,ou=People,dc=anybank,dc=com”, “actor”: “AnyBank Authorization Application”, “audience”: “payment:1514988993”, “definition”: { “id”: “payment”, “version”: “1.0”, “locale”: “en-GB” }, “dataText”: “Payment intent 1514988993”, “purposeText”: “To approve the one-time payment”, “data”: { “intentID”: “payment:1514988993”, “amount”: 10, “currency”: “GBP”, “status”: “Approved”, “accountID”:”23465475687”, “recipient”: “AnyCharity”, “amountFormatted”: “10.00” }, “createdDate”: “2018-10-22T10:32:35.942Z”, “updatedDate”: “2018-10-22T10:32:35.942Z”}


Appendix C: Using the PingFederate RESTful API to Revoke Grants Linked to Open Banking Intent IDPingFederate provides API endpoints with which to revoke access grants issued to OAuth clients.

In PSD2 terms, these endpoints can be used to invalidate TPP access when consent (previously provided by the PSU) is revoked

either by the PSU themselves, or by the ASPSP through internal security process.

PingFederate includes a REST-based API web service for the management of OAuth access grants. Further information can be

found at PingFederate OAuth Access Grant Management Service

The following is an example of how this can be used for Open Banking flows for the example user [email protected]. The GET

request retrieves all grants issued for the user with the openbanking_intent_id in the grantAttributes node.

The consent management system can then use this information to gain the grant ID and use this to issue a DELETE request to

revoke the grant.

GET https://[PF_HOST]:[PF_USER_PORT]/pf-ws/rest/oauth/users/[TOKEN_SUBJECT_USERKEY]/grants HTTP/1.1

HOST: [PF_HOST]:[PF_USER_PORT]

Authorization: Basic [AUTHZ_BASIC_DIGEST]

X-XSRF-HEADER: [XSRF_HEADER_VALUE]

GET https://anybank-sso.ping-eng.com:9031/pf-ws/rest/oauth/users/[email protected]/grants HTTP/1.1

HOST: anybank-sso.ping-eng.com:9031

Authorization: Basic YWRtaW46MkZlZGVyYXRl

X-XSRF-HEADER: PingFederate

ACCESS GRANT LOOKUP AND REVOCATION

SAMPLE GET REQUEST

Example:

https://documentation.pingidentity.com/pingfederate/pf91/index.shtml#adminGuide/concept/oauthAccessGrantManagementService.html


{

“items”: [

{

“id”: “3GHid5tMENwMqxw2gTUKN0VqkXljdwwC”,

“userKey”: “[email protected]”,

“grantType”: “AUTHORIZATION_CODE”,

“scopes”: [

“openid”,

“accounts”

],

“clientId”: “fintechlabs-code-client-secret”,

“issued”: “2018-07-02T16:21:03.245Z”,

“updated”: “2018-07-02T16:21:03.245Z”,

“grantAttributes”: [

{

“name”: “openbanking_intent_id”,

“values”: [

“urn:mybank:account-request:1530548452670”

]

},

{

“name”: “subject”,

“values”: [

“[email protected]”

]

}

]

}

]

}

SAMPLE GET RESPONSEReturn Code: 200Body:

ABOUT PING IDENTITYPing Identity envisions a digital world powered by intelligent identity. We help enterprises achieve Zero Trust, identity-defined security and more personalized, streamlined user experiences. The Ping Intelligent Identity Platform provides customers, employees and partners with access to cloud, mobile, SaaS and on-premises applications and APIs, while also managing identity and profile data at scale. Over half of the Fortune 100 choose us for our identity expertise, open standards leadership, and partnership with companies including Microsoft, Amazon and Google. We provide flexible options to extend hybrid IT environments and accelerate digital business initiatives with multi-factor authentication, single sign-on, access management, intelligent API security, directory and data governance capabilities. Visit www.pingidentity.com.

#3413 | 03.19 | v03

39

DELETE https://[PF_HOST]:[PF_USER_PORT]/pf-ws/rest/oauth/users/[TOKEN_SUBJECT_USERKEY]/grants/

[GRANT_ID] HTTP/1.1

HOST: [PF_HOST]:[PF_USER_PORT]

Authorization: Basic [AUTHZ_BASIC_DIGEST]

X-XSRF-HEADER: [XSRF_HEADER_VALUE]

DELETE https://anybank-sso.ping-eng.com:9031/pf-ws/rest/oauth/users/[email protected]/

grants/3GHid5tMENwMqxw2gTUKN0VqkXljdwwC HTTP/1.1

HOST: anybank-sso.ping-eng.com:9031

Authorization: Basic YWRtaW46MkZlZGVyYXRl

X-XSRF-HEADER: PingFederate

SAMPLE DELETE REQUEST

Example:

SAMPLE DELETE RESPONSEReturn code: 204

http://pingidentity.com

technical solution guide - ping identity · psd2 & open banking technical solution guide 4 1...

Documents