Post Auto-Registration Issue with CA API Developer Portal (Saas) Integrated with CA API Gateway (On-Premise)

cloud-computing-2001090_1920.jpg

Problem Description:

After registering the SaaS CA API Developer Portal, the applications created on the developer portal cannot be synced with the CA API Gateway OTK database.

Solution:

1- Check your JDBC connection configured for OTK. When you installed your OTK onto the CA API Gateway, you were asked to configure a JDBC connection for your OTK persistence layer if you choose to use SQL databases. By default, you should use “OAuth” for that JDBC connection, but in many cases, the JDBC name can be set to anything. This will not give you problems with OTK but when you register with SaaS Developer Portal, the auto registration will create services and encapsulated assertions that contain a JDBC Query and those query assertions are mapped to JDBC connection by name which is “OAuth”. If you have a different name for your OTK JDBC Connection, those JDBC queries will fail.

To fix the issue, you need to update the JDBC query assertions in the following services:

Portal Application Sync Fragment

Portal Application Sync Fragment

Change default connection OAuth to the connection you configured for your OTK.

2- If you are using a dual API Gateway configuration and you Installed OTK onto both DMZ and INT gateways, after you register your DMZ API Gateway to the Developer Portal, the Application will show that it is out of sync. This is because the DMZ Gateway should not have the OTK Database configured. For most of the steps in deploying an application from the SaaS Portal to the API Gateway, the request can be handled by built-in OTK assertions where it will route the DB query requests to the INT gateway. The INT Gateway then queries the OTK DB. Unfortunately, a simple error in the portal sync service breaks the flow.

In Portal Application Sync Fragment, the direct JDBC query will return API key count value in a context variable called: ${apiKeyCount.count}, meanwhile the OTK assertion will return the API Key count value in ${apiKeyCount}. The following policy will refer to ${apiKeyCount.count} for the API Key count value. Therefore, when trying to sync an Application from the DMZ Gateway, the OTK Assertion is used and returns the value in the wrong context variable.

To fix this issue, simply add a context variable after the OTK Assertion to assign the value of ${apiKeyCount} to ${apiKeyCount.count}.

Adding a Context Variable After the OTK Assertion

Adding a Context Variable After the OTK Assertion

3- If you are using the Cassandra Database for OTK Token store, you need to upgrade your CA API Gateway to v9.4 or up and OTK to v4.3 or up. Otherwise, it will not support integration with SaaS CA API Developer Portal. Only OTK v4.3 or up will have the updated database schema to be able to store API Key information and API Access information, which is required when creating an application from the SaaS CA API Developer Portal.

If your current OTK version is 3.x, then you need to manually uninstall and re-install your OTK to be upgraded to OTK v4.3. If your current OTK version is 4.x, then you can use the upgrade button to upgrade your OTK to v4.3. Unfortunately, due to some defects with the OTK, some manual configuration after the auto upgrade is required. Please check my other blog post entitled “Layer 7 Gateway OTK Upgrade” for details.

After the upgrade, the SaaS CA API Developer Portal will still not work properly due to a defect in the current Portal Application Sync Policy Fragment. In this fragment, it will try to make a JDBC query first and if it fails then it will rely on OTK Assertion to make the NoSQL query to the Cassandra DB. Unfortunately, the OTK Assertion returns the request in the wrong context variable, which breaks the workflow.

The fix is simple - add a context variable to assign the value of ${apiKeyCount} to variable ${apiKeyCount.count}

Add a Context Variable

Add a Context Variable

4- To avoid having the SaaS CA API Developer Portal push data to the CA API Gateway and break the API Gateway runtime traffic, the communication between the CA API Gateway and SaaS CA API Developer Portal occurs by having the CA API Gateway pull information from the CA API Developer Portal. Therefore, to sync any configuration or modifications from the Portal to the Gateway, it requires the API Gateway to make outbound calls.

In most enterprise environments, outbound calls usually require a secure proxy, otherwise it will be blocked by the firewall. Here are a few things we need to know about the proxy configuration:

a- You need to configure a global proxy for the registration URL to work and you can disable/delete that global URL after registration. However, you need to enable/add the global proxy again when you run Portal Upgrade Tasks.

CA API Gateway - Policy Manager

CA API Gateway - Policy Manager

b- The outbound proxy will only work with “Automatic” and “Scripted” deployment. “On-Demand” deployment type is NOT supported for proxy settings. Because for “On-Demand” there is a portal deployer module running on the background to sync APIs from SaaS Portal to API Gateway. That module is not configurable by API Gateway admins and it will make an websocket call to SaaS Portal where proxy setting cannot be added.

Add API Proxy

Add API Proxy

c- You need to update every routing assertion inside Portal services to manually add a proxy configuration. Here is a list of service you need to change and add proxy to:

Move Metrics Data Off Box

Portal Application Sync Fragment

Portal Bulk Sync Application

Portal Check Bundle Version

Portal Delete Entities

Portal Sync Account Plan (Two routings needs to be edited)

Portal Sync API (Two routings needs to be edited)

Portal Sync API Plan (Two routings needs to be edited)

Portal Sync Application

Portal Sync Fragment

Portal Tenant Sync Policy Template

API Portal SSO SAML Validation Service Fragment

Portal Sync SSO

            For example:

HTTP Routing Properties

HTTP Routing Properties