Save Relation Between TPP Certificate and Client ID (OpenBanking / PSD2)
Article ID: 105986
Updated On:
Products
STARTER PACK-7
CA Rapid App Security
CA API Gateway
Issue/Introduction
How can we store the relation between the certificate information and the TPP ClientID in our API Gateway? We need to persist this relation, so caching it is not an option.
We need some help to understand the capabilities of the API Gateway related with OpenBanking specification (PSD2 for UK). The security specification of OpenBanking establishes a one-to-one relation between the enrolled TPPs (ClientIDs) and their certificate used for Mutual Authentication (TLS). The main target of this requirement is to offer to the APIM Platform a way to confirm this communication is secure and comes from the correct TPP ( APIM confirms the provided ClientID received in the request body is related with the Certificate used for MA).
The expected flow is the following:
1. A Third party enrols in our API Portal, sending information about its business. In addition, using another flow (for example via email) the TPP sends us the certificate.
2. The API team in our company will double check the information sent using the API Portal and the certificate send via email, all together.
3. If everything is OK, the TPP is accepted and the enrollment finishes registering an App in the API Portal. This App will generate a client_id and a client_secret.
4. THIS IS THE IMPORTANT POINT!! After this registering, the API Team must persist in our API Platform the relation between the certificate got on step 1 with the client_id generated on step 3.
5. When the registered App on step 3 wants to consume a published API, the communications between the App and the API platform will be secured using the certificate provided in step 1. In addition, the App must send in the request the client_id of the registered App, got on step 3.
6. When the API Platform receives the request, one of the security assertions is to confirm that the certificate used in the secured communication is related with the client_id retrieved from the request info. If it's not related, the APIM must return a security error.
We need some help to understand the capabilities of the API Gateway related with OpenBanking specification (PSD2 for UK). The security specification of OpenBanking establishes a one-to-one relation between the enrolled TPPs (ClientIDs) and their certificate used for Mutual Authentication (TLS). The main target of this requirement is to offer to the APIM Platform a way to confirm this communication is secure and comes from the correct TPP ( APIM confirms the provided ClientID received in the request body is related with the Certificate used for MA).
The expected flow is the following:
1. A Third party enrols in our API Portal, sending information about its business. In addition, using another flow (for example via email) the TPP sends us the certificate.
2. The API team in our company will double check the information sent using the API Portal and the certificate send via email, all together.
3. If everything is OK, the TPP is accepted and the enrollment finishes registering an App in the API Portal. This App will generate a client_id and a client_secret.
4. THIS IS THE IMPORTANT POINT!! After this registering, the API Team must persist in our API Platform the relation between the certificate got on step 1 with the client_id generated on step 3.
5. When the registered App on step 3 wants to consume a published API, the communications between the App and the API platform will be secured using the certificate provided in step 1. In addition, the App must send in the request the client_id of the registered App, got on step 3.
6. When the API Platform receives the request, one of the security assertions is to confirm that the certificate used in the secured communication is related with the client_id retrieved from the request info. If it's not related, the APIM must return a security error.
Environment
Release:
Component: APIGTW
Component: APIGTW
Resolution
To record the relationship between a certificate and an app (via client_id). You are using the developer portal, therefore the information relating to the app lives in the portal.
• You would want to remember the certificate finger print at issuing time in policy and store it as a CustomField property of the Application.
• This would be achieved by calling PAPI via the policy issuing the certificate for example.
• The PAPI documentation at the following link provides information to make an api call that updates an application https://docops.ca.com/ca-api-developer-portal-enhanced-experience/4-2/en/publishers/portal-api-papi#!/Applications/updateApplication
• At runtime, you would want to load up the application properties for the given client_id and you would confirm that the certificate that was 'proven' in the handshare has the same signature as the one stored in the property of the application.
• You would want to remember the certificate finger print at issuing time in policy and store it as a CustomField property of the Application.
• This would be achieved by calling PAPI via the policy issuing the certificate for example.
• The PAPI documentation at the following link provides information to make an api call that updates an application https://docops.ca.com/ca-api-developer-portal-enhanced-experience/4-2/en/publishers/portal-api-papi#!/Applications/updateApplication
• At runtime, you would want to load up the application properties for the given client_id and you would confirm that the certificate that was 'proven' in the handshare has the same signature as the one stored in the property of the application.
Feedback
Yes
No
Powered by
