Oauth2-proxy: Keycloak as provider - Got error http: named cookie not present after authenticated

Created on 23 Jun 2020 · 6Comments · Source: oauth2-proxy/oauth2-proxy

Please jump directly to "Update-3". I managed the issue reported in the title.

Deploy oauth2-proxy on Kubernetes cluster, customized it to work with the Keycloak server running also in the K8s cluster.
Deployed a dummy hello-world service, that user tries to access from browser.
The first part that consists of detecting the user is not authenticated, works fine. I got the keycloak login page. But after being authenticated, I got the following error in the browser:

403 Permission Denied
http: named cookie not present

Sign In

After I did some google search, I found this very similar issue (https://github.com/oauth2-proxy/oauth2-proxy/issues/360), but it is closed without explanation about the fix or workaround.

Update-1
I now added the "--cookie-secure=false" flag, it still failed and get following error:

[2020/06/23 12:31:41] [requests.go:25] 200 GET http://192.168.56.104/auth/realms/asms/protocol/openid-connect/userinfo {"name":"user1 user1","sub":"fe6d81a1-7dcd-483d-9f33-04d5193cd9e9","email_verified":true,"preferred_username":"user1","given_name":"user1","family_name":"user1"}
10.244.0.5 - - [2020/06/23 12:31:41] [AuthFailure] Invalid authentication via OAuth2: unauthorized
10.244.0.5 - - [2020/06/23 12:31:41] 192.168.56.104 GET - "/oauth2/callback?state=aed9a1d3a27f38f328caa0be0c8c5f11%3A%2Ffavicon.ico&session_state=696a5508-3313-4b21-879b-3166388e68ba&code=64d3d45f-3657-415c-a15d-19f2e09c56e4.696a5508-3313-4b21-879b-3166388e68ba.7dd26498-4491-4d67-bd65-aa493b791038" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36" 403 338 0.012

Update-2
After I search for the error in the code, looks that it failed here - what the meaning of the condition ?:

    // set cookie, or deny
    if p.Validator(session.Email) && p.provider.ValidateGroup(session.Email) {
        logger.PrintAuthf(session.Email, req, logger.AuthSuccess, "Authenticated via OAuth2: %s", session)
        err := p.SaveSession(rw, req, session)
        if err != nil {
            logger.Printf("%s %s", remoteAddr, err)
            p.ErrorPage(rw, 500, "Internal Error", "Internal Error")
            return
        }
        http.Redirect(rw, req, redirect, 302)
    } else {
        logger.PrintAuthf(session.Email, req, logger.AuthFailure, "Invalid authentication via OAuth2: unauthorized")
        p.ErrorPage(rw, 403, "Permission Denied", "Invalid Account")
    }

Update-3
I finally understood the meaning of the condition above, and I configure an emial for the user, and it succeeded to authenticated.
Now, I have two more issues/questions:
1 - the original URI I gave in the browser was "bonjour/polo", and after authentication succeeded, the browser was redirected to "bonjour/:443". The logs are below:

[2020/06/23 13:04:39] [requests.go:25] 200 GET http://192.168.56.104/auth/realms/asms/protocol/openid-connect/userinfo {"sub":"fe6d81a1-7dcd-483d-9f33-04d5193cd9e9","email_verified":true,"name":"user1 user1","preferred_username":"user1","given_name":"user1","family_name":"user1","email":"[email protected]"}
10.244.0.5 - [email protected] [2020/06/23 13:04:39] [AuthSuccess] Authenticated via OAuth2: Session{email:[email protected] user: PreferredUsername: token:true}
10.244.0.5 - - [2020/06/23 13:04:39] 192.168.56.104 GET - "/oauth2/callback?state=199c1eb6655785a9af6f0680f3f4d689%3A%2Fbonjour%2F%3A443&session_state=21f64f62-5cd2-4979-b795-6b2080005c3b&code=7b195ba7-6d46-492f-92f1-dbf51e8e1d03.21f64f62-5cd2-4979-b795-6b2080005c3b.7dd26498-4491-4d67-bd65-aa493b791038" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36" 302 36 0.028
10.244.0.5 - [email protected] [2020/06/23 13:04:39] 192.168.56.104 GET - "/bonjour/:443" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36" 200 13 0.000

2 -After authenticated, when redirected to the initial url, I expected to see the access_token (JWT) that hold the users info in the headers, but I only found the
keycloak standard tokens and the _oauth2_proxy that looks like a token, but failed to decode it at jwt.io site.

Expected Behavior

Expect to be redirected to the dummy hello-world service.

Current Behavior

Got error : permission denied with error on the cookie.

The following appears in the log

[2020/06/23 07:46:04] [requests.go:25] 200 GET http://192.168.56.104/auth/realms/asms/protocol/openid-connect/userinfo {"name":"user1 user1","sub":"fe6d81a1-7dcd-483d-9f33-04d5193cd9e9","email_verified":false,"preferred_username":"user1","given_name":"user1","family_name":"user1"}
10.244.0.5 - - [2020/06/23 07:46:04] [AuthFailure] Invalid authentication via OAuth2: unable too obtain CSRF cookie
10.244.0.5 - - [2020/06/23 07:46:04] 192.168.56.104 GET - "/oauth2/callback?state=2c296b5b166b30fe3659e8150451fbbd%3A%2Fbonjour%2Fhello&session_state=160e7f17-7ca3-4eaf-8385-e122dcdff241&code=7c698e71-b406-4ca4-a92a-54e5dda575d1.160e7f17-7ca3-4eaf-8385-e122dcdff241.7dd26498-4491-4d67-bd65-aa493b791038" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36" 403 353 0.070

Possible Solution

Steps to Reproduce (for bugs)

1 - Deploy keycloak
2 - Deploy oauth2-proxy and customize it with realm and other settings
3 - deploy dummy hello-world service
4 - Configure the istio gateway to terminate tls traffic on the edge (gateway) and forward the traffic over clear http

Context

Your Environment

Centos 7.8, Kubernetes 1.18.4, Istio 1.6.1, Keycloak (last version)
oauth2-proxy

Version used:
oauth2_proxy v5.1.1 (built with go1.14.2)

Stale configuration question

Source

yaakov-berkovitch

👍1

Most helpful comment

@yaakov-berkovitch Have you find a solution for this issue? Because I am facing the same issue on my project. It going in an infinite redirect loop with error "Error loading cookied session: http: named cookie not present, removing session"

l7devops on 26 Nov 2020

👍2

All 6 comments

Can you please provide your configuration so that we can see which options you have provided before we attempt to work out what's happened here?

JoelSpeed on 25 Jun 2020

Thanks - Sure following additional information.

oauth2-proxy k8s deployment yml as follows:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
        - args:
            - --provider=keycloak
            - --provider-display-name="Keycloak"
            - --email-domain=*
            - --pass-access-token=true
            - --pass-authorization-header=true
            - --set-authorization-header=true
            - --oidc-issuer-url=http://192.168.56.104/auth/realms/asms
            - --login-url=http://192.168.56.104/auth/realms/asms/protocol/openid-connect/auth
            - --redeem-url=http://192.168.56.104/auth/realms/asms/protocol/openid-connect/token
            - --validate-url=http://192.168.56.104/auth/realms/asms/protocol/openid-connect/userinfo
            - --http-address=0.0.0.0:4180
            - --cookie-expire=4h0m0s
            - --cookie-domain=192.168.56.104
            - --standard-logging=true
            - --auth-logging=true
            - --request-logging=true
            - --skip-provider-button=true
            - --upstream=static://
            - --cookie-secret=KVgwiyRNt_deA_shUsVgoQ==
            - --client-secret=9bae365c-3d88-4843-a089-84ccb65fb1d9
            - --skip-auth-preflight=true
            - --cookie-secure=false
            - --pass-access-token=true
          env:
            - name: OAUTH2_PROXY_CLIENT_ID
              value: gatekeeper
            - name: OAUTH2_PROXY_CLIENT_SECRET
              value: 9bae365c-3d88-4843-a089-84ccb65fb1d9
            - name: OAUTH2_PROXY_COOKIE_SECRET
              value: KVgwiyRNt_deA_shUsVgoQ==
            - name: OAUTH2_PROXY_COOKIE_DOMAIN
              value: 192.168.56.104
          image: bitnami/oauth2-proxy:latest
          imagePullPolicy: IfNotPresent
          name: oauth2-proxy
          ports:
            - containerPort: 4180
              protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauthproxy-service
  namespace: default
spec:
  ports:
    - name: http
      port: 4180
      protocol: TCP
      targetPort: 4180
  selector:
    k8s-app: oauth2-proxy

I have also an istio virtual service that forward all the ingress traffic from port 80 to oauth2-proxy:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: oauth2-proxy
spec:
  gateways:
    - istio-ingressgateway.istio-system.svc.cluster.local
  hosts:
    - '*'
  http:
    - name: "proxy-routes"
      match:
        - port: 80
      route:
        - destination:
            host: oauthproxy-service
            port:
              number: 4180
    - name: "proxy-routes-2"
      match:
        - uri:
            prefix: /oauth2
      route:
        - destination:
            host: oauthproxy-service
            port:
              number: 4180

yaakov-berkovitch on 26 Jun 2020

I'm finding it a little hard to parse what the actual issue here is with the edits and updates. Perhaps you could help clarify the outstanding problems?

"bonjour/:443".

This looks like a broken force_https, this should be fixed in the latest version, though there may also be a bug in that so I may have to cut a v6.0.1 or v6.1.0 in the near future

I expected to see the access_token (JWT) that hold the users info in the headers

This isn't currently supported by the keycloak provider, but you can use the OIDC provider with keycloak instead and that will then be supported

        - name: OAUTH2_PROXY_COOKIE_DOMAIN
          value: 192.168.56.104

This might have to be an actual domain, I'm not sure, but I'd check the set-cookie responses you'll get from the response to the callback URL to see if it's actually working

JoelSpeed on 7 Jul 2020

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.