elytron-oidc-client configuration

[Stephen Sill II]

I've been using the elytron-oidc-client since wildfly 26 with great success.  However since the beginning I've had random issues with the following exception that happened just frequently enough to be annoying but not a show stopper.

2024-04-23 19:24:19,475 ERROR [org.wildfly.security.http.oidc] (default task-4) failed to turn code into token: java.net.SocketException: Connection reset at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:328) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:355) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:808) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:484) at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:478) at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1465)

 

Some research has suggested that this is likely a network issue in GCP where long-lived connections from wildfly to keycloak are being severed by gcp itself.  I don't see this problem with a locally minikube deployed keycloak and my wildfly app.

Some folks suggested configuring the "connection-ttl-millis" attribute to have it recycle the connections to keycloak regularly.  In trying to do this in both json configuration and via subystem, I discovered that isn't considered a legal attribute even though this page says it is.

https://docs.wildfly.org/31/wildscribe/subsystem/elytron-oidc-client/provider/index.html#attr-connection-ttl-millis

The problem appears to be that org.wildfly.security.http.oidcOidcJsonConfiguration doesn't considered this valid but the jboss-cli shows that as a valid attribute when adding a provider or secure-deployment.

Even more frustrating is that jboss-cli will allow you to add a provider with that attribute

[standalone@localhost:9990 /] /subsystem=elytron-oidc-client/provider=keycloak:add(provider-url="${OIDC_PROVIDER_URL}", connection-timeout-millis=${OIDC_CONNECTION_TTL_MILLIS}, connection-pool-size=${OIDC_CONNECTION_POOL_SIZE}, ssl-required="${OIDC_SSL_REQ}") {"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=elytron-oidc-client/provider=keycloak:read-resource()
{
    "outcome" => "success",
    "result" => {
        "allow-any-hostname" => false,
        "always-refresh-token" => false,
        "auth-server-url" => undefined,
        "autodetect-bearer-only" => false,
        "client-key-password" => undefined,
        "client-keystore" => undefined,
        "client-keystore-password" => undefined,
        "confidential-port" => 8443,
        "connection-pool-size" => 20,
        "connection-timeout-millis" => 60000L,
        "connection-ttl-millis" => undefined,
        "cors-allowed-headers" => undefined,
        "cors-allowed-methods" => undefined,
        "cors-exposed-headers" => undefined,
        "cors-max-age" => undefined,
        "disable-trust-manager" => false,
        "enable-cors" => false,
        "expose-token" => false,
        "ignore-oauth-query-parameter" => false,
        "principal-attribute" => undefined,
        "provider-url" => "https://auth.local/realms/ISPSS",
        "proxy-url" => undefined,
        "realm-public-key" => undefined,
        "register-node-at-startup" => false,
        "register-node-period" => undefined,
        "socket-timeout-millis" => undefined,
        "ssl-required" => "NONE",
        "token-signature-algorithm" => "RS256",
        "token-store" => undefined,
        "truststore" => undefined,
        "truststore-password" => undefined,
        "verify-token-audience" => false
    }
}

 

The problem comes when trying to add a secure-deployment

[standalone@localhost:9990 /] /subsystem=elytron-oidc-client/secure-deployment=guardian-war:add(provider="keycloak",client-id="${OIDC_CLIENT_ID}", credential={secret="${OIDC_CLIENT_SECRET}"}) {     "outcome" => "failed",     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyExcepti on: Unrecognized field \"connection-ttl-millis\" (class org.wildfly.security.http.oidc.OidcJsonConfiguration), not marked as ignorable (45 known properties: \" ssl-required\", \"cors-allowed-headers\", \"register-node-period\", \"redirect-rewrite-rules\", \"token-signature-algorithm\", \"turn-off-change-session-id-on- login\", \"truststore\", \"client-key-password\", \"token-store\", \"resource\", \"realm\", \"proxy-url\", \"disable-trust-manager\", \"use-realm-role-mappings \", \"autodetect-bearer-only\", \"truststore-password\", \"use-resource-role-mappings\", \"client-keystore\", \"confidential-port\", \"enable-pkce\", \"auth-se rver-url\", \"verify-token-audience\", \"cors-allowed-methods\", \"public-client\", \"expose-token\", \"token-minimum-time-to-live\", \"min-time-between-jwks-r equests\", \"ignore-oauth-query-parameter\", \"adapter-state-cookie-path\", \"cors-max-age\", \"enable-cors\", \"allow-any-hostname\", \"realm-public-key\", \" credentials\", \"principal-attribute\", \"always-refresh-token\", \"public-key-cache-ttl\", \"provider-url\", \"bearer-only\", \"client-id\", \"connection-pool -size\", \"client-keystore-password\", \"enable-basic-auth\", \"cors-exposed-headers\", \"register-node-at-startup\" [truncated]])  at [Source: (ByteArrayInputStream); line: 1, column: 139] (through reference chain: org.wildfly.security.http.oidc.OidcJsonConfiguration[\"connection-ttl-mill is\"])",     "rolled-back" => true }

This same issue occurs trying to configure via oidc.json

Would it be possible to expose connection-ttl-millis and other config options that the documentation and jboss-cli say are valid?

[Prarthona Paul]

Hello there, 

Thank you for catching that. 
It is a bug in the code where connection-timeout-millis is not one of the json properties added for oidc configuration. 
I have created an issue to track this here: https://issues.redhat.com/browse/ELY-2753

Best, 

Prarthona

[Stephen Sill II]

Hi, I was curious what release of wildfly this might end up in.  It's been in Pull Request Sent status for several months now.  This would fix an issue I've been dealing with for quite some time.

[Rebecca Searls]

There is no clear time set for this to be merged into Elytron and then WildFly.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/7b28cbaf-2d00-4810-8490-87acf745e660n%40googlegroups.com.

[Stephen Sill II]

Hi thanks for the follow-up.  I'll keep monitoring the open issue for a status change then.