Azure API Management - Who's calling?
API Management is one of the lesser explored areas of Azure. Regardless, it's a very powerful service to layer onto your service to add:
- Governance
- Throttling
- Analytics
- Authentication
- developer documentation
- And more stuff
… just like that. It's a fantastic example to illustrate how Azure can take care of the work that's not as interesting as the code that your boss wants you to write to add new features to your service.
Since I've been playing with it a little bit on behalf of a few service providers now, I thought I share some of my learnings. So here we go.
Imagine you have an internal service API you'd like to expose to the rest of the world over the big, bad internet - securely.
Azure and API Management make this daunting task a rather simple endeavor. Yes. Really! Secure … as in security infrastructure for DDoS prevention, Intrusion detection, etc. are in place, as well as application security like authentication and authorization. All that without running a single cable or having to punch holes in your firewall.
Security Infrastructure
API Management avoids you having to expose your service to the internet directly. Instead, it provides your endpoint on the internet, which runs in Azure and therefore piggy-backs on the defense mechanisms in place for all Azure services. You connect your Azure API to your internal service via a secure VPN or an ExpressRoute connection, which means your server is not directly exposed to the internet. If you don't want to or you can't set up a VPN connection, you could also make your service listen on a queue and then layer API management in front of the queue - which will be the topic of the of the next post.
Authentication / Authorization
Now what about letting only known users use the API? It's an internal API … It's probably not built for OAuth or SAML authentication. API Management will help you avoid writing authN or authZ code as well. First off, you secure the API with an access token, which maps to a user in the management portal. You can also assign group memberships to those users. Those groups can be handy to implement authorization in your code, since you can check groups or roles fairly easy.
API Management can do the translation from user to group using policies, which means you don’t have to change your API. Authorization can occur using HTTP headers. Policies can translate the API Management user and its groups into an HTTP header. For example, this policy will add a header with the username of the user associated with the certification used to authenticate the call:
<set-header name="X-User" exists-action="override">
<value>
@(context.User.Email)
</value>
</set-header>
While this policy will construct a string listing the user's group memberships:
<set-header name="X-User-Groups" exists-action="override">
<value>
@(string.Join(";", (from item in context.User.Groups select item.Name)))
</value>
</set-header>
Your API implementation can now check these headers to authorize against your group system, e.g. Active Directory without having to change API methods and their implementation.
If you really wanted to, you could also add policies to modify the actual API call with a set-body policy. We'll explore that policy in the next post.
Policies
Both policies were written using single-line .NET expressions and the context object provided by the policy engine. The policy can work with a subset of .NET classes and most language constructs. As you can see above, even Linq queries work.
You can even write complex multi-line .NET expressions, which will be part of the examples in the next article.