Earlier this month we announced support for wildcard (*) application publishing. In this blog, we’ll take a moment to go over this in more depth. As a reminder, 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 reduces your administrative work, reduces opportunities for error, and helps make your users more efficient.
The documentation has two example scenarios. Below, we build on those to walk through two sample deployments which highlight two different ways to exclude specific applications from the publishing. Note that excluding applications may not be needed for your deployments.
Assume I have already added the custom domain adventure-works.com to my tenant. While custom domains are optional for other types of applications, they are required for wildcard applications.
Deployment 1: Block Wildcard Exceptions
Phase #1: General Wildcard Application Publishing
I have three different applications that I want to publish for all my users, and they are all configured for Integrated Windows Authentication.
Because my three applications have the same properties (users, protocol, backend authentication), I can publish these using a wildcard.
First, I will create a CNAME entry in my DNS to point *.adventure-works.com to 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net, where 000aa000-11b1-2ccc-d333-4444eee4444e is my tenantId. This ensures correct routing for my application. By using a wildcard DNS entry, I will be covering all the applications that match the wildcard application.
Next, I will create a new Application Proxy application in my tenant, following the same steps outlined in the documentation. Note the wildcards in the Internal URL, External URL, and Internal Application SPN fields.
By publishing this one wildcard application, my users can now access any of the three applications by going to the URLs they are familiar with (ex: travel.adventure-works.com). My application structure now looks like the following, where blue boxes are the applications explicitly published and visible in the Azure Portal, and gray applications are accessible through the parent application.
Phase #2: Creating an Exception
I’m very excited about this access for my users, but I have another application, finance.adventure-works.com, which should only be accessible by my Finance division. With the current application structure the finance application would be accessible through the wildcard application, and thus by all employees. To prevent this, I will publish Finance as a separate application with more restrictive permissions. This process is no different than publishing any other application.
I also need to make sure my DNS is pointing finance.adventure-works.com to the application specific endpoint. You can find the instructions at the bottom of the Application Proxy settings for the Finance application. In this case, I will be pointing finance.adventure-works.com to https://finance-awcycles.msappproxy.net/.
Now my application structure looks like the following:
Because finance.adventure-works.com is a more specific URL than *.adventure-works.com, it will take precedence. Thus only my finance department has access to this application, and it has successfully been excluded from the wildcard publishing.
Note: If I had multiple applications published for finance and also had finance.adventure-works.com as a verified domain, I could also publish another wildcard application *.finance.adventure-works.com. Because this is still more specific than the generic *.adventure-works.com, it will also still take precedence if a user accesses an application in the finance domain.
Deployment #2: Limiting applications covered by the wildcard application
Let’s assume I still want to publish my Expenses, Travel, and HR applications. However, I don’t want anyone to have access to the Finance application. I could still do this using Deployment #1, by assigning the Finance application to no users (instead of the finance department). Anyone trying to access the application through Application Proxy will then get a user unauthorized error. However, I could also do this in the following way:
Configure the wildcard application in the Azure Portal the same way as I did in Deployment #1, Phase #1. However, I will now create specific DNS entries for the applications I want to enable. I will need a CNAME entry pointing each of the following:
to 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net (where 000aa000-11b1-2ccc-d333-4444eee4444e is my tenantId).
For each wildcard application using this approach I will also need to create a CNAME entry mapping <ApplicationId>.domain to the same endpoint, 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net. As a reminder, the ApplicationId can be found in the application properties page.
The DNS routing rules make sure that only the applications you’ve specifically listed with CNAME entries will be routed through Application Proxy, thus blocking/excluding all other applications even if they would have matched the wildcard pattern.
Please note that we recommend using the pattern in Deployment #1 if possible. This is easier to manage, and allows you to be more flexible with changes that may be needed for the excluded applications.
Are there any other scenarios you’d like to see more details on? Do you have any further questions? Please let us know by either leaving a comment here, or by emailing us at email@example.com.
Program Manager II