Per von Zweigbergk created GUACAMOLE-2038:
---------------------------------------------
Summary: Outbound connections to JWKS endpoint fails in IPv6-only
environment, causing a redirect loop
Key: GUACAMOLE-2038
URL: https://issues.apache.org/jira/browse/GUACAMOLE-2038
Project: Guacamole
Issue Type: Bug
Components: guacamole-auth-openid
Affects Versions: 1.5.5
Reporter: Per von Zweigbergk
If you are running guacamole (server) in an ipv6-only environment, with the
OIDC plugin for authentication, authentication will fail, causing a redirect
loop.
The following message appears repeatedly in the guacamole application log
(truncated for privacy and brevity) while the client is stuck in a redirect
loop:
{{guacamole_compose | 09:45:03.595 [http-nio-8080-exec-8] INFO
o.a.g.a.o.t.TokenValidationService - Rejected invalid OpenID token: JWT
processing failed. Additional details: [[17] Unable to process JOSE object
(cause: org.jose4j.lang.UnresolvableKeyException: Unable to find a suitable
verification key for JWS w/ header
\{"typ":"JWT","alg":"RS256","kid":"<REDACTED>"} due to an unexpected exception
(java.net.ConnectException: Network is unreachable (connect failed)) while
obtaining or using keys from JWKS endpoint at
https://login.microsoftonline.com/...... <REST OF LINE REDACTED>}}
The error above suggests a failure to connect to the backend server (in this
case login.microsoftonline.com).
The root cause of this seems to be that Java doesn't have a great algorithm for
address selection, as documented in this OpenJDK bug, but it's not clear where
the correct place to fix this is. Reference:
[https://bugs.openjdk.org/browse/JDK-8170568]
Briefly, what seems to happen is that a connection to login.microsoftonline.com
is attempted with IPv4 first, which fails (because there's no IPv4 address
configured in my container), and that makes the connection give up completely
instead of re-trying using IPv6.
The workaround for this is to set the JAVA_OPTS environment variable in the
docker container to:
-Djava.net.preferIPv6Addresses=true
(I'm sure there are ways to set these options too if you're not running docker.)
I'm not sure, but I think this would affect any outgoing connections from the
guacamole server itself, not just outbound connections for OIDC.
Not sure what the solution to this should be, but ideally I'd expect a
well-behaved application making HTTP requests to try connecting using IPv6
first (if available) and then fall back to IPv4, and not, which is what seems
to happen now, just try IPv4 and then fail if it doesn't work. Perhaps this
should be documented and a more "user friendly" method to enable this flag
should be set?
(Also, and I'm not sure if this is a seperate bug, or if it's even a bug at
all, but causing a redirect loop because of a problem like this doesn't really
seem like a great failure more. It appears to stop after a while, but only
because the IdP stops redirecting after a while after repeated failures, not
because of anything Guacamole does.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
