Authentication and Authorization

One of the capabilities that can be added to an application by the Service Gateway is Authentication (AuthN) with Azure Active Directory (AAD) as well as certain levels of Authorization (AuthZ). Using the Service Gateway to apply these capabilities (especially AuthN) makes sense as this is a shared service across the multiple Roles exposed by the Gateway. It also relieves each role of the necessity to integrate with (sometimes complex) authentication libraries and frameworks, thus making AuthN integration truly turnkey.


Authentication integration in the Gateway is achieved using Azure Active Directory as a Secure Token Service (STS) and default Identity Provider (IdP) which, in turn, is capable of federating with other IdPs to allow user identities from a wide range of systems.

One great advantage of integrating with AAD is the capability of Single Sign-On (SSO), such that when a user logs on to a different application eg. Office 365, the same identity will be automatically used when authenticating to the Gateway, thus eliminating repeated credential challenges.

Cloud identity services rely on identifying not only the user wishing to log on, but also the application that they are attempting to log on to. Identifying the application increases the security of the user's credentials and identity as well as providing a secured channel to reply to a sign-on request with a valid authentication token. Without this knowledge, identity management systems would be vulnerable to various security attacks.

A full description of enabling SSO for single-tenant and multi-tenant applications is provided here: Adding Sign-On to Your Web Application Using Windows Azure AD on MSDN.

Registering the Gateway for AAD Authentication for Single-Tenant Usage

As described in the above MSDN article in the section Register a New Application, an application may be registered for usage when only users belonging to a single AAD tenant will attempt to log on. Following the steps in this section, a new application may be created by a tenant admin specifying Single Sign-On as the required access. The App URL and App ID URI values are important:

  • The App URL value must specify the address of the Gateway, once deployed. This is the address that AAD will reply with the authentication token once the user has logged on.
  • The App ID URI must uniquely identify the application to AAD. Generally, the App URL value will work fine here. This is the value that must be specified in the ApplicationName configuration attribute.

For single-tenant access, the Directory configuration attribute must specify a registered domain name in the directory of the users attempting to log on.

Registering the Gateway for AAD Authentication for ISV Usage

Independent Software Vendors (ISVs) provide cloud application as multi-tenanted applications with more that one customer using the same service or application. AAD provides a specific mechanism to enable users from more than one tenancy to sign-on to a single application. The MSDN article Developing Multi-Tenant Web Applications with Windows Azure AD describes this mechanism.

In the above article, special attention should be paid to the section Promoting the Application Entry in Windows AD to be Externally Available which talks about constraints on the App ID URI value. When configuring multi-tenanted authentication for the Gateway, the ApplicationName configuration value will be the App ID URI value as per the single-tenanted configuration, but the Directory value no longer refers to the directory of the user attempting to log on, but instead is the directory name of the ISV configuring the Gateway.

In the same MSDN article, the Add Sign-Up Capabilities to the Application section describes how tenant administrators for new customers must provide consent to enable the application to log on users for that tenant. This is a one-time administrative process that may be included as part of the provisioning workflow of the application or may be part of manual onboarding instructions.


The Gateway provides a light-weight authorization mechanism which enforces the authentication requirements of users to certain parts of roles (identified as URL paths) which allows other parts of a role to allow anonymous access. This is typical of a home or landing page that will present information to users before they log on. Once a user navigates to a path of the application that requires authentication, the standard AAD sign-on flow will automatically commence (if they have not already signed on to this or another AAD integrated application). The user will be prohibited access to the resource if they do not successfully authenticate.

Last edited Dec 6, 2013 at 2:03 AM by jamesbak, version 2