Microsoft Infrastructure
Child pages
  • Azure Application Proxy (copy)
Skip to end of metadata
Go to start of metadata

This page contains preliminary information that is subject to revision as this new sub-service design is refined.

This is a copy. The original lives in the 644 Wiki.


Azure Application Proxy (App Proxy) is a service that extends UW SSO to web applications that use NETID AD authentication. For example, suppose a web site accesses data stored on a SQL Server database. This would require AD Kerberos authentication. Without App Proxy the user experience would be the browser prompting the user (using the browser credential dialog) for their NETID credentials, even if they were already logged into a SAML (Shibboleth) protected web site.

The App Proxy benefits include:

  • SSO for native windows web applications
  • Ability to use those applications from non-Windows platforms
  • Ability to access P172 web applications from off-campus without needing to use a VPN
  • Optional ability to publish the application in the Office 365 application "waffle"
  • Optional ability to limit access to members of a group; this would apply before any application-specific access controls
  • Optional ability to assign an organizational domain name as part of the app URL

How Does App Proxy Work?

  1. An "Application" object is created in Azure AD
    1. It can be given a user-friendly name which is what the user would see in the O365 waffle
    2. This application object is then configured to use App Proxy for authentication
    3. An organizational domain name can optionally be configured, more below
  2. Kerberos constrained delegation is configured for the web app's service account; this is done on the App Proxy connector server computer object
    1. The connector server is located in our P172 network; it runs the App Proxy Connector service which reaches out via HTTPS to Azure AD
    2. We currently have one proxy connector server; we'd need to add more for redundancy/fault-tolerance
  3. The user goes to the web app's app proxy URL; Azure AD will then check to see if there was a user login token (cookie) sent with the URL
    1. If there is a login token in the browser cookie cache, then the user is seamlessly logged into the web application
    2. If not, the user is directed to the Shib IdP to log in
    3. This discussion is ignoring the protocol transitions and app token issuance that would result
  4. All HTTPS traffic flows through the app proxy service, a capacity planning link is included below

Architectural Diagram

App Proxy URLs

The default app proxy url has the form <app-name>-uwnetid.msappproxy.net. The <app-name> portion would be a shortened, URL-friendly version of the full application name. As an example:

https://mireports-uwnetid.msappproxy.net for the application named "Microsoft Infrastructure Reports"

It is possible to use any of our 11 custom AAD domain names instead of the "-uwnetid.msappproxy.net" suffix. For example:

https://mireports.netid.washington.edu

It would also be possible to add custom domain names to our AAD tenant specifically for app proxy. For example, apps.uw.edu. This would give an app URL of:

https://mireports.apps.uw.edu

Current AAD Domain Names

  • cloud.uw.edu
  • cloud.washington.edu
  • deviceusers.washington.edu
  • exchange.washington.edu
  • netid.washington.edu
  • o365.uw.edu
  • o365.washington.edu
  • resource.washington.edu
  • u.washington.edu
  • uw.edu
  • uwnetid.onmicrosoft.com (the default name)
  • washington.edu

Fulfillment Process

  1. Prerequisites
    1. A web application using port 443, i.e. HTTPS protocol
    2. The web application running on a NETID domain-joined computer and using AD authentication
  2. Customer supplies UW-IT the following information
    1. The web site URL
    2. The web host computer name
    3. The web site service account name, if different from the computer name
    4. The preferred app proxy URL prefix (and perhaps suffix, TBD as to the custom naming)
    5. The preferred AAD application object name (this is the name that would show up in the waffle)
    6. Whether the application should be published in the waffle or not
    7. Whether access to the application should be limited to a group, if so, the name of the group
    8. If using a custom app URL, then an SSL certificate with that name is needed
  3. UW-IT will then configure AAD and AD for the new app proxy instance

Outstanding Questions

  • Whether and how this would work if the web app is a load-balanced farm
  • Which of the existing custom AAD tenant domain names can be used
  • Whether any new custom AAD domain names will be created

Links for More Info


  • No labels