I am currently using the IIS URL Rewrite Module and Application Request Routing on a server in the DMZ to forward requests to a web application running on an internal server.
The application which is deployed on the internal server has SSO which includes Azure AD using OWIN pipeline and openIdConnect.
When a user selects the authenticate using AzureAD option instead of being redirected to the https://login.microsoftonline.com/<tenantname>/...
they are redirect to http://my.company.com/<tenantname>/... where http://my.company.com is the URL used to access the application from the DMZ.
The SSO works for all internal instances i.e. where request are not being forwarded in a reverse proxy scenario.
Why is this happening when using URL Rewrite and ARR?
Unchecking the Reverse rewrite host in response headers checkbox under Application Request Routing Cache > Server Proxy Settings solved this issue.
Reverse rewrite host in response headers (checked)
ARR will rewrite the host name in the location header of a 301
response to the original host.
URL Rewrite keeps original host Location
IIS Url Rewrite ARR issue
Related
I have a blazor app that redirects to the login page using 302 redirection. If open it from the local network, it returns in http headers:
Status Code: 302
http://myvm/Identity/Account/Login?returnUrl=%2F
It works as expected.
When access to this vm from the Azure Application Gateway, the redirection works but the Gateway only replaces the host, not the protocol.
For example, I call:
https://example.com
This domain points to the Azure Application Gateway.
The gateway returns
Status Code: 302
http://example.com/Identity/Account/Login?returnUrl=%2F
Note that it has replaced the host but not the protocol (it should be https, not http).
My workaround is to add a rule for redirection, from https to http.
I do not like it because the gateway still returns http, but then the new rule is executed and redirected to https.
Is there an elegant solution for this?
In my opinion the best solution is to rewrite the Location header in your backend responses. This documentation describes how you can create a rewrite rule from the Azure portal for specifically the location header. Then create your rule specifically to replace http:// with https://
maybe someone can help me out.
I have a publicly accessible IIS Web Server (DMZ) with ARR enabled and use that IIS as a reverse proxy to rewrite all requests to an internal Website (QlikSense). So far so good. I sucessfully implemented keycloak as my Authentication module which is currently also installed on that external accessible DMZ server. Here comes my issue. Whenever I request the external URL, it sucessfully redirects me to my internal application (url rewrite) , and from there (over a redirect Uri) back to the keaycloak instance (which sits on the DMZ server) for authentication. Everything works fine but from an architectual point that setup is questoinable in my eyes. I would like the authentication to be happening internally and not on my DMZ server (behind the Reverse Proxy). But all my attempts to make keycloak authenticate on an internal installation failed so far (page cannot be opend because server not found). What do I miss to make external requests being rewritten to the internal keycloak server without getting the error that SAFARI CANNOT OPEN THE PAGE BECAUSE THE SERVER CANNOT BE FOUND ?
I would like to have the authentication part being handeld internally (behind reverse Proxy) and not externally, since port 8080 needs to be open on the DMZ which is a security issue...
thanks
When I use this URL I get this error "AADSTS500117: The reply uri specified in the request isn't using a secure scheme." I am guessing this is beacuse I am not using HTTPS, is there any way I get this app working with HTTP
Azure does not redirect from authorization requests to non-HTTPS URLs. Localhost is the only exception. You need to use HTTPS to protect your website and make sure that the redirect you provide is HTTPS.
So you can use http://localhost/ .
Is it possible to use IIS' URL rewrite module in the following scenario:
Site A hosted on IIS with anonymous authentication and URL Rewrite module
Site B hosted on IIS with Windows authentication
When a client requests Site A, the request is forwarded to Site B using a specific Windows identity
I've tried to configure the pool associated to Site A so that it runs under the identity I want Site B to be accessed with but it does not work, i.e. the client's Windows identity is used instead.
URL Rewrite runs so early in the stack that it doesn't have access to authentication data.so the only way to resolve the issue You can use the custom HTTP module which sends the authenticated user custom header. You could add an HTTP module to your app, or use global.asax, or you can use www.isapirewrite.com which runs later in the stack and has a handle on the auth data.
https://learn.microsoft.com/en-us/archive/blogs/benjaminperkins/configure-application-request-routing-with-windows-authentication-kerberos
https://learn.microsoft.com/en-us/archive/blogs/asiatech/a-quick-solution-when-windows-authentication-is-required-on-backend-web-server-for-arr-scenario
For my Web Java application, Which is deployed on Azure VM I have done the http to https redirection on azure waf listener. which looks working fine on web but not for rest webservices.
For example: When I access the http url like http: //www.abc.com it will automatically redirect to https: //www.abc.com.
But when I am trying to access the rest post webservice with http for example: http: //www.abc.com/rs/savedata it gives error with status code -301 and status message "Moved Permanently".
However when we access rest post api with https it works fine.
I am not sure what configuration is required on Azure, so that it can automatically redirect to https for http rest request.
This is the normal behavior that is described in here: you will have to manage it from the client to call the new redirect to URL as described in here:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-redirect-overview
if you want transparent redirect you will need to look at putting in place a Reverse Proxy Like Nginx which will handle the redirect and make a pass through.