docker resolution causes RMSSOAuthenticator error, failed to load IDP config? Or something else?

kundeng

Rapidminer is installed on a VM (running docker) with valid certs for DNS "rapid.lab.bayeslearner.org".  
The browser error is RMSSOAuthenticator error, failed to load IDP configuration,  and the browser shows that the cert is valid. 

When I ping the IP from the container rm-server-svc, I get:

rapidminer@rm-server-svc:/$ ping 192.168.1.231

PING 192.168.1.231 (192.168.1.231) 56(84) bytes of data.

64 bytes from 192.168.1.231: icmp_seq=1 ttl=64 time=0.476 ms

64 bytes from 192.168.1.231: icmp_seq=2 ttl=64 time=0.144 ms

64 bytes from 192.168.1.231: icmp_seq=3 ttl=64 time=0.092 ms

64 bytes from 192.168.1.231: icmp_seq=4 ttl=64 time=0.132 ms

^C

--- 192.168.1.231 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 70ms

rtt min/avg/max/mdev = 0.092/0.211/0.476/0.154 ms

When I ping using DNS name, I got the following.  It seems that it is resolved to connect to one of the internal containers (wrongly?) 

rapidminer@rm-server-svc:/$ ping rapid.lab.bayeslearner.org

PING rapid.lab.bayeslearner.org (172.29.0.3) 56(84) bytes of data.

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=1 ttl=64 time=12.7 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=2 ttl=64 time=0.156 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=3 ttl=64 time=0.100 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=4 ttl=64 time=0.093 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=5 ttl=64 time=0.153 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=6 ttl=64 time=0.125 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=7 ttl=64 time=0.103 ms

64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=8 ttl=64 time=0.105 ms

^C

--- rapid.lab.bayeslearner.org ping statistics ---

8 packets transmitted, 8 received, 0% packet loss, time 161ms

rtt min/avg/max/mdev = 0.093/1.692/12.705/4.162 ms


When I run wget, connection is refused.  

rapidminer@rm-server-svc:/$ wget https://rapid.lab.bayeslearner.org:8443

--2022-12-20 22:28:38--  https://rapid.lab.bayeslearner.org:8443/

Resolving rapid.lab.bayeslearner.org (rapid.lab.bayeslearner.org)... 172.29.0.3

Connecting to rapid.lab.bayeslearner.org (rapid.lab.bayeslearner.org)|172.29.0.3|:8443... failed: Connection refused.

I saw in the log of rm-server-svc: 
2022-12-20 21:57:24,963 WARN  [org.keycloak.adapters.KeycloakDeployment] (http-/0.0.0.0:8080-1) Failed to load URLs from https://rapid.lab.bayeslearner.org:8443/auth/realms/master/.well-known/openid-configuration: java.net.ConnectException: Connection refused (Connection refused)

What did I do wrong?  Also why does an internal container such as rm-server-svc try to contact an external public URL. I understand it is related to keycloak integration, but it doesn't seem to make sense to me. 

kundeng

The keycloak component seems to be up and running:
https://rapid.lab.bayeslearner.org:8443/auth/admin/master/console/#/realms/master

Oh also if I hit the URL https://rapid.lab.bayeslearner.org:8443/auth/realms/master/.well-known/openid-configuration from a browser, it works:

{"issuer":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master","authorization_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/auth","token_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token","token_introspection_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token/introspect","userinfo_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/userinfo","end_session_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/logout","jwks_uri":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/certs","check_session_iframe":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/login-status-iframe.html","grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public","pairwise"],"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA1_5"],"id_token_encryption_enc_values_supported":["A128GCM","A128CBC-HS256"],"userinfo_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"response_modes_supported":["query","fragment","form_post"],"registration_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/clients-registrations/openid-connect","token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"token_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"claims_supported":["aud","sub","iss","auth_time","name","given_name","family_name","preferred_username","email","acr"],"claim_types_supported":["normal"],"claims_parameter_supported":false,"scopes_supported":["openid","microprofile-jwt","web-origins","roles","phone","address","email","profile","offline_access"],"request_parameter_supported":true,"request_uri_parameter_supported":true,"code_challenge_methods_supported":["plain","S256"],"tls_client_certificate_bound_access_tokens":true,"introspection_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token/introspect"}

kundeng

If I change public URL to ip. I got this in the log: 2022-12-21 04:04:00,023 WARN [org.keycloak.adapters.KeycloakDeployment] (http-/0.0.0.0:8080-2) Failed to load URLs from https://192.168.1.231:8443/auth/realms/master/.well-known/openid-configuration: javax.net.ssl.SSLException: Certificate for <192.168.1.231> doesn't match common name of the certificate subject: *.lab.bayeslearner.org

jwpfau

Hi,

have you already tried the suggestions from this post https://community.rapidminer.com/discussion/comment/182057/#Comment_182057 ?

Greetings,
Jonas

kundeng

I tried. It didn't work.  

For some reason, in the rm_server_svc container,  rapid.lab.bayeslearner.org is resolved to the proxy container's internal IP, not the physical host's external IP (192.168.1.231).    When this happens, the docker port-mapping 8443:443 is bypassed and the request is not forwarded to the keycloak container.   

rapidminer@rm-server-svc:/$ host rapid.lab.bayeslearner.org

rapid.lab.bayeslearner.org has address 172.17.11.2

rapidminer@rm-server-svc:/$ wget https://172.17.11.2:443/auth/realms/master/.well-known/openid-configuration

--2022-12-21 14:54:57--  https://172.17.11.2/auth/realms/master/.well-known/openid-configuration

Connecting to 172.17.11.2:443... connected.

The certificate's owner does not match hostname ‘172.17.11.2’

rapidminer@rm-server-svc:/$ 

kundeng

The problem itself is fixed by commenting out the aliases for the proxy, but it seems there are some other things breaking (links in the landing page).   It makes no sense (to me) to require internal services to go through the proxy, but  IF internal services have to use the proxy to reach other services, those aliases created half-baked bypass that interfered with host port-mapping.   

networks:

rm-go-proxy-net:

aliases:

- rm-proxy-svc

# - ${PUBLIC_DOMAIN}

rm-platform-int-net:

aliases:

- rm-proxy-svc

# - ${PUBLIC_DOMAIN}

jupyterhub-user-net:

aliases:

# - ${PUBLIC_DOMAIN}

- rm-proxy-svc

kundeng

Any updates?