The Developer Portal stands as a critical subsystem within API Connect, facilitating API Developers' interaction with API Catalogs through an array of technical and collaborative tools. API Developers leverage the Portal for tasks such as API discovery, documentation review, plan subscription, API testing, and issue discussion. To extend access to the Developer Portal for 3rd-party partners, it is common to implement a Web Application Firewall (WAF) that securely exposes the Portal to the internet. This week, a client approached me, expressing interest in exploring the "Defining multiple portal endpoints" feature available on the VMware form factor.
I conducted experimentation on a VMWare-based API Connect stack to evaluate this feature. Initially configured with a single portal-www endpoint, I followed the provided instructions by introducing an extra values file, incorporating three new endpoints. For simplicity, I set all three as aliases to the same portal VM IP address. The system required approximately 5 minutes to reconcile the changes, after which the new endpoints were operational.
To my surprise, I discovered that access to the original Developer Portal Site resulted in an HTTP 404 error, indicating a deviation from its prior functioning state. Evidently, the portal-www endpoints specified in the extra values file superseded the portal-www endpoint in the apiconnect-up-v10.yml file.
Subsequently, I proceeded to configure a new Portal Site. The original behavior, where a single www-portal endpoint was provided based on API Manager selection, persisted. However, the system continued to present the original portal-www endpoint, which was not part of the extra values file. While creating a site with the original endpoint was successful, it remained inaccessible. Conversely, creating a site with a new endpoint proved successful, and the site was accessible.
In summary, this feature represents an integrate capability within API Connect, enabling API developers to access the Developer Portal via distinct endpoints from diverse network segments. Consequently, the same Developer Portal subsystem becomes accessible through endpoints such as ICN (https://developer.int.company.com) and DMZ (https://developer.ext.company.com), catering to different network requirements.
Several considerations must be taken into account when planning the implementation of multiple portal endpoints within an existing API Connect instance. Primary among these considerations is the decision regarding the existing endpoint – whether it should be decommissioned or retained as one of the endpoints. The potential implications of endpoint decommissioning on existing portal users warrant careful evaluation. Additionally, discussions should address the new endpoints' IP addresses, corresponding network segments, and the requisite measures to secure access from untrusted networks, ensuring the overall system's security.
References:
Defining multiple portal endpoints for a VMware environment (API Connect v10.0.5.x)