Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-5045

Support different URLs for front-end redirect and back-channel endpoints

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Duplicate
    • Major
    • None
    • 3.0.0.Final
    • Adapter - JEE, OIDC
    • None
    • NEW
    • NEW

    Description

      Hi,

      we're having a scenario with a Keycloak (OIDC) protected classic web application (no SPA) which has the
      restriction that it is not allowed to do any internet requests from its server within the DMZ it is located.
      Due to this restriction it cannot execute any back-channel requests (e.g. /token, /userinfo) to Keycloak
      because the configured "auth-server-url" is the front-end URL which is only visible through internet and
      actually points to a firewall component. The Apache web server with mod_cluster that is the load balancer
      for Keycloak is on a separate machine with separate hostname, port and SSL certificate.

      We're suggesting an enhancement for Keycloak (server and OIDC adapters) to support different URLs
      for front-end (browser redirect) and back-channel URLs for Keycloak server endpoints?

      That would imply several changes:
      1. The server side endpoint implementations (UserInfoEndpoint, TokenIntrospectionEndpoint) are using TokenVerifier
      which by default checks the token issuer.
      This check will fail because the realmUrl of the back-channel request will be unequal to the token's issuer URL,
      which comes from the session created at login with the front-end URL.

      There are several alternatives to handle this:
      a) There is already a boolean varibale "checkRealmUrl" in TokenVerifier to disable this check, but no way to set it to false.
      It might be an option to support a switch per client to disable/enable the issuer checking via admin console.
      b) Instead of deriving the issuer name from the current request URL it might be possible to (optionally) provide
      an explicit issuer name field per realm. That would allow setting issuer names that are completely independent
      of any network infrastructure.
      c) When issuing a token through TokenEndpoint, set the issuer to the current /token request URI rather than using
      the one from the associated session.
      see TokenManager.initToken(): token.issuer(clientSession.getNote(OIDCLoginProtocol.ISSUER));
      d) When the token "iss" field gets checked, it could be checked against clientSession.getNote(OIDCLoginProtocol.ISSUER)
      rather than the current request URI.

      2. The OIDC adapters must support a second configuration parameter (e.g. "auth-server-url-for-backend-requests") to
      allow setting a separate back-channel URL (as it did before KEYCLOAK-2623).
      Solving this via DNS (as suggested in KEYCLOAK-2067) is not working in our scenario because the back-channel endpoints
      also have different port and certificate.

      Cheers,
      Manfred

      This is related to:
      KEYCLOAK-2623, KEYCLOAK-2067, KEYCLOAK-2004, KEYCLOAK-5014
      http://lists.jboss.org/pipermail/keycloak-user/2017-May/010788.html
      http://lists.jboss.org/pipermail/keycloak-user/2017-June/010864.html

      Attachments

        Issue Links

          Activity

            Public project attachment banner

              context keys: [headless, issue, helper, isAsynchronousRequest, project, action, user]
              current Project key: KEYCLOAK

              People

                Unassigned Unassigned
                manfredduchrow Manfred Duchrow (Inactive)
                Votes:
                10 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: