Hi folks,

I often get security-related questions from customers evaluating the Azure AD App proxy for the first time. And I’ve noticed that lot of these questions betray a more traditional outlook towards providing remote application access. These traditional mechanisms to offer remote access have typically involved installation of costly servers on-prem. And because there was unauthenticated traffic arriving at the customer network, these approaches have required careful analysis of access patterns and the deployment of additional security infrastructure like WAF servers, with the added cost of installing, maintaining, monitoring and patching them.

Azure AD app proxy, on the other hand, offers ‘remote access as a service’ and takes a different approach. In this context, therefore, the evaluation process of the solution warrants a rethink. And I’d assert that a lot of the pain associated with the traditional approaches can be side-stepped.

In today’s post, Ross Adams (a Senior PM on the team) and I decided to tackle the topic of security in the context of remote application access. The goal here is to provide you and your security teams enough context to understand how Azure AD app proxy provides a secure service for publishing and accessing your applications. And how different capabilities of Azure AD come together to offer a very secure remote access solution.

A different approach—with great security benefits

When evaluating the security of the remote access solution offered by Azure AD app proxy, it is useful to keep the following in mind:

• Authenticated access: Only authenticated connections hit your network
  • Azure AD app proxy is best suited to publish applications with pre-authentication. Azure AD app proxy relies on the Azure AD STS for all authentication. For applications published with pre-authentication, no traffic is allowed to pass through the app proxy service to your environment, without a valid STS token
  • Pre-authentication, by its very nature, blocks a significant number of anonymous attacks, as only authenticated identities are allowed to access the backend application.
• Conditional Access: Richer policy controls can be applied before connections to your network are established
  
  • With conditional access, it is also possible to further define restrictions on what traffic is allowed to hit your backend application. With conditional access, you can define restrictions based on location, strength of authentication and user risk profile.
  • This offers further stumbling blocks for attackers. You can read more about conditional access here.
• Traffic termination: All traffic is terminated in the cloud
  • Since the Azure AD application proxy is a reverse-proxy. All traffic to the backend application is terminated at the service. And the session is re-established with the backend server. This means that your backend servers are not exposed to direct HTTP traffic and targeted attacks like Heartbleed can be mitigated.
• All access is outbound: No inbound connections need be opened to the corporate network
  
  • The connectors maintain outbound connections to the Azure AD App proxy service. This means there is no need to open firewall ports for incoming connections.
    
  • On the other hand, traditional approaches required a DMZ and opening access to unauthenticated connections at the network edge. This resulted in the need for lot of additional investment in WAF products to analyze traffic and offer addition protections to the environment.
    
  • With app-proxy you can avoid this and even do away with your DMZ as all connections are outbound and over a secure channel.
    
• Security Analytics and ML based intelligence: New-age security protection
  • Azure AD Identity Protection combines Machine-Learning driven security intelligence with data feeds from Microsoft’s Digital Crimes Unit and Microsoft Security Response Center to proactively identify compromised accounts and offers real-time protection from risky sign-ins. This takes into account factors like accesses from infected devices, or through anonymizing networks, or from atypical and unlikely locations to increase the risk profile of a session, which in turn is used for real-time protection.
  • Many of these reports and events are already available through an API for integration with your SIEM systems.
  • You can read more about Azure AD Identity Protection here.
• Remote access as a service: You don’t have to worry about maintaining and patching on-prem servers
  
  • The Azure AD app proxy is an internet scale service that we own ensuring is always patched with the latest security patches and upgrades, so you don’t have to worry about it.
  • Unpatched software still accounts for a large number of attacks. With the service model, you don’t have to carry the heavy burden of managing these edge servers anymore and scramble to patch them as needed.

Additionally, as part of any evaluation of a cloud service there’re the obvious questions around how data is handled and secured in our data centers and operational environments. AAD AP, as part of the Azure set of cloud services, operates in accordance with the guidelines and standards that are outlined in the Azure Trust Center.

Evaluating the security of the app proxy solution:

A lot of security teams desire a deeper look at how the solution works.
The information below is provided to help you and your security teams understand how the AAD AP service provides a secure mechanism for publishing your applications.

Components of the solution:

Azure AD Application proxy can be logically broken into two parts:

1. The cloud based service (AAD AP) where most of the work is performed and to which external client/user connections are made.
2. An on-premises component called the AAD App Proxy connector, or ‘connector’ for short.  This connector listens for requests from the AAD AP service and handles connections to the internal applications, including taking care of items such as KCD (Kerberos Constrained Delegation) for SSO.

Different traffic flows—and how each is secured

There are a number of flows between the connector and the AAD AP service, each of which is detailed further below with a description of how these flows are secured.

1. When a connector is first setup
2. The connector periodically pulls configuration information from the AAD AP service. (Eg: the connector group the connector is part of)
3. When users access a published application

It is important to note that all communications occur over SSL, and always originate at connector to the AAD AP service, i.e. are outbound only.  The connector uses a client certificate to authenticate to the AAD AP service for all calls. The only exception to this is the initial setup step where the client certificate is established.

Installation of the connector

1. During install (connector registration to the service, happens as part of the install) of the connector, the user is prompted to enter their AAD admin credentials.  The token acquired is presented to the Azure AD App Proxy service (AAD AP).
2. AAD AP then evaluates the token to ensure that the user is a member of the company admin role within the tenant the token was issued for.  [If not, the process is terminated.]
3. The connector then generates a client certificate request and passes this with the token to the AAD AP service that in turn verifies the token and signs the client certificate request. The connector then uses this client certificate for future communication with the AAD AP service.
4. The connector then performs an initial pull of the system configuration data from the AAD AP Service using its client certificate and is ready to take requests.

Regular updates of configuration

1. The connector connects to the configuration end point within the AAD AP service using its client certificate.
2. Once the client certificate has been validated, the AAD AP service returns configuration data to the connector such as the connector group that the connector should be part of.
3. The connector will generate a new certificate request if the current certificate is more than 30 days old, effectively rolling the client certificate every 30 days.

Accessing a published application

1. When a user accesses a published application, the AAD AP service checks the configuration of the application.  If the application is configured to use Pre-Authentication with AAD the user will be redirected to the AAD STS to authenticate.  This is skipped in case the application is published using pass through.
   1. During authentication with AAD, AAD will check for any conditional access policy requirements for the specific application and ensures the user has been assigned to the application. (for example, if MFA is required the authentication sequence will prompt the user for a second factor authentication)
   2. Once all checks have passed, the AAD STS will issue a signed token for the application and redirect the user back to the AAD AP service.
   3. AAD AP will then validate the token to ensure that it was issued to the application that the user was requesting access to, along with other checks, such as ensuring the token was signed by AAD, is still within the valid window etc.
   4. AAD AP then sets an encrypted authentication cookie (i.e. a non-persisted cookie) to indicate that authentication to the application has occurred.  This cookie includes expiration timestamp based on the token from AAD and other data such as the user that the authentication is based on.  This cookie is encrypted using a private key known only to the AAD AP service.
      
   5. AAD AP then redirects the user back to the originally requested URL.
      

   NOTE: If any part of pre-authentication steps fails, the user’s request is denied and the user is shown a message indicating the source of the problem.

2. AAD AP upon receiving the request from the client validates that the pre-authentication condition has been meet and that the cookie is still valid (as required) and puts a request on the appropriate queue for an on-premises connector to handle.  (Remember, all requests from the connector are outbound to the AAD AP service. Connectors keeps an outbound connection open to AAD AP. When a request comes in, the app proxy queues up the request on one of these open connections for the connector to pick up)
   

   This request includes such items as the application, the headers of the request and data from the encrypted cookie such as the user making the request and a request id.  The encrypted authentication cookie is not sent to the connector.

3. The connector picks up the request from the queue, based on a long lived outbound connection and will do one of the following based on the request.
   1. The connector confirms it knows the application, if not, the connector will establish a connection to the AAD AP service to gather the details of the application and cache this locally.
   2. If the request is a simple operation where there is no data within the body such as a “get”, the connector will make a connection to the target internal resource and await the response.
   3. If the request has data associated with it in the body, for example a “post” operation, the connector will make an outbound connection using the client certificate to the AAD AP instance to request the data and open a connection to internal resource.  Upon receipt of the request from the connector, the AAD AP service begins accepting content from the user and forwards this on to the connector.  The connector, in turn, then forwards this data to the internal resource.
4. Once the request/transmission of all content to the backend is complete the connector waits for a response.
5. Once a response is received the connector then makes an outbound connection to the AAD AP service to return the header details and begins streaming the return data.
6. AAD AP then “streams” the data to the user.  (Some processing of the headers may occur here as needed and defined by the application).

We hope this level of detail helps your organization evaluate the Azure AD app proxy more efficiently and effectively. As always if you have any questions, comments or feedback, please feel free to reach us at aadapfeedback@microsoft.com

Girish Chander

Identity, Microsoft.

@chander_girish