Production Environment Overview

In our production setup, we have the following components:

• M1: ASP.NET Website
• M2: IIS URL Rewrite 2.0 with Application Request Routing (ARR) 3.0

Request Redirection

Using IIS URL Rewrite, any incoming request to M2, such as http://m2/app/login.aspx, is redirected to M1 as http://m1/app/login.aspx.

On M1, we have implemented ASP.NET Open Auth to facilitate Google external authentication. When a user clicks the Google login button, they are redirected to the Google login page for authentication.

Issue with Redirects

However, when accessing the website through M2, the redirect URL generated by the .NET OAuth library (e.g., https://accounts.google.com/[query-string]) is altered by the URL Rewrite module, resulting in a redirect to http://m2/[query-string] instead.

To clarify, when a request is made to authenticate via an external provider, a 302 redirect is returned. The response headers typically look like this:

Response Headers:
...
Location: https://accounts.google.com/o/oauth2/auth?big_long_query_string
...

Since M1 is behind the proxy server (M2), the URL Rewrite modifies the Location header to:

Response Headers:
...
Location: http://m1/o/oauth2/auth?big_long_query_string
...

Solution Requirement

To resolve this issue, we need to create a rule that prevents the rewriting of the location URL during specific redirects. While the default behavior of redirecting all requests to the main proxy server is often desired, we require exceptions for certain redirects.

Suggested Workaround

Consider implementing a conditional rule in your URL Rewrite configuration that checks for specific patterns in the redirect URL and bypasses the rewrite for those cases. This way, you can maintain the desired behavior for most redirects while allowing certain ones to function correctly.

Conclusion

By carefully configuring your URL Rewrite rules, you can ensure that external authentication redirects work seamlessly without being altered by the proxy server.