OpaInfoFetcher missing/bad TLS config results in confusing error message

We moved from an on-prem Keycloak (16.0.1) to a managed keycloak (24.0.4) for a customer. It worked fine for basically all required products (Trino, Superset, Datahub etc.) but the OPA infofetcher was unhappy with just changing the endpoint and clientId / clientSecret.

user-info-fetcher 2024-12-05T11:52:15.473210Z  WARN stackable_opa_user_info_fetcher: Error while processing request error=failed to get user information from Keycloak error.sources=[failed to get access_token, http response 405 for "https://foo.bar.de/realms/foobar/protocol/openid-connect/token" with response body "{\"error\":\"HTTP 405 Method Not Allowed\",\"error_description\":\"For more on this error consult the server log at the debug level.\"}"] 

That was the error from the info fetcher. The get "access-token" call is 100% a POST HTTP call etc.
The managed Keycloak actually was complaining about (and receiving) a GET request.

This was very misleading, since the actual problem was missing the webPki trust.

    userInfo:
      backend:
        keycloak:
          hostname: "{{ .Values.keycloak }}"
          clientCredentialsSecret: "opa-infofetcher-secret"
          adminRealm: "foobar"
          userRealm: "foobar"
          tls:
            verification:
              server:
                caCert:
                  webPki: {}

Since Trust/TLS this is a very common configuration mistake, i think the error messages should reflect this better.

Edit: Since this may depend on the (managed) keycloak server and setup, I did not check if i could reproduce this with other setups.

Aucun fichier ni test n’est nommé ; commencez par localiser la requête de jeton d’accès de OpaInfoFetcher et sa gestion de TLS/des erreurs. Reproduisez le problème avec la configuration Keycloak indiquée, puis vérifiez que l’absence de confiance webPki ou une confiance incorrecte produit une erreur qui identifie le problème TLS plutôt que de signaler uniquement le HTTP 405.