PSD2 CONFIGURATIONS GUIDE

This document includes following topics:

• IDCS Configuration
• APICS Configurations
• Third Party Application Registration
• Registering A Third Party Mobile Client In IDCS
• OBDX Configurations

 

IDCS CONFIGURATIONS

Registering OBDX as an Admin application in IDCS

• Click add in the application tab to register OBDX Admin application.

• Select trusted application.

• Add “name” and “description”.

• Check ‘Client Credentials’ option as the ‘Allowed Grant Type’. Check ‘Introspect’ as ‘Allowed Operations’.

• Add Admin Privileges for OBDX Client Configuration.

• Application added.

• Application added. We shall need the Client-Id and Client-Secret to configure OBDX Admin application in OBDX and WLS. (Enabling PSD2 on OBDX Entity & Set up IDCS Asserter section).

Setting up login page

• Set Login URL to ‘/ui/v1/signin’ if something else. ‘/ui/v1/signin’ is the default login page provided by IDCS.

• Page to set session token timeout and custom login URL.

APICS CONFIGURATIONS

• Login to APICS

• Create API

• API Implementation

• Edit Policy

• View API Summarizing

THIRD PARTY APPLICATION REGISTRATION

Registering a Third Party Browser Client in IDCS

• Log into the IDCS dashboard.
• Click on the “Applications” tab which will list all applications associated with the logged in account.

• Click add in the application tab to register a browser client.

• Select ‘Trusted Application’.

• Add ‘Name’ and ‘Description’.

• Check ‘Authorization Code’ option as the ‘Allowed Grant Type’. Configure the ‘Redirect URL’ of the application.

• Configure Access Token Expiration, Refresh Token properties as per bank policy.

• Application Added.

• Click on “Activate” to activate the application.

REGISTERING A THIRD PARTY MOBILE CLIENT IN IDCS

• Log into the IDCS dashboard.
• Click on the “Applications” tab which will list all applications associated with the logged in account.

• Click on the “Add” button to create a new application.

• Select Mobile Application.

• Enter the name and description.

• Select ‘Authorization Code’ as Allowed Grant Types. Configure Redirect-URL as per your choice. The client application should listen to this URL when IDCS redirects on this URL with Authorization code.

• Click on Finish to complete the process.

• Client ID is generated for the application. As this application is not a ‘Trusted Application’, Client-Secret is not generated for the application.

• Click on “Activate” to activate the application.

OBDX CONFIGURATIONS

WebLogic Configurations

Patch WLS12.2.1.2

• WLS 12.2.1.2.0 (PS2 PSU) Obtain and install the WLS 12.2.1.2.0 kit from OTN:

Download the 12.2.1.2.171017 Patch Set Update (PSU) for WebLogic Server 12.2.1.2 from https://support.oracle.com/epmos/faces/PatchDetail?patchId=26485996

Apply the PSU patch following the instructions contained in the README.txt in the p26485996_122120_Generic.zip patch file.

Set up IDCS asserter

• Login to WLS console using admin credentials.
• Navigate to Security Realms myrealm Providers
• Click on New
• Name the asserter. Select ‘OracleIdentityCloudIntegrator’ as the provider type

• Click ‘OK’

• Click on ‘IDCSAsserter’
• Choose ‘Authorization’ property as Active Type

• Click on Provider Specific and configure IDCSAsserter properties. Provide Client Id and Client secret of OBDX Admin Application; created in Step 4.1.a in fields Client Id and Client Secret & Confirm Credentials. Fill in other marked properties as per the IDCS host.

• Restart the OBDX Managed as well as Admin Server.

Configuring TLS for IDCS.

• Download Certificate from IDCS Host. Add the certificate to a custom keystore and add it to the WebLogic server.

• Add the following property in WLS managed server start configuration.

Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier

• Restart OBDX Managed as well as Admin Server.

OBDX Configurations (Scope Definition)

Scopes need to be defined in IDCS and OBDX application as well. It needs to be operationally ensured that the scopes are the same in IDCS as well as OBDX.

The scopes will be seeded in the OBDX application table ‘DIGX_FW_ACCESSPOINTSCOPE’ as shown below.

Once the scopes are seeded, the same will appear as part of Touch Point Definition as well as in Role to transaction mapping

OBDX Configurations (Touch Point Definition)

Touch points in OBDX are user agents from which transactions or inquiries can be initiated. Touch points are of 2 types i.e. Internal and External.

Internal Touch Points are shipped from the product i.e. Internet, Mobile Apps, Mobile Responsive, Siri/Chatbot etc.

External Touch Points are typically Third PartyA party is any individual or business entity having a banking relationship with the bank. Applications that the bank user registers on to inquire and/or transact on bank accounts from third party applications.

To create an external touch point:

1. Login to the system as System Administrator user.
2. Navigate to Touch Point Definition option.

• Click on Create option and enter the details required to create the Touch Point as mentioned below.

Description of the fields is mentioned below:

Field Name	Mandatory	Description	Recommended Values
Touch Point Id	Yes	Specify a unique Id to identify the Touch point in the OBDX application	NA
Touch Point Name	Yes	Specify the Touch point name with which the same needs to be identified in the system	NA
Touch Point Type	Yes	Specify the type of Touch Point if it is internal or external. Third party applications are defined as external touch points in the system	External
Client ID	Yes	Specify the same client ID provided to the third party application as part of onboarding in IDCS.	NA
Scopes	Yes	Select the scopes that the Third Party application can access on behalf of the user.	The scopes for the Third Party application should be operationally the same as that defined in IDCS
Upload Logo	Yes	Upload the image of the brand logo of the Third Party Application. This will help the end business user to identify the third party application while managing the Fine Grained Consents	NA
Touch Point Status	Yes	If a particular Touch point is disabled, then any request from Third Party application will not be executed by OBAPI	The default value to will be ‘Active’ to enable the third party application to access information
Headless Mode	Yes	Select if the Touch Point needs to be enabled in Headless mode. If enabled then masking, indirection of data etc. will be disabled while accessing API from the Third Party	Ideally it should be selected as “YES” so that Third Party apps can access OBAPI in headless mode.
Two Factor Authentication	Yes	Select if two factor authentication needs to be enabled for the third party application.	If disabled, it will override the system level 2FA configuration for the requests from that respective touch point.
Self On Board Touch Points	Yes	Select if the touch point will be self onboarded by the user or will be provided by the bank official.	Value should be ideally “YES” since the user decides the TPPs on which he/she wishes to register

The above parameters defines the behavior of the third party application when it requests access to OBDX/OBAPI resources. To summarize, any external channel that needs to be given access to OBDX API’s, the pre-requisite is that registration need to be done on IDCS and OBDX as well. Client ID is the unique identifier common between the two systems i.e. (IDCS and OBDX)

Post maintenance of touch point, access needs to be defined for the touch point by defining application role for a scope and then associate transactions to the application role.

OBDX Configurations (Role Transaction Mapping)

Each scope defined and mapped for a Third Party Application needs an application role to access OBDX/OBAPI resources on behalf of the user.

As part of this maintenance, new application role can be created of type ‘External’ for each scope and also map transactions to the application role created.

To create new application role and map transactions:

1. Login to the system as System Administrator user.
2. Navigate to Role Transaction Mapping maintenance.

• Click on ‘Create’ option.
• Create New Application Role and select user type i.e. ‘Retail’ and Access Type as ‘External’.
• Select the scope from the list for which this new application role is being created.

• Now click on Map Transaction to associate transactions to the new application role created.
• Select the module(s) in case of specific transactions from the modules need to be mapped.
• The selected transactions will be available to the Third Party for access on the basis of the passed scope.
• Click on Save will take to review page.
• Confirm the Role Transaction Mapping.

Back