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.