Application Proxy Blog


Hello all. Another Tangent thought to add.  I am now a guest blogger on the Application Proxy Blog.  I wanted to share that here as well. If you know a little bit about Active Directory Federation Services (AD FS) you may have been familiar with the AD FS Proxy role.  Back in those days, companies also used Unified Access Gateway or TMG in the past to publish applications externally to their internal corporate environment.  Now in Windows Server 2012 R2, the Web Application Proxy role service does two main functions: First, it now is the AD FS Proxy component, and as such also requires AD FS 2012 R2, and it also acts to securely publish applications. 

The new Microsoft Blog is called Application Proxy because now there is the Application Proxy Service in Microsoft Azure. Here is my first guest BLOG on http://blogs.technet.com/b/applicationproxyblog/archive/2014/10/11/paths-to-success-with-web-application-proxy.aspx. Since I did a major rollout of Web Application Proxy starting in its Beta and for about a year after that, I had many lessons learned about what works and what does not. So I can say with a high degree of assurance say that many of those, ahem, “features” that were originally somewhat limiting, will soon be fixed in the Web Application Proxy v.Next 🙂  You can watch the latest video that tells all about Azure Application Proxy and also Web Application Proxy v.Next on Channel 9: TechEd Europe.

Here are some of my other favorite Web Application Proxy resources that you may enjoy as well!

Deploy the Web Application Proxy

 

Overview: Connect to Applications and Services from Anywhere with Web Application Proxy

This Guide also contains the Walkthrough Guide for WAP to continue building from where the AD FS lab environment guide left off.

Publishing Internal Applications using Web Application Proxy

 

SCOM Management Pack for Web Application Proxy

The Web Application Proxy management pack provides health and event monitors to get a unified state for the Web Application Proxy role.

WAP: External and Backend server URLs are different and URL translation is disabled

By default, Web Application Proxy translates the host portion of requests to a backend server. For example, Web Application Proxy will translate the URLs successfully if the external URL is https://apps.contoso.com/ and the backend server URL is https://appsinternal.contoso.com/. However, URL translation is currently disabled, which might cause client requests to be rejected. You can manually enable the translation of host headers by using the DisableTranslateUrlInRequestHeaders parameter.

Web Application Proxy Overview

 

Comments (1)

  1. Jack says:

    Hi,

    Nice Article

    I have successfully deployed ADFS and Web Application Proxy

    However, now I want to use the same ADFS Server for another application

    I added another Relying Party using metadata file, however, am facing some confusion regarding Publishing it via Web Application Proxy

    I would like to know the exact meaning and difference between the External URL and the Backend URL

    The first Relying Party I setup was published to the same Public URL to which the ADFS Server was setup, example :
    https://abc01.contoso.com

    It used a SSL certificate issued to "https://abc01.contoso.com"

    My ADFS Federation Service name is also "abc01.contoso.com"

    Hence, the Public Certificate I used while publishing is the same as the SSL/Service Communication Certificate setup in my ADFS

    Since, Web Application Proxy does not support nesting of URLs, I am unable to Publish my second Relying Party to another path of the same Public URL, example :
    https://abc01.contoso.com/second/ is not accepted

    Will creating a new sub domain for the second Relying Party and publishing it to the new sub domain work ? example :
    https://second.contoso.com

    In this case is my Backend URL supposed to be set as the ADFS Service Name URL "https://abc01.contoso.com" OR can it also be set as the new sub domain I create "https://second.contoso.com"

    Will using "https://second.contoso.com" and a different certificate(issued to
    https://second.contoso.com) during publishing still let users authenticate via ADFS even though ADFS is configured for the first URL "abc01.contoso.com"

    Thanks and Regards,

    Jack

Skip to main content