AZ-500-Microsoft Certified: Azure Security Engineer Associate-Day-5

Published in

FAUN — Developer Community 🐾

7 min readJun 2, 2020

— — — — — — — — — — — — — — — — — — — — — —
Module-1-Secure your cloud applications in Azure
— — — — — — — — — — — — — — — — — — — — — —

Sub-Modules
— — — — — — — — — — — — — — — — — — — — — — — — — —
Control authentication for your APIs with Azure API Management
— — — — — — — — — — — — — — — — — — — — — — — — — —

- Introduction

Azure API Management enables you to carefully identify and control who can access the data published by your APIs.

Suppose you work for a meteorological company, which has an API that customers use to access weather data for forecasts and research. There is proprietary information in this data, and you would like to ensure that only paying customers have access. You want to use Azure API Management to properly secure this API from unauthorized use.

In this module, you will use two different methods to secure access to an API in Azure API Management:

-Subscriptions

-Client Certificates

- What is API Management?

APIM provides the core competencies to ensure a successful API program through developer engagement, business insights, analytics, security, and protection. You can use APIM to take any backend and launch a full-fledged API program based on it.

Common scenarios include:

Securing mobile infrastructure by gating access with API keys, preventing denial of service attacks (DoS) by using throttling, or using advanced security policies like JSON Web Token (JWT) validation.
Enabling independent software vendor (ISV) partner ecosystems by offering fast partner onboarding through the developer portal, and building an API facade to decouple from internal implementations that are not ready for partner consumption.
Running an internal API program by offering a centralized location for the organization to communicate on a secured channel between the API gateway and the backend about the availability and latest changes to APIs, and gating access based on organizational accounts.

Components of API Management

API gateway

Accepts API calls and routes them to the backend.
Verifies API keys, JWT tokens, certificates, and other credentials.

Azure portal

Define or import API schema.
Package APIs into products.

Developer portal

Read API documentation.
Try out an API via the interactive console.

- Create subscriptions in Azure API Management

When you publish an API with APIM, you define who can access the API through the gateway.

For your meteorological app, you want to ensure that only customers who have subscribed to your service can access the API and use your forecast data, by issuing subscription keys.

- Subscriptions and Keys

You can choose to publish your APIs and the information they contain for free but usually, you want to restrict access to users who have paid or organizations with which you have a working relationship. You can control access to your APIs by using a subscription.

Subscriptions are used to segment the access levels to an API.

Subscription keys form the authorization to enable access to these subscriptions.
Whenever a client makes a request to a protected API, they must include a valid subscription key in the HTTP request or the call will be rejected.

A subscription key is a unique auto-generated key that can be passed through in the headers of the client request or as a query string parameter.
The key is directly related to a subscription, which can be scoped to different areas. Subscriptions give you granular control over permissions and policies.

The three main subscription scopes are:

All APIs
Applies to every API accessible from the gateway
Single API
This scope applies to a single imported API and all of its endpoints
Product
A product is a collection of one or more APIs that you configure in API Management. You can assign APIs to more than one product. Products can have different access rules, usage quotas, and terms of use. So if you want your partners and suppliers to have different access rights to your WeatherData API, assign the API to a product. You use the Azure portal to associate APIs with a product.

Applications that call a protected API must include the key in every request.

You can regenerate these subscription keys at any time, for example, if you suspect that a key has been shared with unauthorized users.

- Call an API with the subscription key

Applications must include a valid key in all HTTP requests when they make calls to API endpoints that are protected by a subscription. Keys can be passed in the request header, or as a query string in the URL.

The default header name is Ocp-Apim-Subscription-Key, and the default query string is subscription-key.

To test out your API calls, you can use the developer portal, or command-line tools, such as curl. Here’s an example of a GET request using the developer portal, which shows the subscription key header:

Here’s how you can pass a key in the request header using curl:

curl — header “Ocp-Apim-Subscription-Key: <key string>” https://<apim gateway>.azure-api.net/api/path
Here’s an example curl command that passes a key in the URL as a query string:

curl https://<apim gateway>.azure-api.net/api/path?subscription-key=<key string>

If the key is not passed in the header, or as a query string in the URL, you’ll get a 401 Access Denied response from the API gateway.

Use client certificates to secure access to an API

Certificates can be used to provide TLS mutual authentication between the client and the API gateway.

You can configure the API Management gateway to allow only requests with certificates containing a specific thumbprint. The authorization at the gateway level is handled through inbound policies.

For your meteorological app, you have some customers who have client certificates issued by a certificate authority that you both trust. You want to allow those customers to authenticate bypassing those certificates.

Here, you will learn how to configure API Management to accept client certificates.

TLS client authentication

With TLS client authentication, the API Management gateway can inspect the certificate contained within the client request and check for properties like:

Certificate Authority (CA) Only allow certificates signed by a particular CA

Thumbprint Allow certificates containing a specified thumbprint

Subject Only allow certificates with a specified subject

Expiration Date Only allow certificates that have not expired

Accepting client certificates in the Consumption tier

The Consumption tier in API Management is designed to conform with serverless design principals. If you build your APIs from serverless technologies, such as Azure Functions, this tier is a good fit. In the Consumption tier, you must explicitly enable the use of client certificates, which you can do on the Custom domains page.

Certificate Authorization Policies

Create these policies in the inbound processing policy file within the API Management gateway:

Check the thumbprint of a client certificate

Every client certificate includes a thumbprint, which is a hash, calculated from other certificate properties.
The thumbprint ensures that the values in the certificate have not been altered since the certificate was issued by the certificate authority. You can check the thumbprint in your policy. The following example checks the thumbprint of the certificate passed in the request:

___________________________________________________________________

<choose>
<when condition=”@(context.Request.Certificate == null || context.Request.Certificate.Thumbprint != “desired-thumbprint”)” >
<return-response>
<set-status code=”403" reason=”Invalid client certificate” />
</return-response>
</when>
</choose>
___________________________________________________________________

Check the thumbprint against certificates uploaded to API Management

___________________________________________________________________

<choose>
<when condition=”@(context.Request.Certificate == null || !context.Request.Certificate.Verify() || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))” >
<return-response>
<set-status code=”403" reason=”Invalid client certificate” />
</return-response>
</when>
</choose>
___________________________________________________________________

Check the issuer and subject of a client certificate

__________________________________________________________________

<when condition=”@(context.Request.Certificate == null || context.Request.Certificate.Issuer != “trusted-issuer” || context.Request.Certificate.SubjectName.Name != “expected-subject-name”)” >
<return-response>
<set-status code=”403" reason=”Invalid client certificate” />
</return-response>
</when>
</choose>
___________________________________________________________________

Thank You!