Sitecore Open Authentication with Application Request Routing (ARR)
I was recently working on integrating UAEPASS with Sitecore Federated Authentication. Everything worked as expected during local development and QA testing. Confidently, I moved the code to UAT and that’s when things got interesting.
Before diving into the issue, let’s walk through the architecture behind this setup.
Architecture Overview
In this setup, the user interacts with a public-facing server, which uses ARR to route traffic to a backend Sitecore server.
As shown in the diagram, users aren’t communicating directly with the Sitecore server or even the load balancer. Instead, requests hit a public-facing server, which then routes them to a proxy server configured with ARR (Application Request Routing). This proxy server, in turn, sends the request to the actual Sitecore-hosted application.
Why this detour? Security, isolation, and flexibility the usual suspects in enterprise environments.
What Does ARR Actually Do?
ARR (think: IIS Rewrite’s smarter cousin) acts as a reverse proxy. It takes incoming requests, pulls content from a designated backend server, and serves it to users under a single unified hostname.
Most of the time, ARR servers do not have direct internet access intentionally so. This keeps the internal network secure and reduces exposure.
In summary: ARR pulls the content → passes it to the public server → which serves it under the company’s domain.
Where UAEPASS Went Wrong
As you know, Open Authentication protocols like OpenID Connect involve:
- Redirecting the user to an identity provider (e.g., UAEPASS)
- Completing login there
- Redirecting back to the original site with an authentication token
This process heavily relies on accurate, publicly resolvable hostnames and strict redirect_uri validation.
But in our case, because ARR was proxying the UAEPASS call under the company’s internal hostname, the whole redirect/token exchange process fell apart. UAEPASS didn’t recognize the origin and failed to return the token essentially breaking the login.
To confirm, I accessed the UAT server directly, and UAEPASS worked like a charm. But through the public-facing ARR route? Total failure. I even enabled internet access temporarily on the proxy server to test still no luck.
The Hidden Villain: A Single Checkbox
After nearly four days of debugging, fiddling with logs, double-checking configuration files, and more coffee than sleep, I found the issue.
One checkbox. Just one.
In ARR’s server farm settings, there’s an option labeled “Reverse rewrite host in response headers”
Here’s what it does:
- When unchecked, ARR replaces the original host header with the backend server’s hostname which breaks any authentication process expecting the original domain.
- When checked, ARR preserves the original hostname, which is critical for UAEPASS (or any OpenID provider) to match the redirect_uri and validate the authentication flow.
This doesn’t redirect the user it simply ensures that the correct Host header is passed along internally, allowing the backend to handle redirects and validation accurately.
Once I enabled this setting, the UAEPASS authentication worked flawlessly.
Final Thoughts
This entire issue boiled down to a checkbox that says more than it shows. If you’re implementing federated authentication behind a reverse proxy, make sure you:
- Understand how ARR handles headers and redirects
- Preserve the original host header for proper redirect URI matching
- Keep caffeine handy, just in case
Because sometimes, the difference between four days of debugging and five minutes of success...
is a tiny checkbox hiding in plain sight.