2

Use case: Due to specific restrictions, I need to configure the following configuration:

  • Tomcat configured to use port 8080
  • IIS configured to use port 443 (SSL)
  • IIS redirect to Tomcat via ARR + URL redirect rule
  • Keycloak standalone configured to use port 8443 (SSL)
  • Access the application through a public domain and not the IP address (ie: www.myserver.com)

The Tomcat application will be accessed using the IIS proxy: https://server/myapp

The Keycloak authentication will be accessed using directly the keycloak URL: https://server:8443/auth/....

Problem: When I access keycloak directly using the 8443 secured port works great, but when I access the Java application via IIS proxy (443), the IIS/Tomcat is redirecting for the keycloak authentication to port 443 instead of port 8443.

Question: Are there any settings on IIS, Tomcat, or Keycloak that I am missing to make the tomcat redirect to the correct keycloak 8443 port for authentication?

Ie: When adding to the browser the https://server/myapp URL, the tomcat application is redirecting (for authentication) to https://server/auth/ instead of https://server:8443/auth/

IIS ARR configuration screenshot: IIS ARR settings

IIS Redirect rule configuration screenshot IIS Redirect rule

Deployment use-case screenshot Deployment use case diagram

Pete
  • 23
  • 5

1 Answers1

1

but when I access the Java application via IIS proxy (443), the IIS/Tomcat is redirecting for the keycloak authentication to port 443 instead of port 8443.

Where is the request coming from to the Java Application and where is it going to. If you are going to the domain name, it’s going to hit your IIS proxy first on 443.

Try adding an 8443 rewrite rule for keycloak in IIS

  • Hello, Jesse. Many thanks for your response. The authentication forward is set in the header response by the java keycloak adapter. I think here is where due to the IIS proxy to Tomcat the location set in the header is overridden by IIS to have the 443 (IIS) port and not the 8443 (keycloak) port. My initially goal was to fix this problem. But your workaround to have IIS forward the request to keycloak based on the pattern ('auth') might work just fine. I will try your approach, while keep researching the root problem. – Pete Jul 23 '18 at 15:36