Claims-to-Windows Identity Translation Solutions and "Considerations" when using AD Application Proxy

Problem Statement:

At one of my consulting engagement this year my team were unable to communicate from a claims aware azure web application via client browser to an on-premise, windows authenticated SOAP endpoint.  To overcome the identity endpoint mismatch, Claims and Windows, we were using the Azure Application Proxy to perform the identity translation. Our problems primarily occur in communicating between the browser and the Azure Application Proxy.  We found multiple potential solutions to solve this problem, but each one has a fatal flaw.  We do not need to solve for every solution, rather we only need 1 to work.

Solution 1:

Hide an iframe in the page that authenticates to the proxy by hitting a proxy endpoint and performing the redirect dance.  Because the user must first log-in to the application, the iframe can reuse these credentials.

Process Flow Description:

1. Iframe makes a request to the proxy endpoint (without authentication)
2. Proxy returns a 302 redirect
3. Iframe is redirected to AAD login page. Login cookies are submitted to AAD login because application requires authentication.
4. Login successful returning token
5. Sends token to proxy
6. Proxy returns cookie that is valid for the proxy.
7. Any future calls to the proxy can use the proxy cookie and make successful calls.

This solution works for the majority of cases except…

Fatal flaw: During step 3, if the user has multiple logins to Azure AD the user can not automatically be logged in because AAD returns an HTML to the hidden iframe asking which to use for login.

Potential fixes:

• Enable home realm discovery (Domain_Hint) for the Application Proxy
  • When enabling domain hints, step 2 will return an updated redirect URL to include an extra parameter, ‘&domain_hint=fmi.com’. With this extra information in Step 3, the AAD login page can automatically determine which user to login as.  Now the iframe can successfully login and the requests going forward will succeed.
  • Blocker: this feature is not available yet for App Proxy.
• Use a Smart Link
  • A smart link tells AAD login similar information as the domain hint. I’ve tried using the below smart link, but it does not automatically detect the user domain to use. e.g. https://myapps.microsoft.com/fmi.com/signin/Home%20Proxy%20Dev/000-000-000-000 
  • Blocker: The Smart link still requires me to choose which user to select.

Solution 2:

Use ADAL.js to retrieve a bearer token for authentication to the Application Proxy endpoint.

Process Flow Description:

1. ADAL.js calls AcquireToken to requesting a bearer token for the Application Proxy Endpoint.
2. AAD returns an authentication token.
3. We make JavaScript calls adding the header “authentication: bearer [token]” so we are properly authenticated to the endpoint.

This solution works for Internet Explorer but in any other browser it fails

Fatal Flaw: When making requests in step 3 with the authentication header, the browser sends a CORs preflight request.  The proxy is not handling the OPTIONS request properly and is returning a 302.

Potential Fixes:

• Enable CORs on the Application Proxy so that Preflight requests are handled gracefully.
  • Blocker: this feature is not available yet for App Proxy.

Summary:

We communicated these shortcomings of AAD Application Proxy to Microsoft and hope they would prioritize this feature in next release.  Hope you would be able to customize your design keeping the above solutions and it's shortcomings in mind.