Certificate exchange allows Azure API Management and an API to create a trust boundary based on encryption that is well understood and easy to use.

In this scenario, because Azure API Management is communicating with an API that has been provided, a self-signed certificate is allowed as the key exchange for the certificate is via a trusted party.

For an in-depth discussion on how to configure mutual certificate authentication to secure your API, please refer to the Azure API Management documentation ( https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/ ).

If an enterprise already uses Azure Active Directory to provide single or same sign-on to cloud-based services, for instance, on-premises Active Directory synchronization via ADConnect , then this provides a good opportunity to leverage Azure Active Directory to provide a security and trust boundary to on-premises API solutions.

For an in-depth discussion on how to add Azure Active Directory to an API Management instance, please see the Azure API Management documentation ( https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-protect-backend-with-aad/ ).

Another way of providing a security boundary between Azure API Management and the API is managing the creation of a VPN.

A VPN creates a tunnel between the corporate network edge and Azure, essentially creating a hybrid cloud solution. Azure API Management supports site-to-site VPNs, and these are created using the Azure Classic Portal.

If an organization already has an ExpressRoute circuit provisioned, this can also be used to provide connectivity via private peering.

Because a VPN needs to communicate to on-premises assets, a number of firewall port exclusions need to be created to ensure the traffic can flow between the Azure API Management instance and the API endpoint. These are shown in the following table: only those ports relating to APIs on-premises need to be opened, not all the ports in the table.