Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Thursday, February 9, 2017 4:00 PM

Massimo Crippa by Massimo Crippa

In Azure API Management, Groups are used to manage the visibility of products to developers so the developers can view and consume the APIs that are contained into the groups in which they belong.

Suppose that we have a custom group for developers affiliated with a specific business partner and we want to allow those developers (that signed up with different identity providers) to access only to the partner's relevant Products.

Let's combine Logic Apps, Azure API Management and ARM together to automate the user group association.

In short: no matter what which identity provider (AAD, Google, Twitter, etc..) is used to sign up, when the user belongs to the domain it should be added to the "Codit Dev Team" custom group.

The basic idea here is to use logic apps as a batch process to get the list of registered users and then call a child logic app to assign the current developer to a proper custom group to manage the product visibility.

Logic Apps and Azure API Management

There are three ways to invoke an API Management endpoint from a Logic App:

  • API Management connector. The connector is pretty straightforward. You first select an APIM tenant, the API and then the operation to be called. Finally, the available headers and parameters are automatically displayed. The APIM connector by default shows only the APIM tenants created in the same subscription where the Logic App was created. 
  • Http + Swagger connector. This connector provides a similar user experience as the APIM connector. The shape of the API with the parameters are automatically integrated in the designer.
  • Http connector. It requires to specify HTTP verb, URL, Headers and Body to perform an HTTP call. Simple as that!

In this exercise, all the services that had been integrated are located in different Azure subscriptions therefore I used only Http and Http+Swagger connectors.

Manage 'em all

With the "Every API should be a managed API" mantra in mind and with the final goal to have a more information about which API is called and its performance we created a facade API for every HTTP call.

Here the list of managed APIs:

  • Every call to the Azure Resource Manager (get users, get groups by user, add user to group)
  • Get the token to authorize the ARM call
  • Call the child Logic App

And here the Logic App workflows that had been created. 

Some other benefits we got from the virtualization: 

  • Use of a single authorization model between Logic App and APIM by providing an API Key via the "Ocp-Apim-Subscription-Key" header.
  • Balancing complexity and simplicity. The ARM authentication is delegated to the API Management layer.
  • Apply a consistent resource naming convention. 

Azure API Management Policies

The policy engine is where the core power of Azure API Management lies. Let's go through the policies that have been configured for this exercise. 

Get the bearer token

A token API with a GET operation is used by the ARM facade API to get the bearer token to authorize the call to Azure Resource Manager endpoint. The policy associated to the "get-token" operation changes the HTTP request method and sets the body of the request to be sent to the AAD token endpoint using the password flow.

Call the ARM

This is the call to the ARM endpoint (get users, get groups by user, add user to group). The "send-request"-policy is used to perform a call to the private token API and to store the response in the bearerToken context property.

The "set-header" policy in combination with a policy expression is used to extract the token and to add it as a header to the request sent to the ARM endpoint.

This policy can be improved by adding the policy expressions to store and retrieve the token from the cache. Here an example. 

Logic Apps facade API

The Logic Apps workflows that expose an HTTP trigger call can be called by using the POST verb only and passing the parameters in the body of the request.

The child workflow that takes care to assign a user to a specific group has been virtualized via Azure API Management to change the URL segments as here{uid}/groups/{groupname} and to change the request method to PUT.


Thanks to this simple Logic App and some APIM power I can now be sure that every new colleague that sign up to our developer portal is automatically associated to the internal developer team so that he/she can get access to a broader set of APIs.

A similar result can be achieved using the Azure B2B/B2C integration in combination with the AAD security groups but, at the time of writing, the APIM integration with AAD B2C has not been completed yet.

Another benefit of managed APIs is the gain of visibility of the exposed assets and their performance. Discover how an API is used, information about the consumer and be able to discover the trends that are most impacting the business.



Categories: API Management
Tags: Azure
written by: Massimo Crippa

Posted on Tuesday, April 14, 2015 4:30 PM

Massimo Crippa by Massimo Crippa

The Azure API Management Portal allows API Publishers to set policies to change the behavior of the underlying API by configuration.
The Policies act like a pipeline that executes a set of conditions or rules in a sequence. Policies contain configurable rules for authentication, validation, quota and IP level restriction, caching and more.
The Microsoft Product team is constantly adding features to the service, recently conditional policies have been added.

Policies overview

Policies can be applied at different scopes (Global, Product, API, and Operation), some are allowed only on the inbound channel, some others on the contrary only on the outbound.

The table summarizes the policies as today with their scope and the applicability.

The Policies that are defined at different scopes are then pulled from the higher level to the lowest through the “<base/>” element and flattened to a single policy definition that executes the steps in a sequence.

Here the definition of the policies I setup for this blog post and the effective result per scope.

Conditional policies

On April 10th conditional policies have been rolled out:

  • Policy expressions. C#-based expressions that can be used as values in policy attributes and elements. 
  • Control flow policy. That's an if-then-else construct to conditionally apply policies based on the evaluation of logical expressions.
  • Set variable policy. Use this policy to store a computed value for later re-use within the scope of a single request.
  • Set backend service policy. To override the backend service URL.

The conditional policies bring flexibility to the API Management policy engine enabling the definition of more complex complex rules like evaluate headers in the inbound pipeline, save it in the context and then, based on that properties, take decisions on the outbound channel. 

In the very basic example below I combined these 4 new policies in a single policy definition to route the request message to different endpoints depending on the datetime millisecond.

Test and analyze the trace

To test the policy definition I used the API management built-in console and I added the "ocp-apim-trace:true" header to the operation call to enable the API inspector.

The trace location is returned in the response ocp-apim-trace-location header which can be used to download the json data to inspect the execution.

Here I got the json using fiddler and then the online json visualizer to easily inspect the trace, check the policy execution and the debug messages.


With the Azure API Management policies you gain the ability to protect, transform and to modify the underlying behavior of the virtualized backend service.

The April service update and the conditional policies brought more flexibility and power to the policy engine.





Categories: Azure, API Management
written by: Massimo Crippa