Handling Sitecore CM and IdentityServer Behind a Proxy or CDN in an Azure Environment

Recently, while working with a Sitecore 10.4 deployment in an Azure environment, we encountered an interesting challenge: handling Sitecore Content Management (CM) and IdentityServer (SI) behind a proxy/CDN setup using Azure Application Gateway. The DNS configuration was managed at the Application Gateway level. Here’s how we resolved the issue.

The Setup

In this scenario, the public URLs were routed through Azure Application Gateway before reaching the internal Sitecore servers:

• User Request (CM): https://cm.cdn.xyz.com → Azure Application Gateway → https://cm.xyz.com (internal CM URL)

However, this setup presented some issues, as Sitecore’s out-of-the-box configuration isn’t fully equipped to handle such complex routing seamlessly.

Issue

Misalignment in URLs: The login redirects and callbacks during authentication often landed on the internal URLs (https://cm.xyz.com) rather than staying within the proxy URLs (https://cm.cdn.xyz.com), and hence produces invalid request error.

The Three-Step Solution

To resolve these issues, a three-step solution was implemented:

1. Install the "Application Gateway Host Rewrite" Extension

The first step is to ensure that the host headers are correctly rewritten so that Sitecore picks up the appropriate URLs. We installed the Application Gateway Host Rewrite extension on the CM App Service. This extension allows the Azure Application Gateway to rewrite the host headers for incoming requests, ensuring that IdentityServer4 picks up the correct host (https://cm.cdn.xyz.com), even after the requests have passed through the gateway.

2. Update Sitecore Identity Server confguration

The next step involves updating the Sitecore Identity Server configurations to allow communication from all relevant domains.

1. Open the \Config\production\Sitecore.IdentityServer.Host.xml file in the Sitecore Identity Server site root.
2. Locate the <AllowedCorsOrigins> tag and update it to include all the necessary domains that need to communicate with IdentityServer. Separate each domain using the | symbol.

For example, in an Azure QA environment with both CM and CD app services, the configuration might look like this:

1<AllowedCorsOrigins>
2  <AllowedCorsOriginsGroup1>https://cm.xyz.com|https://cm.cdn.xyz.com</AllowedCorsOriginsGroup1>
3</AllowedCorsOrigins>

3. Add a Rewrite Rule in CM’s web.config

Lastly, we added a rewrite rule in the web.config of the Content Management instance to handle URL rewrites correctly for outbound responses. Here’s the rule that was applied:

1<system.webServer>
2  <rewrite>
3    <outboundRules>
4      <rule name="HttpToHttpsOutbound" preCondition="IsRedirect">
5        <match serverVariable="RESPONSE_Location" pattern="^http://cm.xyz.com/(.*)" />
6        <action type="Rewrite" value="https://cm.cdn.xyz.com/{R:1}" />
7      </rule>
8      <preConditions>
9        <preCondition name="IsRedirect">
10          <add input="{RESPONSE_STATUS}" pattern="3dd" />
11        </preCondition>
12      </preConditions>
13    </outboundRules>
14  </rewrite>
15</system.webServer>

This rule ensures that any HTTP redirect responses are transformed to use the correct HTTPS endpoint (https://cm.cdn.xyz.com) and that the responses maintain consistency with the proxied URL.

Wrapping Up

By leveraging the Application Gateway Host Rewrite extension and carefully configuring rewrite rules, we were able to seamlessly integrate Sitecore CM and IdentityServer in a complex proxy/CDN environment. These adjustments allowed the client’s Sitecore environment to maintain consistent URLs throughout the authentication flow, improving the user experience and eliminating issues caused by internal vs. external URL mismatches.

This setup highlights the importance of understanding how Sitecore’s configurations interact with reverse proxies and CDNs, especially when dealing with environments hosted in Azure.