Authservice not accepting http endpoints: invalid authorization_uri about authservice

[cfryanr]

Hi @MeghanaSrinath, thanks for reaching out and sharing the details of your issue.

So far we've written the code to only support https, because we thought that in practice everyone would want to use https for security reasons, even in non-production systems. We're certainly open to feedback on that and would appreciate any details you could provide on your use case and why you've set up your system to use http.

In terms of certificates, there is no particular restriction. The Authservice will check the full validity of the server's certificate, including checking that the container's OS trusts the CA. We recently introduced a setting called trusted_certificate_authority in the config (see docs at docs/README.md) to allow you to configure any CA to be additionally trusted, which makes it easy to trust systems who certs perhaps were not signed by a generally trusted CA.

[MeghanaSrinath]

Hi @cfryanr ,
Thanks for the clarifications. We have actually setup keycloak to be accessed via nginx ingress. A DNS record is created for this nginx ingress and certmanager is used to authenticate the ownership of the DNS (Thanks to @snkshukla 's help on this). So authservice works perfectly with this setup.
But when we use keycloak as a load balancer by exposing it on port 443 (with no certmanager), we weren't able to redirect back to the application page after keycloak login. We could see the below errors in keycloak container:

03:19:39,280 ERROR [io.undertow.request] (default I/O-2) Closing SSLConduit after exception on handshake: javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 is not enabled or supported in server context
        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.negotiateProtocol(ClientHello.java:883)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:835)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
        at [email protected]//io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1072)
        at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
        at java.base/java.lang.Thread.run(Thread.java:834)

03:20:02,929 ERROR [io.undertow.request] (default I/O-2) Closing SSLConduit after exception on handshake: javax.net.ssl.SSLHandshakeException: no cipher suites in common
        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254)
        at java.base/sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(ServerHello.java:460)
        at java.base/sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(ServerHello.java:295)
        at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
        at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1102)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:854)
        at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
        at [email protected]//io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1072)
        at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
        at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
        at java.base/java.lang.Thread.run(Thread.java:834)

This made us wonder if not having certificates at keycloak level is causing this issue, as everything worked fine with the first setup.
If you can provide us with any clarifications regarding this, that'd be great!

Now from the implementation perspective, we have a use case wherein we are automating this entire authentication setup with keycloak, istio and authservice. So, considering the first setup with nginx ingress, we wont be able to create any DNS record beforehand and it has to be done on the fly. We are still exploring other options on this.
Hence, we were wondering if authservice can work with http so all of this can be simplified.
Please let me know your thoughts on this :)

[cfryanr]

@MeghanaSrinath, thanks for explaining your use case more. There's one more thing that I don't think I'm understanding...

It sounds like you're at the step where keycloak has redirected the user's browser back to the application, the authservice has intercepted that request and is trying to make an HTTPS POST request back to keycloak to exhange the authcode for some tokens. From your keycloak logs, I'm guessing that keycloak was not configured to accept HTTPS requests?

That particular request has the oauth client ID and client secret in plain text as a header, has the authorization code in plain text as a param, and has the user's tokens in plain text in the response body. As you know, all of those secrets would be potentially devastating to the security posture of your app if they were leaked to an outside observer. That observer would, at the very least, be able to act as the user who was trying to log in to the app, and not just for now, but also be able act as that user for the indefinite future until the user's refresh token expired. This is why we were assuming that you would want to protect that data in transit by using TLS encryption in all cases, even in non-prod systems.

I'm curious if maybe you have some other data protection scheme in mind, and maybe that's why you're suggesting that HTTP would be okay for your use case?

[MeghanaSrinath]

@cfryanr , We were looking at options whether we can secure this while having HTTP, but we haven't yet come to any conclusion. So we do not have much on this idea yet. But yes, HTTPS is always a better way to do it.

It sounds like you're at the step where keycloak has redirected the user's browser back to the application, the authservice has intercepted that request and is trying to make an HTTPS POST request back to keycloak to exhange the authcode for some tokens. From your keycloak logs, I'm guessing that keycloak was not configured to accept HTTPS requests?

Yes, you are right. Its at this step, we're having the issue.
We have exposed keycloak on port 443 as HTTPS LoadBalancer. But still we obtained the errors which I have posted in my previous thread. Authservice worked totally fine when keycloak was accessed via nginx ingress with the required certificates.
So we were just wondering if there is any additional setup that is required for keycloak or authservice with respect to the ingress/certificates part.
Please let me know your thoughts on this!

[cfryanr]

Hi @MeghanaSrinath, I'm sorry, I'm not sure what's happening with your keycloak setup. The Java exception log messages that you shared previously makes it look as though the key manager for accepting incoming TLS connections is not configured correctly, however I'm not personally familiar with using Keycloak, so I'm not sure. My guess is that there could be more configuration that you would need to do for Keycloak. Perhaps reviewing this part of their guide might help: https://www.keycloak.org/docs/latest/server_installation/#_setting_up_ssl

[MeghanaSrinath]

@cfryanr , Thank you for the analysis. I will check my keycloak configuration.

[zimmertr]

HTTP is useful for local dev. I have a small Kustomize project to deploy Istio, Authservice, and Keycloak to Minikube and the requirement for Keycloak to leverage TLS adds a lot of complexity to something that would otherwise normally be simple.