This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

This document explains the flow of events related to the Consumer Data Standards API v1.0.0. 

Before you begin:

You need to deploy the Consumer Data Standards API in <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/consumerdatastandards.org.au/1.0.0/consumer-data-standards.yaml file. See Configuring APIs for AU, for instruction on how to deploy this API.

You can use the CDR Dynamic Client Registration API v0.1 API to register a Data Recipient (DR) application. See Deploying Dynamic Client Registration API v0.1, and continue from the Authorizing account consents step if you are using the CDR Dynamic Client Registration API v0.1 API.

For evaluation purposes, you may follow all the steps given below and register the DR application manually.

Step 1 - Sign up as a Data Recipient 

In this step, the Data Recipient (DR) registers its application in WSO2 API store.

 Click here to see how it is done...

  1. Navigate to the API Store at https://<WSO2_OB_APIM_HOST>:9443/store.

  2. Select Sign-up on the top left corner of the homepage.

  3. Provide the requested details on the signup page.

     Click here for more information..

    a. Generic details:

    Field

    Description

    Username/Email

    The username/email that the DR uses to sign in to the API Store.

    Password

    The password that the DR uses to sign in to the API Store.

    Retype Password

    This is to prevent the DR from accidentally setting an incorrect password.

    Last Name

    This is the last name of the DR.

    First Name

    This is the first name of the DR.


    b. Company details:

    Field

    Description

    Legal Entity Name

    The official name of the DR.

    Country of Registration

    The country in which the DR is registered.

    Legal Identifier Number (LEI)

    This identifies the DR.

    Company Register

    The organization that registered the DR.

    Company Registration Number

    Identifier issued at the DR registration.

    Address Line 1

    Address of the DR.

    Address Line 2

    Address of the DR.

    City

    City in which the DR is located.

    Postal Code

    Postal code of the geographical location of the DR.

    Country

    The country in which the DR is located.

    c. Competent authority registration details:

    Field

    Description

    Competent Authority

    The regulatory body that authorises and supervises the open banking services delivered by the DR.

    Competent Authority Country

    Country of the competent authority that authorised the DR to provide open banking services.

    Competent Authority Registration Number

    The registration number issued by the Competent Authority to the DR.

    URL of the Competent Authority Register Page

    URL of the page that has the list of organizations authorised by the competent authority.

  4. Read terms and conditions. Click the checkbox to agree to the terms and conditions.

  5. Click Sign Up. A request to approve the DR sign up is now sent to the Approver users.



Step 2 - Approve the DR

Now that you have signed up as a DR, an admin who overlooks all DR sign-up forms must approve it. 


It is not mandatory to include the approval step for approving the DR. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution.

 Click here to see how it is done...

  1. Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.

  2. Locate the approval request and click Assign To Me.

  3. Click Start to start the approval process.

  4. Select Approve then Complete.

Now the DR can sign in to the API store. 

Step 3 - Sign in to the API store as the DR

Users can sign in to the API store and proceed with the steps mentioned below.


 Click here to see how it is done...

  1. Sign in to the API Store as the DR at https://<WSO2_OB_APIM_HOST>:9443/store.

  2. Click Sign In and navigate to the Sign In page.

  3. Enter the username and the password you entered when signing up as a DR.

  4. Click Sign In. 

The homepage of the API store is now displayed along with the APIs.

Step 4 - Create an application

The DR with an application needs to create an application using WSO2 API store. The application created via WSO2 API store allows to observe statistics of APIs, subscribe to APIs, and access the subscribed APIs.
 Click here to see how it is done...

  1. Go to the Applications tab in the API Store.

  2. Click Add Application.

  3. Enter application details.

    Field

    Description

    Name

    Application name.

    Per Token Quota

    Determines the maximum number of API requests accepted within a given duration.

    Description

    This describes the purpose of the application.

  4. Click Add. 

An application can be used to subscribe to multiple APIs. See Subscribe to an API for instructions.

Step 5 - Subscribe to API

The DR user needs to subscribe to the ConsumerDataStandards v1 API in order to access its API resources. Once subscribed, the users can access all the supported services of the API resources.


 Click here to see how it is done...

  1. Go to the APIs tab in the API Store.

  2. Select the ConsumerDataStandards v1 API.

  3. Select the application you created in the Create an application section.

  4. Set the Tiers to Unlimited.

  5. Click Subscribe.

Now that you have subscribed to the API, generate access tokens and invoke the API.

Step 6 - Create certificates

The DR user needs to create certificates to validate whether the DR is registered in a governing entity.

 Click here to see how it is done...

  1. A keystore file is used to store the trusted certificates of the DR in the WSO2 Open Banking solution. Use the commands given below in a command-line interface in order to create a keystore file as a DR.

    Make sure to update the following placeholders:

    <alias>A preferred alias for the keystore file.
    <filename>A preferred name for the keystore file.
    keytool -genkey -alias <alias> -keyalg RSA -keystore <filename>.jks

    During the command execution, the DR user requires to;

    1. Set a password for the keystore.
    2. Provide information, acquired when registering with a governing entity.
    3. Set a password for user-defined alias (<alias>).

  2. Convert the keystore from the .jks format to .PKCS12.  Make sure to update the following placeholders:

    <keyStoreName>This is the name of the <filename>, given above.
    <PKCS12FileName>This is the name of the keystore in the .PKCS12 format.
    keytool -importkeystore -srckeystore <keystoreStoreName>.jks -destkeystore <PKCS12FileName>.p12 -deststoretype PKCS12

    During the command execution, the DR user requires to;

    1. Set a password for the destination keystore.
    2. Enter the source keystore password, as defined in the above step .

  3. Create the application certificate (.pem) file in the PKCS12 format using the keystore. e.g: dr.p12.

    Make sure to update the following placeholders:

    <PKCS12FileName>This is the name of the keystore in the PKCS12 format, as mentioned above for the <PKCS12FileName>.
    <PEMFileName>This is the name of the application certificate that is created in the .pem format. 
    openssl pkcs12 -in <PKCS12FileName>.p12 -nokeys -out <PEMFileName>.pem

    During the command execution, the DR user requires to;

    1. Set a password to import the .pem file.

  4. Import the public key you extracted in the previous step to the truststore file.

    Update the placeholder values and use the given command.

    <alias>The alias for the keystore file.
    <PEMFileName>The name of the application certificate that is created in the .pem format.
    <truststoreFileName>The name of the truststore file that you want to import the public key.
    <password>The keystore password of the truststore file.
    keytool -import -alias <alias> -file <PEMFileName>.pem -keystore <truststoreFileName>.jks -storepass <password>

Step 7 - Generate keys

The DR user requires a Client ID (Consumer Key) and a Client secret (Consumer Secret) to access the subscribed APIs.

 Click here to see how it is done...

  1. Sign in to the API store as a DR user and go to the Applications tab.

  2. Choose your application from the Application List and select either of the following:

    1. Production Keys: Generates access tokens in the production environment.

    2. Sandbox Keys: Generates access tokens in the sandbox environment.

  3. Provide the requested information as defined below:  

    Field

    Description

    Grant Types

    These determine the credentials that are used to generate the access token.

    • Refresh Token: This is to renew an expired access token.

    • Client Credential: This relates to the client credentials grant type and is applicable when consuming the API as an application.

    • Code: This relates to the authorisation code grant type and is applicable when consuming the API as a user.

    Callback URL

    This is the URL used by the DR to receive the authorisation code sent from the Data Holder (bank). The authorisation code can be used later to generate an OAuth2 access token.

    Application Certificate

    This is the content between the BEGIN CERTIFICATE and END CERTIFICATE strings of the application certificate (.pem) that you created above.

  4. Click Request Access if you are generating production keys. If workflows are configured in the solution, it sends a request to Approver user to approve the token generation. Otherwise, it generates consumer key and consumer secret.

  5. Click Generate Keys if you are generating sandbox keys. It generates consumer key and consumer secret.

Step 8 - Approve Production Key generation

This step includes instructions to an Approver user to review and approve a request to generate production keys for an application.

It is not mandatory to include the approval step for the Production Key generation. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution.

 Click here to see how it is done...

  1. Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.

  2. Click Tasks and then Application Registration.

  3. Locate the approval request and click Assign To Me.

  4. Click Start to start the approval process.
  5. Select Approve and then click Complete.
  6. Navigate back to the API Store and click Applications.
  7. On the Applications tab in the API Store, click View of the application that you created.
  8. Select the Production Keys or Sandbox Keys tab to find the generated keys.
    The consumer key and consumer secret are displayed as follows:

Step 9 - Authorizing account consents

The bank redirects the bank customer to authenticate and approve/deny application-provided consents.

 Click here to see how it is done

  1. Generate the request object by signing the following JSON payload using the supported algorithms.

    To configure the supporting algorithms:

    1. Open the <WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml file.

    2. Update the following configurations with the algorithm:

      <UK>
	<!-- The following configuration specifies the signature algorithms allowed in the DR requests.
        The JWTs signed in algorithms that are not in the following list, will be rejected. If the configuration
        is not present, no validation will occur and any algorithm will be passed through.
        Allowed values are:
            1. PS256
            2. RS256
        -->
	<AllowedInboundSignatureAlgorithms>
		<Algorithm>PS256</Algorithm>
	</AllowedInboundSignatureAlgorithms>
</UK>

    The scope claim is required to access the data available via an endpoint. See Consumer Data Standards Australia - Authorisation Scopes, for more information on Authorisation scopes.

  2. Run the following in a browser to prompt the invocation of the authorize API. Make sure you update the placeholders with the relevant values:



  3. You are directed to a login page. Log in with the credentials of a user that has a Subscriber role.

  4. If a secondary factor is required. For example, SMS OTP, provide the relevant values. Upon successful authentication, the user is redirected to the consent management page.

  5. Upon providing consent, the consumer is redirected to the callback URL of the DR with the authorization code.

Step 10 - Generate user access token

In this section, you will be generating an access token using the authorization code generated in the section above.

 Click here to see how it is done

  1. The client_assertion is a JSON Web Token (JWT). Generate the client_assertion by signing the following JSON payload using the supported algorithms:

    The value of the aud claim should contain the same value as the Identity Provider Entity ID.

     Click here to view the Identity Provider Entity ID:
    1. Sign in to the Identity and Access Management console at https://localhost:9446/carbon. 
    2. In the Main menu, go to Home > Identity > Identity Providers > Resident.
    3. View the value in Resident Identity Provider > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration > Identity Provider Entity ID. By default this value is set to https://localhost:8243/token.

  2. Run the following cURL command in a command prompt to generate the access token as a DR user. Use --cert and --key in the access token generation request, for Mutual TLS authentication. 

    curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/token \
  -H 'Cache-Control: no-cache' -k \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --cert <TRANSPORT_PUBLIC_KEY_FILE_PATH> --key <TRANSPORT_PRIVATE_KEY_FILE_PATH> \
  -d 'client_id=<APPLICATION_ID>&grant_type=authorization_code&code=<GENERATED_CODE>&redirect_uri=<APPLICATION_REDIRECT_URI>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION>'

    The response of the contains an access token and a refresh token as follows:

    {
   "access_token":"4f939510-4330-336a-a3d6-3cee7e9f50da",
   "refresh_token":"cedd647f-cb01-3112-bfea-3a5eb61d05a8",
   "scope":"bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read openid",
   "id_token":"eyJ4NXQiOiJORFV3WldGbE16WmlZalV6WmpJeE5USTNZV0V4T0dWXmw",
   "token_type":"Bearer",
   "expires_in":3496
}

    The access tokens have an expiration period, once an access token expires, you need to regenerate it. Run the following cURL command to generate a new access token as an AISP:

    curl -X POST \
 https://<WSO2_OB_APIM_HOST>:8243/token \
 -H 'Authorization: Basic <APPLICATION CLIENTID:CLIENT_SECRET_BASE64_ENCODED>' \
 -H 'Content-Type: application/x-www-form-urlencoded' \
 -H 'cache-control: no-cache' \
 -k --cert <PUBLIC_KEY_FILE_PATH> --key <PRIVATE_KEY_FILE_PATH> \
 -d 'grant_type=refresh_token&refresh_token=<REFRESH_TOKEN>'

Step 11 - Invoke Consumer Data Standards API

This section shows how to invoke the endpoints in the ConsumerDataStandards v1 API using a few samples. These requests use the access token generated in the step above .

GET /banking/accounts

The DR is able to obtain a list of accounts that the consumer has authorised the DR to access.

POST /banking/accounts/balances

The DR is able to obtain balances for a specified list of accounts. The request body contains a list of account IDs to obtain balances for.

See Consumer Data Standards Australia - Banking APIs, for more information on all the available endpoints.

  • No labels