Full Azure API Management suite and more VSTS extension
This software is provided as-is with no warranty of any kind.
The purpose of this extension is to bring Azure API Management into VSTS as part of your release lifecyle. Whether you use API Management to monetize APIS or for internal purposes, it is good to associate the release of your backends APIs with their corresponding facade APIs published against the API Gateway. On top of the API Management integration, the extension also ships with an API Security Checker that helps validating that all endpoints of an API are well secured, this is of course only applicable to non-public APIs.
- New task to import legacy services from WSDL: SOAP Pass-Through and SOAP to REST. Author: Luis Ruiz Pavon
- Minor improvements in the policy templates
- Product creation task revisited to with visibility rules
- Support of OAuth2 servers and OpenID Connect integration. Note that if you double check the authorization settings in the portal, you might need to refresh the page multiple times before it gets rendered correctly.
The below features were added.
- Versioning Scheme (Segment, Query String, HTTP Header)
- Inline Swagger and Swagger as a build artifact
- API Suffix
- Switched the input type from "string" to "multiline" for policies
- Added a new policy of type "custom"
Update of the documentation.
- Supports versioned APIs
- Creation of API products on the fly
- Supports both API and Product policies
- Supports the creation of APIs on top of Azure Functions
- API Security checker
In order to use this extension, you must have an ARM Service Endpoint configured in VSTS and make sure this endpoint is allowed to contribute to API Management instances. This can easily be done by granting Subscription Contributor role or the ad-hoc API Management Service Contributor role. Similarly, the endpoint should have access to the Azure Functions should you plan to use the tasks related to Azure Functions.
Depending on your usage of API Management, some extra considerations should also be paid attention to. If your backend APIs are part of a dedicated VNET, make sure the VSTS agents have connectivity to them. In case you provide a web URL for the Swagger definition, the extension makes use of Swagger import and downloads the Swagger definition of the backend API. Therefore, connectivity between the VSTS agent and the target API is required. If you do not have such connectivity, you should fallback to in-line Swagger (provided as a piece of text) or a Swagger from file provided as a build artifact. For the latter, you might want to use a Config Transformation task as part of your release definition in order to inject the right API host as shown below:
where in this case, the APIHost variable is defined as a enviromnment-scoped release variable.
A few tasks allow to set policies at product and/or API level. They come with some pre-defined policies which you can override to adjust them to specific needs. You can easily use other policies by getting the default boilerplate config from the APIM Portal.
This task allows you to create a new product or update an existing one. The following screenshot illustrates the task:
Where parameters such as approval required and subscription limits may be defined as well as more advanced policies using one of the provided policies or a custom one.
This task allows you to create a new Gateway API or update an existing one, against backend APIs.
where you reference the Swagger location as well as the API suffix and optionally a policy that governs the API such as a JWT validation policy.
This task allows you to create a new Versioned Gateway API or update an existing one, against backend APIs. The reason why versioning has been put in a separate task is to make it clear for the VSTS Release Managers and to be compliant with the old way of working with APIM which did not support versioning in the past.
Note that you can create gateway APIs based on WSDL files.
where you may also define the versioning scheme.
This task allows you to create a new Gateway API or update an existing one, against Azure Functions that are protected with a code in the Function URL. For each and every function, a corresponding API Operation is created with a specific policy that injects the function's secret as a querystring parameter.
where the only thing you have to do is to map the new API you create with the target function site.
Same as above but in a versioned way.
This very basic task parses the Swagger definition of an API (or MVC apps) to check whether all the exposed endpoints are secured. Every return code that differs from 401 or 302 (redirection to the login page) are marked unsafe. If at least one unsafe endpoint is discovered, the task fails to complete and all the tested endpoints appear in the logs.
Since this task needs to call the target API, the only way to provide the swagger definition is via its URL. If the Swagger endpoint is protected via a key, just provide it as part of the URL.