Many of you have said that you have business logic/API either running on premise or somewhere hosted in Virtual Machines across the cloud. These native apps often run on iOS/Android/MAC/.NET and need to interact with the API endpoints to make use of the data or provide a way of user interaction. This is a scenario that is also supported with Azure AD Application Proxy. As with other solutions supported with the Application Proxy, this lets you move from scenarios where you would need to open firewall ports and control authentication and authorization at the app layer (Figure 1 below) to a faster and more secure solution which also allows additional security through Azure AD premium features like Multifactor Authentication, Device Based Conditional Access for Desktops, iOS/MAC and Android devices using Intune (Figure 2 below).

Figure 1: A typical way to publish you on premise resources.

Figure 2: Securely Publish your APIs using the Azure AD App Proxy without requiring any incoming ports.

The Overall Solution

The Azure Ad Application Proxy forms the core backbone of the entire solution working as public endpoint for API access, providing Authentication and Authorization. You could access all your API’s from a vast array of platform using the ADAL Libraries. To give an overview of this solution, I'll walk through a demo.

For the Demo lets assume we are hosting an API service on premise.

Sample Rest Response

Publish the API using the App Proxy

Let’s drill into how you can publish this API. It is follows the same pattern as publishing web applications.

Step 1: Ensure the Pre-Authentication is set to Azure Active Directory.

Step 2: Hide the application from end users

Since this is an API you do not want this to be available in the MyApps Panel to your end users, set the "Visible to users?" option to "No".

Step 3: Configuring the Authorization, select users and group who can access this application.

As with any other application, you will need to assign users to the application.

With the above three steps you should have your API published outside of the intranet through the Application Proxy.

Note: There might be additional steps required if your API is protected with Windows Integrated Auth

Configuring Native App Registration and Granting Access

Native applications are program developed for use on a particular platform or device. Before the App can connect and access the API you would need to registger App in Azure. For the next step will walk you through the to register App and configure access to the API published above.

More details can be found here

Step 1: Native App Registration: Create a new App Registration

Step 2: Grant Access to the API published (in the previous step)  via Application Proxy 

Configuring the Native Application Parameters

Last step is to identify and configure the Native Application.

Step 1: Click on App Registrations  

Step 2: Drill into the application you just created and capture the App ID URI

The Native App uses the header to attach the bearer token for the request for making call to the API.The below snippet uses the ADAL Library to aquire token and attach it as Bearer to the Header. A sample web app and Native App can be found here

The App configuration requires you to supply in the values from the above screen-shots.

Once the parameters are configured, you can try the application and confirm that the Native App was successfully able to access the API hosted on-premises.

Conclusion

Now we can have Native Apps that are .Net/IOS/Android/MAC  able to utilize the ADAL (Azure Active Directory Authentication Libraries) and Azure AD Application proxy to be able to securely access the APIs hosted on premise. Since Azure AD App Proxy  Authentication and Authorization is built on top of Azure AD, you can  also leverage the Azure AD Conditional access to ensure the API access can only work on trusted devices such as Azure AD join or Azure AD Hybrid Joined for the Desktops and Intune Managed for the IOS/MAC and Android device along with a choice to ensure Azure Multifactor Authentication along with  the security backed by machine learning of the  Azure Identity Protection.

Best,

Jeevan Bisht

Program Manager - GTP

Hi Everyone,

We've heard feedback that you've wanted a more streamlined setup for Tableau using Azure AD Application proxy. Today, we are happy to announce that Application Proxy now natively supports Tableau. There are no longer any additional configuration steps required for using it with Application Proxy. We've done this by updating our pre-authentication protocol from OpenID Connect protocol to the OAuth 2.0 Code Grant protocol. The switch to the OAuth 2.0 Code Grant protocol also allows Application Proxy to better support more modern applications by only using HTTP redirects that are commonly supported in JavaScript and HTML tags.

How to get started

Newly configured applications for Azure AD Application Proxy will use the updated protocol and behave as expected. Existing applications will not be affected by this change. If you have existing applications that are experiencing problems related to OpenID Connect, such as a broken sign-in experience or expired authentication connection, you will need to update your applications to the new protocol. Follow the steps below to update your application. These steps are necessary to ensure our system updates your existing application to use the OAuth 2.0 Code Grant protocol:

1. Sign in to the Azure portal.
2. Navigate to Azure Active Directory > Enterprise applications > All applications.
3. Select the app you would like to update.
4. Temporarily change the Backend Application Timeout setting (or any other setting you would prefer) to be able to trigger a Save. Select Save.
   1. Note: Although you are changing a property on the application, this will not effect end user access negatively and is safe to perform in a production environment.
5. Then change back the Backend Application Timeout to your original setting.
6. Select Save. Your application will now be updated to the new protocol.

You can also trigger this update via PowerShell using the following snippet as an example:

$objectId = (Get-AzureAdApplication -SearchString "application_name").ObjectId
$originalTimeout = (Get-AzureADApplicationProxyApplication -ObjectId $objectId).ApplicationServerTimeout
if ($originalTimeout -eq 'Default') {$newTimeout = 'Long'} else {$newTimeout = 'Default'}
Set-AzureADApplicationProxyApplication -ObjectId $objectId -ApplicationServerTimeout $newTimeout
Set-AzureADApplicationProxyApplication -ObjectId $objectId -ApplicationServerTimeout $originalTimeout

Note: Replace application_name with the name of your application to fetch the correct ObjectId

We're excited to release this new functionality, and would love any feedback or suggestions you have to provide! Please send us a note at aadapfeedback@microsoft.com, where we'll be more than happy to help.

Best,

Jasmine Perez

Program Manager

We've heard your feedback around needing more control over your application's cookie flags due to requirements such as security compliance. I'm excited to share that you will now see three cookie settings for your applications published through Application Proxy.

1. Use HTTP-Only Cookie

Sets the HTTPOnly flag on your Application Proxy access and session cookies to provide additional security benefits such as preventing actions like copying or modifying the cookies from client side scripting. Although, Application Proxy has not used this flag in the past, the cookies have always been encrypted and transmitted in an SSL connection to protect against modification.

When to use: We recommend to keep this setting on for its additional security benefits. Note leave this set to no for clients/user agents that do require access to the session cookie. E.g. RDP/MTSC client connecting to a Remote Desktop Gateway published via Application Proxy.

2. Use Secure Cookie

Sets the Secure flag on your Application Proxy access and session cookies to enhance security by ensuring that the cookie is only transmitted over TLS secure channels such as HTTPS and not over an unencrypted HTTP request. This prevents cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text.

When to use: We recommend to keep this setting on for its additional security benefits.

3. Use Persistent Cookie

Sets the access cookie to not expire when the web browser is closed. The cookie will last for the duration of the lifetime of the access token. These cookies are reset if the expiration time is reached or the user manually deletes the cookie.

When to use: We recommend keeping this setting at its default, off. This setting should be avoided and only used for older applications that cannot share cookies between processes. It is preferred to update your application to handle sharing cookies between processes instead of using this setting.

For more detailed information on how to start using this feature see our documentation here.

As always we love hearing your feedback or suggestions! Please send us a note at aadapfeedback@microsoft.com or suggest an idea on our User Voice form at: https://aka.ms/aadapuservoice.