SAP Cloud Platform API Management - Enable Client Certificate Authentication on API Proxies

[sandeepbheema]

SAP Cloud Platform API Management lets you publish, promote, and oversee APIs in a secure and scalable environment. API Proxies are deployed and published by associating them with products in API Portal. Such API Proxies can be consumed by the App developers by subscribing to the product and create an application in Developer portal to consume.

API Proxies can be secured by applying various policies and can be authenticated in multiple ways like OAuth, JWT, Application Secret/Key and Client Certificate Authentication mechanisms.

This blog is to guide on how to expose an API Proxy by enforcing Client Certificate Authentication.  Client Certificate authentication is also referred as '2-way SSL' / 'Mutual SSL Authentication'. For reference, there is a blog on consuming an API Provider using Client Certificate authentication from API Portal.

Constraint:

Each API Management tenant gets provisioned with one 'Virtual Host'/'Host Alias' by default during on-boarding. While on-boarding the API Management tenant, 'Virtual Host'/'Host Alias' has to be provided so that the API proxies will be exposed with proxy URL containing the same.

If you desire to enable 2-way SSL on API proxies, it has to be done at the Virtual host/Host alias level. Which means all the API Proxies published on such Virtual host are enforced with 2-way SSL & all the API Consumers consuming the proxies on such Virtual host are challenged to provide the Certificate for Authentication. All or none.

Solution:

Multiple Virtual Hosts can be added on a single API Management tenant. There is a provision to add or modify the Virtual host/host alias using the management API of API Portal as defined in the SAP Help link. This is partially a self-service task using API's and share the self-service response in an incident with SAP under the component OPU-API-OD-OPS.

Steps:

1. Create an additional virtual host exclusively for 2-way SSL authentication purpose.


2. Raise an incident (component OPU-API-OD-OPS) to enable 2-way SSL on the new Virtual host created exclusively for this purpose.


3. Provide/upload both the public and root Certificates (in Base-64 encoded x.509 (.CER) format) of all the partners (to add them on the specific virtual host in the same incident) intended to consume API Proxies using 2-way SSL.

Note: For testing purpose, you could create an SAP Passport certificate with your own S-user, extract the public certificate & it's root certificate (CA) and add them into the same incident.

After Step 1: After getting the new virtual host added, multiple Virtual hosts should be visible under 'Host Alias' when you attempt to create a new API Proxy in API Portal.



After Steps 2 & 3: Once the SAP incident processor confirms that 2-way SSL is enabled on the specific Virtual host (Host Alias) and imported the client's public & root certificates - it's time to build/re-build the API proxies.

New API Proxy: Select the new Host Alias (example: abc-devcc) exclusively created for this purpose while creating the proxy, build the proxy with respective policies (optional), deploy and publish by associating with the products.

Existing API Proxy: Edit the existing API Proxy, change the Host Alias (under overview) to the 2-way enabled URL, redeploy and republish.

Note: API Proxies deployed on the original virtual host (example:  'abc-dev' in the snapshot) does not get affected with this change.

After deploy/re-deploy, the API proxy URL get's generated with the new Virtual Host URL as below.



It's time to test. Used Postman tool to test trigger the API's.

Test without private key/certificate:

Triggered the API Proxy URL with GET operation and received an error '400 No required SSL certificate was sent'. 



Test after Importing the Private key/certificate:

Import the private key against the API Proxy Virtual host name with passphrase as below. (used SAP passport for this exercise)





 

Conclusion:

2-Way SSL (or) Client Certificate based Authentication can be enforced at the Virtual host level of API Management tenant. One additional virtual host with 2-way SSL enabled is enough for multiple API consumers. To differentiate the control over who can access which proxy on a 2-way SSL enabled Virtual Host URL - recommend to include additional checks at the Policy level like API Key or IP Address.

API key -  generate role based access to Products on developer portal which will control which APIs get visibility to the App Developers and ultimately the respective API key/secret to be used.

IP Address - minute control at the policy level if you know the API Consuming application's IP range

For more blogs on SAP Cloud Platform API Management visit the SAP Community