Centralized Authentication and Authorization
1. Overview
Centralized Authentication and Authorization uses the concept of federated authentication, which allows Users to access various applications and services using their credentials from a trusted Identity Provider (IdP). By leveraging the authentication infrastructure of trusted IdPs, this federated authentication model facilitates Single Sign-On (SSO) capabilities streamlining the User authentication experience. The User can access resources across different organizations or systems, which are called the Relying Parties (RPs) without needing separate authentication credentials for each.
In the context of Open Finance (OF) the Central Authentication and Authorization Provider (CAAP) acts as an IdP for the LFIs which are the RPs that participate in the federation.
The LFI trusts the CAAP to authenticate the User. There will be strong agreements between the CAAP and the LFI to develop an understanding of how the User can be securely identified.
The User is verified and onboarded with the CAAP and can then use the authentication with the CAAP to securely authorize their LFIs for account access through multiple TPPs.
This removes the need for the User to authenticate with their LFI for every new Data Sharing Request (DSR) / Service Initiation Request (SIR) interaction through the TPPs.
The User has a central consent dashboard provided by the CAAP to manage their consents with different TPPs.
The CAAP MUST use logos and brand names of the LFIs and TPPs as they are defined in the Trust Framework Directory.
2. CAAP Onboarding and Linking the First LFI
For Authenticating and Authorizing OF requests using the CAAP for LFIs that support the federated model the following one-time setup steps are needed
onboarding with the CAAP
one time linking of each LFIs with the CAAP for which the User would like to authorize OF requests
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can be onboarded with the CAAP as part of an OF journey. (The same applies to SIR and service requests)
2.1 User Journey
2.2 Wireframes
The diagram illustrates an OF journey for a User
consuming the TPP service on a mobile app, mobile browser or desktop browser
has selected an LFI that uses the federated authentication model using the CAAP
does not have a CAAP app
Click here for a prototype depicting this journey.
Rules & Guidelines | |
---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen(User-facing TPP to CAAP) that the authorization for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | Since the User does not have the CAAP app the redirection MUST take the User to a web page hosted by the CAAP. |
4 | The CAAP webpage MUST provide the following
|
5 | On redirection to the CAAP webpage in Step 4 the consent details will be persisted for the User which will be retrieved and presented after the User installs the app (using the mechanism of deferred deep linking). |
6 | After installing the CAAP app the User MUST be presented with a one-time consent to be given to the CAAP app to
|
7 | The CAAP app MUST provide the option for manual ID verification of the User which will involve
Each step MUST be presented with clear instructions |
8 | The CAAP app MUST provide the option for ID verification of the User using their UAE Pass identification which will involve the following steps
|
9 | On successful verification of the User’s identity, the CAAP app MUST link the LFI which was selected as part of the consent. For this
|
10 | On successfully linking the LFI, the User MUST be presented the OF consent given to the TPP. If the Consent Authorization Window as expected by the TPP has expired then the User MUST be informed that they need to initiate the request again from the TPP. |
11 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
12 | On successful authorization MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
13 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
14 | User-facing TPPs MUST confirm the successful completion of the OF Request (DSR, SIR). |
3. Linking Subsequent LFIs with CAAP
Once the User has onboarded with the CAAP app the User can authorize any OF requests for other LFIs by simply linking each new LFI with the CAAP. There is no further ID verification required for linking any new LFIs.
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can authorize an OF consent for a new LFI using the CAAP app. (The same applies to SIR and service requests)
3.1 User Journey
3.2 Wireframes
The diagram illustrates an OF journey for a User
consuming the TPP service on a mobile app, mobile browser or a desktop browser
has selected a LFI that uses the federated authentication model
is onboarded with the CAAP app
The redirection MUST directly invoke the CAAP app to enable the User to authenticate and MUST not require the User to provide any User identifier or other credentials to the User-facing TPP.
Click here for a prototype depicting this journey.
Rules & Guidelines | |
---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen( User-facing TPP to CAAP) that the authorization for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | If the user is consuming the TPP service(mobile app/mobile web page) on the same mobile device which has the CAAP app the redirection MUST take the User to the CAAP app. |
4 | If the user is consuming the TPP service on the device which does not have the CAAP app then the redirection MUST take the User to a CAAP hosted webpage which MUST provide the following
|
5 | On redirection from Step 3 or 4 the CAAP app will request for the biometric/Device PIN authentication. |
6 | On successful User authentication, the CAAP app MUST link the LFI which was selected as part of the consent. For this
|
7 | On successfully linking the LFI, the User MUST be presented the OF consent given to the TPP. If the Consent Authorization Window as expected by the TPP has expired then the User MUST be informed that they need to initiate the request again from the TPP. |
8 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
9 | On successful authorization of the consent the CAAP MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
10 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
11 | User-facing TPPs MUST confirm the successful completion of the OF Request (DSR, SIR). |
4. OF Journey for a Linked LFI
Once the User has onboarded the CAAP app and linked a LFI the User can authorize any OF requests from any TPP for the linked LFI by simply authenticating and authorizing through the CAAP app.
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can authorize an OF consent for a linked LFI using the CAAP app. (The same applies to SIR and service requests)
4.1 User Journey
4.2 Wireframes
The diagram illustrates an OF journey for a User
consuming the TPP service on a mobile app, mobile browser or desktop browser
is onboarded with the CAAP app
has selected an LFI that uses the federated authentication model and is already linked with the CAAP app
The redirection MUST directly invoke the CAAP app to enable the User to authenticate and MUST not require the User to provide any User identifier or other credentials to the User-facing TPP.
Click here for a prototype depicting this journey
Rules & Guidelines | |
---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen( User-facing TPP to CAAP) that the authorization for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | If the user is consuming the TPP service(mobile app/mobile web page) on the same mobile device which has the CAAP app the redirection MUST take the User directly to the CAAP app. |
4 | If the user is consuming the TPP service on the device which does not have the CAAP app then the redirection MUST take the User to a CAAP hosted webpage which MUST provide the following
|
5 | On redirection from Step 3 or 4 the CAAP app will request for the biometric authentication. |
6 | After successful User authentication the CAAP app MUST present the OF consent given to the TPP. |
7 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
8 | On successful authorization of the consent the CAAP MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
9 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
10 | User-facing TPPs MUST confirm the successful completion of the Open Banking Service Request (DSR, SIR). |
© CBUAE 2024-2025
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.