Keycloak 26 modifies redirect URI hostname when running behind IIS proxy #37153

imsaha · 2025-02-06T06:37:39Z

imsaha
Feb 6, 2025

Before reporting an issue

I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

No response

Describe the bug

When using Keycloak 26 behind an IIS proxy, the redirect_uri is being modified from http://localhost:5267/scalar/v1 to https://domain.com/scalar/v1 after successful authentication. This happens even though the proxy headers and Keycloak configuration seem correct.

KC_HOSTNAME=${KEYCLOAK_HOSTNAME}
KC_HOSTNAME_URL=https://${KEYCLOAK_HOSTNAME}
KC_PROXY_HEADERS=forwarded

Version

26

Regression

The issue is a regression

Expected behavior

Expected to redirect to the provided redirect_uri.

redirect_uri = http://localhost:5267/scalar/v1 without modifying the base address

Actual behavior

Redirects to https://domain.com/scalar/v1 rewriting the base address http://localhost:5267

How to Reproduce?

Steps to Reproduce

Docker compose.

services :
  keycloak :
    image : quay.io/keycloak/keycloak:26.0.5
    container_name : kc26
    environment :
      - KC_BOOTSTRAP_ADMIN_PASSWORD=${KEYCLOAK_ADMIN_PASSWORD}
      - KC_HEALTH_ENABLED=true
      - KC_METRICS_ENABLED=true
      
      - KC_DB=postgres
      - KC_DB_URL=jdbc:postgresql://postgres/${POSTGRES_DB}
      - KC_DB_USERNAME=${POSTGRES_USER}
      - KC_DB_PASSWORD=${POSTGRES_PASSWORD}
      
      - KC_HOSTNAME=${KEYCLOAK_HOSTNAME}
      - KC_HOSTNAME_URL=https://${KEYCLOAK_HOSTNAME}
      - KC_HTTP_ENABLED=true

      - KC_HOSTNAME_STRICT=true
      - KC_HOSTNAME_STRICT_HTTPS=false

      - KC_PROXY_HEADERS=forwarded

      - KC_HTTPS_CERTIFICATE_FILE=/keycloak/certificates/__smartmeservices.ae.pem
      - KC_HTTPS_CERTIFICATE_KEY_FILE=/keycloak/certificates/__smartmeservices.ae_key.pem

    ports :
      - "80:8080"
      - "443:8443"
    volumes :
      - ./certificates:/keycloak/certificates
      - ./themes:/opt/keycloak/themes
    command : start 
    restart : always
    depends_on :
      - postgres
      - rabbitmq
    networks :
      - kc26net

  postgres :
    image : postgres:latest
    container_name : postgres
    restart : always
    environment :
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    ports :
      - 5432:5432
    volumes :
      - ./db_data:/var/lib/postgresql/data
    networks :
      - kc26net

networks :
  kc26net :
    driver : bridge

IIS config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <!-- Reverse Proxy to Keycloak Server -->
                <rule name="Keycloak Reverse Proxy" enabled="true" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="https://192.168.1.25/{R:0}" appendQueryString="true" logRewrittenUrl="false" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Map the IIS website to a domain.com

Anything else?

No response

shawkins · 2025-02-06T21:36:13Z

shawkins
Feb 6, 2025
Collaborator

You should see an error log indicating that hostname-url is no longer used. hostname-strict-https is not valid either.

With hostname-strict as the default of true, hostname=KEYCLOAK_HOSTNAME, and proxy-headers=forwarded, the server will redirect requests to KEYCLOAK_HOSTNAME - but determine the protocol and port from the forwarded proxy header. If you are not seeing that behavior, then either your proxy is not setting the approriate header values, or is doing additional redirection.

4 replies

imsaha Feb 7, 2025
Author

Thank you for pointing out the invalid environment parameters. I have removed them.

The proxy works as expected when using the admin console or account page. However, when integrating with the application using implicit flow, I am encountering the issue

Upon authentication challenge the application redirects to
https://mydomain.com/realms/testrealm/protocol/openid-connect/auth?response_type=token&client_id=test&redirect_uri=http://localhost:5267/scalar/v1

And after authentication is successful it is expected to redirect to http://localhost:5267/scalar/v1#session_state... however it redirects to https://mydomain.com/scalar/v1#session_state...

The base address of the redirect URI (parameter redirect_uri) is modified to keycloak hostname

shawkins Feb 7, 2025
Collaborator

What is used as the redirect is determined here:

keycloak/services/src/main/java/org/keycloak/protocol/oidc/utils/RedirectUtils.java

Line 72 in 0fc0dcd

    
           public static String verifyRedirectUri(KeycloakSession session, String rootUrl, String redirectUri, Set<String> validRedirects, boolean requireRedirectUri) {

There are several reasons why the provided redirect_uri would not be used. If client is not configured to accept that uri, if it is not properly url encoded, etc.

Ideally there would be a trace or debug log detailing why it wasn't used, but unfortunately there currently is not.

ashokbharathi Apr 26, 2025

Hi @imsaha , I am also facing the same issue. Did you resolve it?

imsaha Apr 28, 2025
Author

On Nginx works as expected. So, I am using nginx proxy

Navigation Menu

Repository navigation

Keycloak 26 modifies redirect URI hostname when running behind IIS proxy #37153

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment 4 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Keycloak 26 modifies redirect URI hostname when running behind IIS proxy #37153

Uh oh!

Uh oh!

imsaha Feb 6, 2025

Before reporting an issue

Area

Describe the bug

Version

Regression

Expected behavior

Actual behavior

How to Reproduce?

Steps to Reproduce

Anything else?

Replies: 1 comment · 4 replies

Uh oh!

shawkins Feb 6, 2025 Collaborator

Uh oh!

Uh oh!

imsaha Feb 7, 2025 Author

Uh oh!

shawkins Feb 7, 2025 Collaborator

Uh oh!

ashokbharathi Apr 26, 2025

Uh oh!

imsaha Apr 28, 2025 Author

imsaha
Feb 6, 2025

Replies: 1 comment 4 replies

shawkins
Feb 6, 2025
Collaborator

imsaha Feb 7, 2025
Author

shawkins Feb 7, 2025
Collaborator

imsaha Apr 28, 2025
Author