Simplified Application Management using Wildcards in Azure AD Application Proxy

[Alex Simons (AZURE)]

First published on CloudBlogs on Feb, 07 2018
Howdy folks, Today I get to tell you about a cool new capability that improves the management experience for Azure AD Application Proxy. Now you can use wildcards(*) to publish many applications at once. Wildcards also let you apply the same settings such as authentication method and user assignment for each of those applications. This capability, now in public preview in Azure AD Application Proxy reduces your administrative work, reduces opportunities for error, and helps make your users more efficient. In the words of one of our private preview customers:

"Deploying applications using the wildcards helps us ensure that our users have access to more of the resources they need."

Using Wildcards

To use this new capability, just configure the URL for the Application Proxy application to include a wildcard (*). All other steps are the same as publishing any other application with Application Proxy. Then, all applications that are in scope of the wildcard can be accessed using Azure AD application proxy. For example, let's say your company, Adventure Works Cycles, has five applications on-premises that you want to publish for external access by your users:

• Travel: https://travel.adventure-works.com
• Expenses: https://expenses.adventure-works.com
• 3 other applications with a similar format: https://*.adventure-works.com

With this new capability, you don't need to publish and manage five individual applications. Now you can use a wildcard to publish and manage these as a single application, https://*.adventure-works.com. Publish the wildcard application the same way you publish any Application Proxy application , with the wildcard (*) in the internal and external URLs.

Figure 1. Application Settings Including a Wildcard in the URLs

All applications in scope of the wildcard can be accessed by the same set of users and groups that are assigned to the application. Applications published through a wildcard need the same type of single sign-on method. Each of the published applications can be accessed by the users and groups that are assigned to the wildcarded application. If the application uses Windows Integrated Windows Authentication, you will also need a wildcard in the Single Sign-On settings if the SPN is not the same across applications.

Figure 2. Wildcard in Single Sign on settings for an application with Windows Integrated Authentication

Exceptions: the right settings for every app

You can still use wildcards even if you have some applications whose requirements (ex: users, single sign-on method) differ from the others but match the wildcard pattern. For example, say you have an application https://finance.adventure-works.com that has different access requirements than your other applications on https://* . In this case, you can publish another application, https://finance.adventure-works.com and assign different users or configure different settings for it.

The settings and access for the most specific URL always take precedence over wildcards. To learn more about how to exclude applications from a wildcard publishing, see our documentation . We believe wildcards will help you use Azure AD Application Proxy to give your users access to more of the resources they need. Wildcards can also help you ensure consistent access and settings for applications that share common requirements. Several of our private preview customers have told us that they plan to use wildcards to publish and manage dozens of applications at once! To learn more about wildcards and Azure AD Application Proxy, see the documentation . To begin publishing an application, sign in to the Azure AD Admin Center . If you have feedback or feature requests related to this new capability, please let us know in the Application Proxy section of our feedback forum . Or feel free to email us at aadapfeedback@microsoft.com . Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division