6

I'm running Keycloak, keycloak Security Proxy and an ui application in a Docker-compose network. When I try to access the webpage, I get a login page, which I can use - but instead of being successfully redirected, I get the following error: 

> Aug 03, 2018 1:13:24 PM org.keycloak.adapters.OAuthRequestAuthenticator resolveCode
ERROR: failed to turn code into token
java.net.ConnectException: Connection refused (Connection refused)
      at java.net.PlainSocketImpl.socketConnect(Native Method)
      at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
      at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
      at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
      at java.net.Socket.connect(Socket.java:589)

I get this error no matter what kind of application I proxy, or if I run it within Docker-compose or simply as a node. It also probably appears when I try to use python adapters, instead of the security proxy.

The whole network runs behind a company proxy, could this be the reason?

Considering that the code seems to be send (see below), it seems Keycloak can at least verify the user. But I'm stumped on how to solve the problem. Has anyone any ideas?

http://localhost:8080/?state=84736978-afe6-43eb-a554-aedf86717415session_state=8a231709-5ef3-45fd-8e36-103e521ba49ecode=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..4GewkGISgYEXeGPuCxupsA.V939JivWRaNltjnjT4r2CJGT4oj1HEX9iXycJFoAb_qhI4ietRc5Z2wQO6ekF9MOZ0VtMcLAyX0zASY-NPEcf3byX0INP-2zJDSF4TOEXNbMbMnVeKFgmLgQKDseUsl1ieofPVY7df8QVvpTs98VAw2_g2XwTsLemBcpxfalvMRBwViN6PyJI8A-gJJToolyDafHbzIco7bH4X4y5bzZsUh5yB6ZUMy0goBkAV_KPLepnA8X2OjEJef8GHyqgHVi.QQtjD-E_MZq72hb4g0BEbw

My proxy.json file is:

{
   "target-url": "http://localhost:7005",
   "bind-address":"0.0.0.0",
   "http-port":"8080",
   "applications":[
      {
        "base-path":"/",
        "adapter-config":{
            "realm":"realm",
            "resource":"realm_ui",
            "auth-server-url":"http://localhost:8800/auth",
            "ssl-required":"external",
            "credentials": {
             "secret":"secret"
            },
            "confidential-port":0
        },
        "constraints":[
            {
               "pattern":"/*",
               "roles-allowed":[
                  "user"
               ]
            }
         ]
      }
   ]
}

In Keycloak:

Access Type: confidential
Standard Flow Enabled: ON
Direct Access Grands: ON
The Valid Redirect URI: *
GenKa
  • 156
  • 1
  • 9

2 Answers2

7

After searching for a while, I found the solution. It was a networking problem. Keycloak OpenIDConnect Authentication flow follows 3 steps, as explained here: https://www.keycloak.org/docs/3.3/server_admin/topics/sso-protocols/oidc.html

Step 1 & 2 were completed, but upon receiving the temporary code from the browser the application was unable to connect with Keycloak. In step 1&2 it is always the browser connecting to application or Keycloak, not them speaking with each other.

This happened, because within my docker-compose file I declared networks that overwrote the automatic binding to 0.0.0.0 of Keycloak and the proxy. Additionally, the auth-server-url to connect to Keycloak must be true for the browser as well as the docker container of the Keycloak security proxy.

GenKa
  • 156
  • 1
  • 9
  • 1
    What would it mean, if the error appears when one is not using docker? – farahm Apr 30 '19 at 14:18
  • 1
    That you're probably having a network problem. It might be a proxy. As you're not using Docker Ketchikan should not be automatically be confessed to 0.0.0.0. I would check carefully over all the ip addresses and maybe try using wire shark you find the solution. – GenKa May 02 '19 at 18:29
0

Make sure credential secret and auth-server-url values are same in keycloak.json and proxy.json files. Also, try removing "confidential-port":0 in the proxy.json file.

I think having a company proxy is not the reason for this error.

Ashen Jayasinghe
  • 472
  • 1
  • 3
  • 14
  • Thanks for your help. You are correct, the company proxy wasn't the problem. The removal of the cofindential-port:0 also didn't affect it. – GenKa Aug 20 '18 at 09:01