arrikto / oidc-authservice Goto Github PK

Is this a bug report or feature request?

• Feature Request

What should the feature do:
Update container image on gcr.io

What is use case behind this feature:
The image (gcr.io/arrikto/kubeflow/oidc-authservice) haven't been updated since 2019

Additional Information:

Add the option to whitelist hostnames in the authservice.
The hostname is found from the Host header.

Ran into an issue while doing the SSO integration with the PingFed. Please look into the AuthService Logs below
time="2020-04-07T21:34:05Z" level=info msg="Starting readiness probe at 8081"
time="2020-04-07T21:34:05Z" level=info msg="No USERID_TOKEN_HEADER specified, using 'kubeflow-userid-token' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SERVER_HOSTNAME specified, using '' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SERVER_PORT specified, using '8080' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SESSION_MAX_AGE specified, using '86400' as default."
time="2020-04-07T21:34:05Z" level=info msg="Starting web server at :8080"
2020/04/07 21:40:50 http: panic serving 10.233.66.18:43662: interface conversion: interface {} is nil, not string
goroutine 214 [running]:
net/http.(*conn).serve.func1(0xc000381e00)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00055af30)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001e20e0, 0xc000208100)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001e20e0, 0xc000208100)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000381e00, 0x9b7ea0, 0xc00013bb80)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
time="2020-04-07T21:44:48Z" level=error msg="Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {"error_description":"Authorization code is invalid or expired.","error":"invalid_grant"}" ip=10.233.66.18 request="/login/oidc?code=PhJGP90OeqIoGhe56evdCulkeGmI2hT-v8gAAABl&state=MTU4NjI5NTU1NXxFd3dBRURoR01uRk9aa2hMTldFNE5HcHFTbXM9fI9GpI-9uyFgS3-5-Qr6-B3Wy2-EavOY5zlxVnJ37Azm"
2020/04/07 21:45:40 http: panic serving 10.233.66.18:46904: interface conversion: interface {} is nil, not string
goroutine 319 [running]:
net/http.(*conn).serve.func1(0xc000169a40)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc0001d2030)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc000428700, 0xc0001b4600)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc000428700, 0xc0001b4600)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000169a40, 0x9b7ea0, 0xc00013b9c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
time="2020-04-07T21:46:39Z" level=error msg="Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {"error_description":"Authorization code is invalid or expired.","error":"invalid_grant"}" ip=10.233.66.18 request="/login/oidc?code=_FHY6Gfl-8jVZy3u3-xzT2TKx_BvX95us8sAAAB0&state=MTU4NjI5NTkzN3xFd3dBRUZkVFVESk9ZMGhqYVZkMmNWcFVZVEk9fCksLhTvEX1rLWiEGQn3yO4yo7sIhCSFvhlg2CVXmS6k"
2020/04/07 21:47:09 http: panic serving 10.233.66.18:47968: interface conversion: interface {} is nil, not string
goroutine 411 [running]:
net/http.(*conn).serve.func1(0xc00041f720)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00023cae0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0004280e0, 0xc000164100)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0004280e0, 0xc000164100)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc00041f720, 0x9b7ea0, 0xc000322a40)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 21:47:28 http: panic serving 10.233.66.18:48424: interface conversion: interface {} is nil, not string
goroutine 400 [running]:
net/http.(*conn).serve.func1(0xc000169a40)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc0001d8cf0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001661c0, 0xc0004e4700)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001661c0, 0xc0004e4700)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000169a40, 0x9b7ea0, 0xc00013bf80)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 21:47:43 http: panic serving 10.233.66.18:48570: interface conversion: interface {} is nil, not string
goroutine 437 [running]:
net/http.(*conn).serve.func1(0xc000381e00)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00023de90)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc000362a80, 0xc000668c00)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc000362a80, 0xc000668c00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000381e00, 0x9b7ea0, 0xc0003227c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 22:43:16 http: panic serving 10.233.66.18:43668: interface conversion: interface {} is nil, not string
goroutine 273 [running]:
net/http.(*conn).serve.func1(0xc0003d3680)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00055acc0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001e2380, 0xc000164300)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001e2380, 0xc000164300)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc0003d3680, 0x9b7ea0, 0xc0002aa2c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
(base)

Following is the Kustomize Config am using

• kustomizeConfig:
  overlays:
  • application
    parameters:
  • name: namespace
    value: istio-system
  • name: userid-header
    value: kubeflow-userid
  • name: oidc_provider
    value: https://fam-dev.kp.org
  • name: oidc_redirect_uri
    value: http://http://172.16.190.65/login/oidc
  • name: oidc_auth_url
    value: https://fam-uat.kp.org/as/authorization.oauth2
  • name: skip_auth_uri
    value: /dex
  • name: client_id
    value: kubeflow-oidc-authservice
    repoRef:
    name: manifests
    path: istio/oidc-authservice
    name: oidc-authservice

Please let me know if you need additional configuration details ?

Is this a bug report or feature request?

• Bug Report

Describe the bug
AuthService used with KubeFlow 1.7 and OIDC passes all requests as whitelisted.

I am not sure why SkipAuthURLs is empty but the requests are all whitelisted.

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService in kubeflow 1.7 using kustmize
2. Access top page of kubeflow
3. See error in authservice log by kubectl logs authservice-0 -n kubeflow

Logs
The logs from authservice is as follows.

time="2023-06-17T07:01:50Z" level=info msg="Config: &{ProviderURL:https://xxxxxxxx ClientID:xxxxxx ClientSecret:xxxxxxx OIDCAuthURL: RedirectURL:https://xxxxxx/oidc/callback OIDCScopes:[openid profile email groups] StrictSessionValidation:false OIDCStateStorePath:/var/lib/authservice/data.db AuthserviceURLPrefix:https://xxxxxxx SkipAuthURLs:[] AuthHeader:Authorization Audiences:[istio-ingressgateway.istio-system.svc.cluster.local] HomepageURL:https://xxxxxxx/site/homepage AfterLoginURL: AfterLogoutURL:https://xxxxxxxx/site/after_logout UserIDHeader:kubeflow-userid GroupsHeader:kubeflow-groups UserIDPrefix: UserIDTransformer:{rules:[]} UserIDClaim:email UserIDTokenHeader: GroupsClaim:groups IDTokenHeader:Authorization Hostname: Port:8080 WebServerPort:8082 ReadinessProbePort:8081 CABundlePath: SessionStorePath:/var/lib/authservice/data.db SessionMaxAge:86400 SessionSameSite:Lax ClientName:AuthService ThemesURL:themes Theme:kubeflow TemplatePath:[web/templates/default] UserTemplateContext:map[] GroupsAllowlist:[*]}"
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request="/?ns=kubeflow-user-example-com"
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/webcomponentsjs/webcomponents-loader.js
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/app.css
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/webcomponentsjs/custom-elements-es5-adapter.js
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/vendor.bundle.js
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/app.bundle.js
time="2023-06-17T07:02:32Z" level=info msg="URI is whitelisted. Accepted without authorization." ip=192.168.93.103 request=/dashboard_lib.bundle.js

Environment:

• AuthService version: gcr.io/arrikto/kubeflow/oidc-authservice:e236439
• Platform: custom kubernetes cluster where kubeflow/manifests deployed
• Kubernetes version: 1.24

Is this a bug report or feature request?

• Feature Request

Add wildcard support for GROUPS_ALLOWLIST.

What should the feature do:

For example, abc*,*bcd,*ccc* will match abc-any-character, any-character-bcd and any-character-ccc-any-character respectively

match("*est", "test") == true
match("est*", "establish") == true
match("*est*", "bestablish") == true
match("t*e*s*t", "ttttteeeeeeeesttttttt")) == true
match("t*e*s*t", "tset") == false
match("test", "testing") == false
match("test*", "1testing") == false

What is use case behind this feature:

To manage common sub-groups authorization rules instead of having very verbose GROUPS_ALLOWLIST

Additional Information:

• Feature Request

What should the feature do:
Currently the there is no support for ES256 signing algorithm with go-oidc v2. We need support for ES256 signing algorithm

What is use case behind this feature:
OIDC token provider need to have a wider list of support for signing algorithms than just RS256

Token that i used throws the following error

level=error msg="Not able to verify ID token: oidc: id token signed with unsupported algorithm, expected [\"RS256\"] got \"ES256\""

There are cases where a user's OIDC Provider is using a self-signed certificate.
In those cases, we want the user to be able to specify the custom CA in the oidc-authservice, so that it will trust it.

Is this a bug report or feature request?

• Bug Report

Describe the bug
After a while, the authservice pod consume a lot of memory

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService version e236439 with oidc provider
2. Wait a while (6 hours) and check the authservice pod

Expected behavior
Memory consumption should be stable

When AFTER_LOGIN_URL is set, authservice will always redirect to a predefined URL.
This means that the original URL that the user was before authentication is lost.

A mechanism should be introduced that informs the target AFTER_LOGIN_URL endpoint the original user URL.

Hi,

We are in the process of upgrading our KF1.0.2 to KF1.3 and it broke our Logout functionality that we have integrated with Ping OIDC. Am trying to get the right code base to do the debugging in our environment. Is there a way to point or pull the Code for
gcr.io/arrikto/kubeflow/oidc-authservice:28c59ef from this repo?

@yanniszark @kimwnasptd .
Appreciate any help. Thank you.

Hello,

I am trying to connect kubeflow to keycloak now using the authservice. However, i get 404 whenever i get redirected to keycloak.

Here is my kustomizeconfig for the authservice

  - kustomizeConfig:
       overlays:
       - application
       parameters:
       - name: namespace
         value: istio-system
       - name: userid-header
         value: kubeflow-userid
       - name: oidc_provider
         value: http://keycloak-http.keycloak.svc:80/auth/realms/kubeflow
       - name: oidc_redirect_uri
         value: /login/oidc
       - name: client_id
         value: kubeflow
       repoRef:
         name: manifests
         path: istio/oidc-authservice
     name: oidc-authservice

Flow goes as follows:

entry point is the istio ingress gateway.
It redirects to the authservice
the authservice redirects to keycloak (which asks me to log in with username and password)
one I give a valid username and password I don't get redirected to the central dashboard but instead to a 404 - not found page with Url (http://keycloak-http.keycloak.svc/login/oidc?state=MTYwMjU5MzI1M3xFd3dBRUVSell6SlhSRGhHTW5GT1praExOV0U9fPim4CovjsV8V1mYBraB2SRuETV4-D9TuHpkeiYyZyEn&session_state=e78c415e-5c7c-40c1-a733-fbe0e3cd060d&code=c0ac69ee-7fdf-4da6-8a66-d31746222cc2.e78c415e-5c7c-40c1-a733-fbe0e3cd060d.1a57a03e-7290-4237-acf5-5ea358ab4cf8)
Discovery Doc:

{"issuer":"http://10.101.65.187/auth/realms/kubeflow","authorization_endpoint":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/auth","token_endpoint":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/token","introspection_endpoint":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/token/introspect","userinfo_endpoint":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/userinfo","end_session_endpoint":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/logout","jwks_uri":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/certs","check_session_iframe":"http://10.101.65.187/auth/realms/kubeflow/protocol/openid-connect/login-status-iframe.html","grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public","pairwise"],"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA1_5"],"id_token_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"userinfo_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"response_modes_supported":["query","fragment","form_post"],"registration_endpoint":"http://10.101.65.187/auth/realms/kubeflow/clients-registrations/openid-connect","token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"token_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"claims_supported":["aud","sub","iss","auth_time","name","given_name","family_name","preferred_username","email","acr"],"claim_types_supported":["normal"],"claims_parameter_supported":false,"scopes_supported":["openid","groups","microprofile-jwt","web-origins","roles","phone","address","email","profile","offline_access"],"request_parameter_supported":true,"request_uri_parameter_supported":true,"code_challenge_methods_supported":["plain","S256"],"tls_client_certificate_bound_access_tokens":true}

Is this a bug report or feature request?

• Bug Report

Describe the bug
When using AWS Cognito the email_verified field is a string "true" instead of a boolean, causing an unmarshal error in

It appears that apple and paypal have similar issues with using string values as well. This is nonconformant to the OpenID spec, but it's annoying enough to want work around.

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService using Cognito as the OIDC IdP.
2. Start the auth code sign in.
3. Sign in to Cognito.
4. Return to AuthService authorization callback, which will error while retrieving you user info.

Expected behavior
Sign in should work and retrieve your email.

Config Files
All defaults except for the mandatory OAuth client id etc.

Logs

level=error msg="Not able to fetch userinfo: oidc: failed to decode userinfo: json: cannot unmarshal string into Go struct field UserInfo.email_verified of type bool"

Environment:

• AuthService version: fef11c3
• Platform: EKS + kubeflow 1.3
• Kubernetes version: 1.19

Additional context
This patch fixes the issue:

diff --git a/oidc.go b/oidc.go
index 3147706..586d0a4 100644
--- a/oidc.go
+++ b/oidc.go
@@ -16,7 +16,7 @@ type UserInfo struct {
        Subject       string `json:"sub"`
        Profile       string `json:"profile"`
        Email         string `json:"email"`
-       EmailVerified bool   `json:"email_verified"`
+       EmailVerified bool   `json:"email_verified,string"`
 
        RawClaims []byte
 }

Is this a bug report or feature request?

• Feature Request

What should the feature do:
The auth service could pass the raw ID Token to downstream requests in the session_authenticator after verifying cookie in a header set as per env variable AUTH_HEADER

What is use case behind this feature:
Downstream requests behind this auth service could handle custom authorization if it has access to the whole IDToken and not just the username.

Additional Information:
This was being done previously but removed recently with the new updates as shown here

Hi there I've been testing using the auth service with Ambassador AuthService. I'm stuck right now and am not sure if I have a configuration issue with Ambassador/Envoy or I was misunderstanding the capabilities of oidc-authservice. Specifically, in the OIDC callback function the request is redirected to the auth service host at oidc-auth.company.io/ORIGINAL_PATH instead of serviceA.company.io/ORIGINAL_PATH which is the host from the original request before being directed to the auth service and going through the OIDC flow. I've added some logging to the code and see that the request.URL.String() that is used for the original path in the state only includes path, without host (code: https://github.com/arrikto/oidc-authservice/blob/master/state.go).

So right now I'm stucking wondering if:

1. I have some Ambassador/Envoy config issue and the host is being stripped in the request URL
2. oidc-authservice is meant to be used to authenticate/authorize endpoints on a single service behind the edge proxy rather than multiple (which would be a little weird since AuthService object in Ambassador applies to all Mappings)
3. something else?

Let me know if you have any insights or need more info. If 2 is the case I can look into forking this and/or starting a project to suit my needs (also would like a token based auth option rather than session based).

A bit more details about the setup:

Ambassador API Gateway (open source) is being used as the edge proxy for a k8s cluster.
I have several services that are accessible through the proxy:

serviceA.company.io
serviceB.company.io
serviceC.company.io
...

An Ambassador Mapping for each service e.g.:

apiVersion: ambassador/v1
kind:  Mapping
name:  serviceA_mapping
ambassador_id: edge_proxy
host: serviceA.company.io
prefix: /
service: serviceA.namespaceA:9000

The authservice is deployed and configured as so:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oidc-auth
  namespace: edge-proxy
  labels:
    app: oidc-auth
spec:
  selector:
    matchLabels:
      app: oidc-auth
  replicas: 1
  template:
    metadata:
      labels:
        app: oidc-auth
    spec:
      serviceAccountName: edge-proxy
      containers:
      - name: oidc-auth
        image: arrikto/oidc-authservice:auth_test
        ports:
        - name: http-api
          containerPort: 8080
        - name: http-web
          containerPort: 8082
        - name: http-readiness
          containerPort: 8081
        readinessProbe:
          httpGet:
            path: /
            port: 8081
        - name:  OIDC_PROVIDER
          value: https://accounts.google.com
        - name: OIDC_SCOPES
          value: "openid profile email"
        - name: AUTHSERVICE_URL_PREFIX
          value: "https://oidc-auth.company.io/authservice/"
        - name: SKIP_AUTH_URLS
          value: ""
        - name: CLIENT_ID
          valueFrom:
            secretKeyRef:
              name: oidc-auth-secret
              key: CLIENT_ID
        - name: CLIENT_SECRET
          valueFrom:
            secretKeyRef:
              name: oidc-auth-secret
              key: CLIENT_SECRET
        volumeMounts:
        - mountPath: "/var/lib/authservice"
          name: data
      volumes:
      - name: google-oauth
        secret:
          secretName: oidc-auth-secret
      - name: data
        emptyDir: {}

apiVersion: v1
kind: Service
metadata:
  name: oidc-auth
  namespace: edge-proxy
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v2
      kind:  AuthService
      name:  authentication
      ambassador_id: edge_proxy
      auth_service: "oidc-auth.edge-proxy.svc.cluster.local:8080"
      allowed_request_headers:
      - "X-Auth-Userinfo"
      - "X-Auth-Token"
      - "authorization"
      - "cookie"
      - "Authorization"
      - "Referer"
      allowed_authorization_headers:
      - "X-Auth-Userinfo"
      - "authorization"
      - "cookie"
      - "Authorization"
      - "X-Auth-Token"
      - "Referer"
      ---
      apiVersion: ambassador/v2
      kind:  Mapping
      name:  ambassador_oidc_auth_mapping
      ambassador_id: edge_proxy
      prefix: "/authservice"
      service: "oidc-auth.edge-proxy:8080"
      host: oidc-auth.company.io
spec:
  type: ClusterIP
  selector:
    app: oidc-auth
    app.kubernetes.io/name: oidc-auth
  ports:
  - port: 8080
    name: http-oidc-auth
    targetPort: http-api

In the current code, if the userid claim is not found, the code panics, which makes it hard to debug and pinpoint the root cause.
In addition, the code should NOT panic.
This is the offending line:

How to resolve:
Check if the field exists and if it doesn't print a helpful error message in logs.

Is this a bug report or feature request?

• Bug Report

Describe the bug
When trying to use Azure AD as an OIDC provider in Kubeflow v1.6.1 as mentioned in the documentation here, I get redirected to Microsoft login. However, after successful login I get redirected back to my kubeflow website getting a page with error 403 access denied, and I get panic error in the logs of the OIDC service pod

How to Reproduce
Steps to reproduce the behavior:

1. Download the kubeflow v1.6.1 manifest here
2. Edit the manifest to use Azure AD OIDC provider as mentioned here
3. Deploy Kubeflow on Azure AKS using this guide

Expected behavior
After successful login in the Microsoft sign in page, I should be redirected back to kubeflow's dashboard and use the UI directly.

Config Files

• Kubeflow manifests here
• OIDC configuration as mentioned here

# parameters for the OIDC service
OIDC_PROVIDER=https://login.microsoftonline.com/<my-tenant-id>/v2.0
OIDC_AUTH_URL=https://login.microsoftonline.com/<my-tenant-id>/oauth2/v2.0/authorize
OIDC_SCOPES=profile email
REDIRECT_URL=https://my-kubeflow-domain.com/login/oidc
SKIP_AUTH_URI=
USERID_HEADER=kubeflow-userid
USERID_PREFIX=
USERID_CLAIM=email
PORT="8080"
STORE_PATH=/var/lib/authservice/data.db

# secret parameters for the OIDC service
CLIENT_ID=<my-Azure-AD-app-ID>
CLIENT_SECRET=<my-Azure-AD-app-secret>

Logs
These are the error logs that appear in the OIDC service pod after signing in with Microsoft

http: panic serving 10.248.0.13:42486: interface conversion: interface {} is nil, not string
goroutine 164 [running]:
net/http.(*conn).serve.func1(0xc0002f4e60)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc000102d20)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0000f8100, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0300) 
/go/src/oidc-authservice/handlers.go:150 +0x1061  
net/http.HandlerFunc.ServeHTTP(0xc0000e8340, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0300)  
/usr/local/go/src/net/http/server.go:2007 +0x44 
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0000ea0c0, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0e00)                       
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2      
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0000fe1c0, 0xc0000a0e00)              
/go/src/oidc-authservice/handlers.go:225 +0xf2        
net/http.HandlerFunc.ServeHTTP(0xc00013c040, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0e00)                              
/usr/local/go/src/net/http/server.go:2007 +0x44      
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc000140000, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0e00)        
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037      
net/http.serverHandler.ServeHTTP(0xc0000fe0e0, 0x9b6ce0, 0xc0000fe1c0, 0xc0000a0e00)    
/usr/local/go/src/net/http/server.go:2802 +0xa4                                                      
net/http.(*conn).serve(0xc0002f4e60, 0x9b7ea0, 0xc000282500)           
/usr/local/go/src/net/http/server.go:1890 +0x875                      
created by net/http.(*Server).Serve                           
/usr/local/go/src/net/http/server.go:2927 +0x38e 

Environment:

• Platform: (Azure AKS)
• Kubernetes version: 1.24.9
• Kubeflow v1.6.1

Is this a bug report or feature request?

• Bug Report
  when I install the Multi-user, auth-enabled Kubeflow with kfctl_istio_dex_v1.2,I get this error.
  Describe the bug
  A clear and concise description of what the bug is.
  
  

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService ...
2. Perform this action ...
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Config Files
Please provide all the relevant configuration that you can publicly share. This
includes:

• AuthService configuration.
• OIDC Provider configuration.

If relevant, upload your configuration files here using GitHub, there is no need
to upload them to any 3rd party services

Logs
Please provide all relevant logs (e.g., AuthService logs , OIDC Provider logs,
etc.)

Environment:

• AuthService version: (found in image tag) gcr.io/arrikto/kubeflow/oidc-authservice: 28c59ef
• Platform: (GKE, Azure, minikube, custom...)google cloud three VMs
• Kubernetes version:V1.16.3

Additional context
Add any other context about the problem here.

I've been trying to get kubeflow working with Azure AD as an idenity provider for a few weeks now with no success. Through some digging i've stumbled on this error that is logged by the service when the code response comes back from AAD prior to the token phase.
I've tried running this image 28c59ef and 5522e4d
Here is the error.

'2020/04/23 21:02:51 http: panic serving 10.215.17.77:39910: interface conversion: interface {} is nil, not string
goroutine 46 [running]:
net/http.(*conn).serve.func1(0xc0002f1540)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x7b27c0, 0xc000134e10)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc000496000, 0x8b5c20, 0xc00047dc00, 0xc000168f00)
/go/src/oidc-authservice/handlers.go:141 +0x1059
net/http.HandlerFunc.ServeHTTP(0xc000238070, 0x8b5c20, 0xc00047dc00, 0xc000168f00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc000212000, 0x8b5c20, 0xc00047dc00, 0xc0000ef000)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001e8120, 0x8b5c20, 0xc00047dc00, 0xc0000ef000)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc000284b60, 0x8b5c20, 0xc00047dc00, 0xc0000ef000)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc0002f1540, 0x8b69e0, 0xc0004cdd80)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
'

The current implementation supports only authorization code flow which is more suitable for interactive login through the browser. #44 introduced support to ID Tokens authentication which will enable non-interactive login but only for users accounts.
Both the session manager and id token authenticator relies on the email claim.
Access tokens generated from outside of OIDC-authservice through client credential flow will not have email claim and validating access token will involve verifying claims in aud , iss, and any other custom scopes.
Enabling support for access token will enable programmatic access for access tokens generated through client credential flow.

Is this a bug report or feature request?

• Feature Request

What should the feature do:
Upgrade oidc-authservice to gcr.io/arrikto/kubeflow/oidc-authservice:e236439

What is use case behind this feature:

• Support IDToken authentication
• Support ServiceAccount token authentication

Additional Information:
oidc-authservice change logs: https://github.com/arrikto/oidc-authservice/commits/master

Currently, session values are stored as plaintext.
They don't contain any user information, but makes for a bigger attack surface in the event the database is compromised.
A better approach would be to store hashed session values.

Is this a bug report or feature request?

• Feature Request
  Enable the OIDC-authservice repository CI for power(ppc64le) architecture. Any inputs on how we can enable CI for power(ppc64le)? As the current Yaml file in the repository does not explain much about architecture-specific configuration, hence not getting a clear idea. Can you help me with the oidc-authservice CI enabling for power(ppc64le) architecture?

What should the feature do:
This will enable CI of OIDC-authservice for power(ppc64le) which builds and push images for both amd64 and ppc64lee.

Additional Information:

I have created one workflow which will just build and push the images for amd64 and ppc64le. Below is the link to the workflow and pushed images.
Link to the workflow:- https://github.com/amitmukati-2604/oidc-authservice/actions/runs/3674045572/jobs/6211797806
Link to pushed images:- https://hub.docker.com/r/amitmukati2604/oidc-authservice/tags

Is this a bug report or feature request?

• Bug Report

Describe the bug
Following the instruction in the readme (and also piecing together examples for a few different repos) I am unable to get the OIDC authservice to work. (I am doing this with Kubeflow 1.3 and am using GitLab to test the functionality).

How to Reproduce
My understanding is that the following should work. However, I get an ext_authz_denied error in the Istio Ingressgateway logs.

1. I start from this base: https://github.com/kubeflow/manifests/tree/master/common/oidc-authservice/base
2. params.env I update as follows:

OIDC_PROVIDER=https://gitlab.my-domain.com
USERID_HEADER=kubeflow-userid
USERID_CLAIM=email
OIDC_SCOPES=read_user profile email #comma separated seems to be wrong
OIDC_AUTH_URL=
AUTHSERVICE_URL_PREFIX=https://kubeflow.my-other-domain.com/authservice/
REDIRECT_URL=https://kubeflow.my-other-domain.com/authservice/oidc/callback #leaving this blank appears to not work as expected
CLIENT_NAME=Kubeflow
TEMPLATE_PATH=web/templates/gitlab/auto_logout
STRICT_SESSION_VALIDATION=true
STORE_PATH=/var/lib/authservice/data.db

3. A virtualservice is created as follows:

kind: VirtualService
metadata:
  name: authservice-web
spec:
  gateways:
    - kubeflow/kubeflow-gateway
  hosts:
    - '*'
  http:
    - match:
        - uri:
            prefix: /authservice/
      rewrite:
        uri: /
      route:
        - destination:
            host: authservice.istio-system.svc.cluster.local
            port:
              number: 8082

4. The authservice svc is patched to add port 8082, as follows:

apiVersion: v1
kind: Service
metadata:
  name: authservice
spec:
  ports:
  - port: 8082
    name: http-web
    targetPort: http-web

Expected behavior
I would expect the above to result in a successful authentication

Logs

authservice:

time="2021-05-11T10:47:37Z" level=info msg="Starting readiness probe at 8081"
time="2021-05-11T10:47:37Z" level=info msg="No USERID_TOKEN_HEADER specified, using 'kubeflow-userid-token' as default."
time="2021-05-11T10:47:37Z" level=info msg="No USERID_PREFIX specified, using '' as default."
time="2021-05-11T10:47:37Z" level=info msg="No SERVER_HOSTNAME specified, using '' as default."
time="2021-05-11T10:47:37Z" level=info msg="No SERVER_PORT specified, using '8080' as default."
time="2021-05-11T10:47:37Z" level=info msg="No SESSION_MAX_AGE specified, using '86400' as default."
time="2021-05-11T10:47:37Z" level=info msg="Starting web server at :8080"

istio ingress gateway:

[2021-05-11T10:52:21.016Z] "GET / HTTP/2" 302 - ext_authz_denied - "-" 0 418 3 2 "95.114.180.246" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36" "2981ed16-3c5a-4cd6-94c3-5497a7582b80" "kubeflow.my-other-domain.com" "-" - - 10.10.0.215:443 95.114.180.246:55847 kubeflow.my-other-domain.com -
[2021-05-11T10:52:28.662Z] "GET /authservice/oidc/callback?code=5d830eaac4a01156871cf71e2f390cda1d2c86424d2eb6bbc9d3c054bc760c5e&state=MTYyMDczMDM0MXxFd3dBRUZkRU9FWXljVTVtU0VzMVlUZzBhbW89fKi3BLU4OfYGwR5zXD3xJyaDWjL83k-hhJvdVVo6T2EE HTTP/2" 302 - ext_authz_denied - "-" 0 418 3 3 "95.114.180.246" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36" "5de49224-8295-414d-b7a2-ca93cdd78dfe" "kubeflow.my-other-domain.com" "-" - - 10.10.0.215:443 95.114.180.246:55847 kubeflow.my-other-domain.com

Environment:

• AuthService version: (found in image tag)
• Platform: EKS
• Kubernetes version: 1.18

Additional context
Add any other context about the problem here.

We have integrated kubeflow with OIDC flow(Heracles+LDAP)We are unable to login to kubeflow UI. GUI throws below error.

Access to kubeflow.aiwb-enc-data-cpu1.uscentral-prd-az3.k8s.int was deniedYou don't have authorization to view this page.
HTTP ERROR 403

While checking the authservice pod logs, I see below error. It happens every couple of days.

2023/03/15 14:08:40 boltstore: remove expired sessions error: input/output error
time="2023-03-15T14:06:29Z" level=error msg="Failed to save state in store: error trying to save session: input/output error" ip= request=/

The issue resolves after restarting authservice pod but it re-appear after every 10-15 days. We have checked the underlying PVC status, it looks healthy.

Can someone look into it and suggest what could be the cause?

Ran into an issue while doing the SSO integration with the PingFed. Please look into the AuthService Logs below
time="2020-04-07T21:34:05Z" level=info msg="Starting readiness probe at 8081"
time="2020-04-07T21:34:05Z" level=info msg="No USERID_TOKEN_HEADER specified, using 'kubeflow-userid-token' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SERVER_HOSTNAME specified, using '' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SERVER_PORT specified, using '8080' as default."
time="2020-04-07T21:34:05Z" level=info msg="No SESSION_MAX_AGE specified, using '86400' as default."
time="2020-04-07T21:34:05Z" level=info msg="Starting web server at :8080"
2020/04/07 21:40:50 http: panic serving 10.233.66.18:43662: interface conversion: interface {} is nil, not string
goroutine 214 [running]:
net/http.(*conn).serve.func1(0xc000381e00)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00055af30)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001e20e0, 0xc000208100)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001e20e0, 0xc000208100)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001e20e0, 0xc000208700)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000381e00, 0x9b7ea0, 0xc00013bb80)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
time="2020-04-07T21:44:48Z" level=error msg="Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {"error_description":"Authorization code is invalid or expired.","error":"invalid_grant"}" ip=10.233.66.18 request="/login/oidc?code=PhJGP90OeqIoGhe56evdCulkeGmI2hT-v8gAAABl&state=MTU4NjI5NTU1NXxFd3dBRURoR01uRk9aa2hMTldFNE5HcHFTbXM9fI9GpI-9uyFgS3-5-Qr6-B3Wy2-EavOY5zlxVnJ37Azm"
2020/04/07 21:45:40 http: panic serving 10.233.66.18:46904: interface conversion: interface {} is nil, not string
goroutine 319 [running]:
net/http.(*conn).serve.func1(0xc000169a40)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc0001d2030)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc000428700, 0xc0001b4600)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc000428700, 0xc0001b4600)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc000428700, 0xc0001b4400)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000169a40, 0x9b7ea0, 0xc00013b9c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
time="2020-04-07T21:46:39Z" level=error msg="Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {"error_description":"Authorization code is invalid or expired.","error":"invalid_grant"}" ip=10.233.66.18 request="/login/oidc?code=_FHY6Gfl-8jVZy3u3-xzT2TKx_BvX95us8sAAAB0&state=MTU4NjI5NTkzN3xFd3dBRUZkVFVESk9ZMGhqYVZkMmNWcFVZVEk9fCksLhTvEX1rLWiEGQn3yO4yo7sIhCSFvhlg2CVXmS6k"
2020/04/07 21:47:09 http: panic serving 10.233.66.18:47968: interface conversion: interface {} is nil, not string
goroutine 411 [running]:
net/http.(*conn).serve.func1(0xc00041f720)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00023cae0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0004280e0, 0xc000164100)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0004280e0, 0xc000164100)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0004280e0, 0xc000668500)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc00041f720, 0x9b7ea0, 0xc000322a40)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 21:47:28 http: panic serving 10.233.66.18:48424: interface conversion: interface {} is nil, not string
goroutine 400 [running]:
net/http.(*conn).serve.func1(0xc000169a40)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc0001d8cf0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001661c0, 0xc0004e4700)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001661c0, 0xc0004e4700)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001661c0, 0xc000668a00)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000169a40, 0x9b7ea0, 0xc00013bf80)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 21:47:43 http: panic serving 10.233.66.18:48570: interface conversion: interface {} is nil, not string
goroutine 437 [running]:
net/http.(*conn).serve.func1(0xc000381e00)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00023de90)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc000362a80, 0xc000668c00)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc000362a80, 0xc000668c00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc000362a80, 0xc000164b00)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc000381e00, 0x9b7ea0, 0xc0003227c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
2020/04/07 22:43:16 http: panic serving 10.233.66.18:43668: interface conversion: interface {} is nil, not string
goroutine 273 [running]:
net/http.(*conn).serve.func1(0xc0003d3680)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc00055acc0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0001c8100, 0x9b6ce0, 0xc0001e2380, 0xc000164300)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0001ae340, 0x9b6ce0, 0xc0001e2380, 0xc000164300)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001b00c0, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc0001da000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc0001dc000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0001e2000, 0x9b6ce0, 0xc0001e2380, 0xc00015e400)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc0003d3680, 0x9b7ea0, 0xc0002aa2c0)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
(base)

Following is the Kustomize Config am using

• kustomizeConfig:
  overlays:
  • application
    parameters:
  • name: namespace
    value: istio-system
  • name: userid-header
    value: kubeflow-userid
  • name: oidc_provider
    value: https://fam-dev.kp.org
  • name: oidc_redirect_uri
    value: http://http://172.16.190.65/login/oidc
  • name: oidc_auth_url
    value: https://fam-uat.kp.org/as/authorization.oauth2
  • name: skip_auth_uri
    value: /dex
  • name: client_id
    value: kubeflow-oidc-authservice
    repoRef:
    name: manifests
    path: istio/oidc-authservice
    name: oidc-authservice

Please let me know if you need additional configuration details ?

Currently, the oidc-authservice only enables session-based authentication used mainly for web apps. It would be great to also have openID token-based auth enabled for services behind the gateway. This would allow other many CLI applications to login to the same IDP and get a token to make requests to the cluster (basically like how kubctl works). Such token-based access would be very similar to authentication with IAP. As I see, there could be two approaches to this.

• Allow and verify ID tokens from multiple clients as per configuration. In this case, maybe the token issuer remains the same, but there could be a list of valid audiences to verify and allow requests.
• Use dex's cross-client-trust-and-authorized-party to let other clients generate tokens on behalf of oidc-authservice app and authservice should verify these tokens accordingly.

It would be great to hear more about this.

Is this a bug report or feature request?

• Bug Report

Describe the bug

I debug this issue a lot of days, but I still cannot fix it. Please help to check that, much appreciated!

The log from the pod oidc-authservice:

time="2023-04-27T07:28:32Z" level=error msg="Failed to verify state parameter: Missing cookie: 'oidc_state_csrf'" context=server ip=192.168.2.5 request="/authservice/oidc/callback?code=vwrb2ivcui775zlkyxx7rt773&state=MTY4MjU4MDQ5M3xOd3dBTkZaUFRVcFpTa0UyVDBzelEwVk5TMWhEVFVSU1NWVmFSMHRaVTBaTFVrTkpTelpZTkRaWU5qWklSRk5ZTWpkTFVGRkpVRUU9fDLENxGlWVyIw3-D963fhK05ekOT8OYqdNJZl43BdD5-"
time="2023-04-27T07:28:50Z" level=warning msg="Missing url parameter: code. Redirecting to homepage `https://authservice.xxx-dev.us.xxx.com/authservice/site/homepage'." context=server ip=192.168.2.5 request=/authservice/oidc/callback
time="2023-04-27T07:45:39Z" level=info msg="Authenticating request..." context=server ip=192.168.2.5 request=/
time="2023-04-27T07:45:39Z" level=info msg="Failed to retrieve a valid session" context="session authenticator" ip=192.168.2.5 request=/
time="2023-04-27T07:45:39Z" level=info msg="Failed to authenticate using authenticators. Initiating OIDC Authorization Code flow..." context=server ip=192.168.2.5 request=/

The log from the pod dex:

time="2023-04-27T07:28:26Z" level=info msg="performing ldap search ou=People,dc=example,dc=org sub (&(|(objectClass=person)(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))([email protected]))"
time="2023-04-27T07:28:26Z" level=info msg="username \"[email protected]\" mapped to entry cn=kevin zhang,ou=People,dc=example,dc=org"
time="2023-04-27T07:28:26Z" level=info msg="performing ldap search ou=Groups,dc=example,dc=org sub (&(objectClass=groupOfNames)(member=cn=kevin zhang,ou=People,dc=example,dc=org))"
time="2023-04-27T07:28:26Z" level=error msg="ldap: groups search with filter \"(&(objectClass=groupOfNames)(member=cn=kevin zhang,ou=People,dc=example,dc=org))\" returned no groups"
time="2023-04-27T07:28:26Z" level=info msg="login successful: connector \"ldap\", username=\"kevin zhang\", preferred_username=\"\", email=\"[email protected]\", groups=[]"
time="2023-04-27T07:49:49Z" level=info msg="performing ldap search ou=People,dc=example,dc=org sub (&(|(objectClass=person)(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))([email protected]))"
time="2023-04-27T07:49:49Z" level=info msg="username \"[email protected]\" mapped to entry cn=kevin zhang,ou=People,dc=example,dc=org"
time="2023-04-27T07:49:49Z" level=info msg="performing ldap search ou=Groups,dc=example,dc=org sub (&(objectClass=groupOfNames)(member=cn=kevin zhang,ou=People,dc=example,dc=org))"
time="2023-04-27T07:49:49Z" level=error msg="ldap: groups search with filter \"(&(objectClass=groupOfNames)(member=cn=kevin zhang,ou=People,dc=example,dc=org))\" returned no groups"
time="2023-04-27T07:49:50Z" level=info msg="login successful: connector \"ldap\", username=\"kevin zhang\", preferred_username=\"\", email=\"[email protected]\", groups=[]"

Configuration:

• Dex: (image: gcr.io/arrikto/dex:v2.30.3-2.0-rc2-13-g3352239f8)

issuer: https://dex.xxx-dev.us.xxx.com/dex
    storage:
      type: kubernetes
      config:
        inCluster: true
    web:
      http: 0.0.0.0:5556

    connectors:
    - type: ldap
      name: OpenLDAP
      id: ldap
      config:
        # The following configurations seem to work with OpenLDAP:
        #
        # 1) Plain LDAP, without TLS:
        host: ldap.auth.svc.cluster.local:389
        insecureNoSSL: true
        #
        # 2) LDAPS without certificate validation:
        #host: localhost:636
        #insecureNoSSL: false
        #insecureSkipVerify: true
        #
        # 3) LDAPS with certificate validation:
        #host: YOUR-HOSTNAME:636
        #insecureNoSSL: false
        #insecureSkipVerify: false
        #rootCAData: 'CERT'
        # ...where CERT="$( base64 -w 0 your-cert.crt )"

        # This would normally be a read-only user.
        bindDN: cn=admin,dc=example,dc=org
        bindPW: Not@SecurePassw0rd

        usernamePrompt: Email Address

        userSearch:
          baseDN: ou=People,dc=example,dc=org
          filter: "(|(objectClass=person)(objectClass=posixAccount)(objectClass=inetOrgPerson)(objectClass=shadowAccount))"
          username: mail
          # "DN" (case sensitive) is a special attribute name. It indicates that
          # this value should be taken from the entity's DN not an attribute on
          # the entity.
          idAttr: DN
          emailAttr: mail
          nameAttr: cn

        groupSearch:
          baseDN: ou=Groups,dc=example,dc=org
          filter: "(objectClass=groupOfNames)"

          userMatchers:
            # A user is a member of a group when their DN matches
            # the value of a "member" attribute on the group entity.
          - userAttr: DN
            groupAttr: member

          # The group name should be the "cn" value.
          nameAttr: cn

    staticClients:
    - id: ldapdexapp
      redirectURIs:
      - 'https://authservice.xxx-dev.us.xxx.com/authservice/oidc/callback'
      name: 'Dex Login Application'
      secret: pUBnBOY80SnXgjibTYM9ZWNzY2xreNGQok

• Oidc-authservice: (image: gcr.io/arrikto/oidc-authservice:0c4ea9a)

  AUTHSERVICE_URL_PREFIX: https://authservice.xxx-dev.us.xxx.com/authservice/
  CA_BUNDLE: /home/authservice/cert/ca.pem
  GROUPS_ALLOWLIST: a,d,e,system:serviceaccounts
  OIDC_AUTH_URL: https://dex.xxx-dev.us.xxx.com/dex/auth
  OIDC_PROVIDER: https://dex.xxx-dev.us.xxx.com/dex
  OIDC_SCOPES: profile,email,groups
  SKIP_AUTH_URLS: /dex/
  STRICT_SESSION_VALIDATION: "true"

How to Reproduce

1. I deployed istio envoyfilter and dex and oidc-authservice, they are running properly.
2. I can get the below window to login in with my ldap credential when I try to access my domain.
   
3. I can get the below window after I input my username and password.
   
4. I got the issue shown below if I click the button "Grant Access" from the above window.
   

Expected behavior
A clear and concise description of what you expected to happen.

Config Files
Please provide all the relevant configuration that you can publicly share. This
includes:

• AuthService configuration.
• OIDC Provider configuration.

If relevant, upload your configuration files here using GitHub, there is no need
to upload them to any 3rd party services

Logs
Please provide all relevant logs (e.g., AuthService logs , OIDC Provider logs,
etc.)

Environment:

• AuthService version: (found in image tag)
• Platform: (GKE, Azure, minikube, custom...)
• Kubernetes version:

Additional context
Add any other context about the problem here.

Use Case:

We have an external microservice that is deployed across namespaces in kubeflow, we want to restrict the access of this microservice to namespace level.

Question:

We observed the oidc-authservice has a external authorizer which has been added two months ago, we couldn't find the updated image where the external authorizer is added. It would be of great help if someone can point to the correct image or a blog that has the external auth tested.

Current setup

kubeflow 1.5
kubernetes 1.21

Old image we were using before external authorizer

New image we used to test the external auth this image gave us 403.

let me know if I missed anything.

The images version I am using gcr.io/arrikto/kubeflow/oidc-authservice:28c59ef
When I use Comma-separated list, I get the following error

ERR_TOO_MANY_REDIRECTS

The correct description is as follows

SKIP_AUTH_URI Space separated list of URIs like "/info /health" to bypass auth. Default empty

We’ve been using this in kubeflow and initially everything works fine. But after you’ve been running roughly more than a week then your session can seemingly be expired and you get 403s. This might kinda make sense but there’s then no way in kubeflow to start a new session. You can’t even logout as every page gets blocked.

When this happens the authservice pod doesn’t log anything for each 403. But it is the authservice rejecting requests as we can fix it by killing that Pod and letting it come back up again. When it comes back up we can login as normal.

Naturally this is quite hard to replicate as you have to run for a long time before you hit it. We didn’t encounter this previously with the old ambassador-oidc version.

Hi, I'm using oidc-authservice along with kubeflow, and encounterd too many redirections on authentication success.

kubeflow manifest version: 1.5
kubeflow version: 1.5
oidc-authservice image version: e236439

on image 28c59ef which was the default image from kubeflow-manifest repo, I have the following config and it works:

OIDC_PROVIDER=https://accounts.foobar.,com # which was my oidc provider
AUTHSERVICE_URL_PREFIX=/authservice/
OIDC_SCOPES=profile email groups # space separated
REDIRECT_URL=https://kubeflow.foobar.com/login/oidc
SKIP_AUTH_URI=/authserver /api /openapi # space separated
USERID_HEADER=kubeflow-userid
USERID_PREFIX=
USERID_CLAIM=email
PORT="8080"
STORE_PATH=/var/lib/authservice/data.db

But we are interested to switch to the newest image e236439 to try some new features like AUTH_HEADER and ID_TOKEN_HEADER

We adjusted the config according to README:

OIDC_PROVIDER=https://accounts.foobar.com
AUTHSERVICE_URL_PREFIX=/authservice/
OIDC_SCOPES=profilememail,groups # switched to comma-separared
REDIRECT_URL=https://kubeflow.foobar.com/login/oidc
SKIP_AUTH_URLS=/authserver,/api,/openapi # switched to comma-separared
USERID_HEADER=kubeflow-userid
USERID_PREFIX=
USERID_CLAIM=email
PORT="8080"
STORE_PATH=/var/lib/authservice/data.db

After applying the config and restart the service, we encounted too many redirections error and can never access kubeflow home page.

Is image e236439 collaborate with kubeflow now?

how to get user info by session token?

The authservice should expose an endpoint to enable users to get their active sessions.

Is this a bug report or feature request?

• Bug Report

Describe the bug
Couldn't change the log level via LOG_LEVEL env.

Seems the code in this line, missing envconfig:"LOG_LEVEL", so it couldn't get the config value.

How to Reproduce
Steps to reproduce the behavior:

1. Set LOG_LEVEL to ERROR or DEBUG via "kubectl -n istio-system edit cm oidc-authservice-parameters".

2. Confirm the env in the authservice-0 pod.
   ~ $ env |grep LOG LOG_LEVEL=ERROR

3. Still the info level log printed.

Expected behavior
The log level changed accordingly.

Environment:

• AuthService version: e236439
• Platform: rke
• Kubernetes version: v1.24.10

Is this a bug report or feature request?

• Bug Report

Describe the bug
A clear and concise description of what the bug is.

We deploy oidc-authservice for Kubeflow and Integrated with Azure AD

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService ...
2. Perform this action ...
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Login the Azure AD user successfully and able the access the kubeflow dashboard

Config Files
Please provide all the relevant configuration that you can publicly share. This
includes:

• AuthService configuration.
• OIDC Provider configuration.

We used below envs

OIDC_PROVIDER=https://login.microsoftonline.com/<tenant_id>/v2.0
OIDC_AUTH_URL=https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/authorize
OIDC_SCOPES=profile email
REDIRECT_URL=https://kubeflow-test.mydomain.com/login/oidc
SKIP_AUTH_URI=
USERID_HEADER=kubeflow-userid
USERID_PREFIX=
USERID_CLAIM=email
PORT="8080"
STORE_PATH=/var/lib/authservice/data.db

CLIENT_ID=
CLIENT_SECRET=

added the https://kubeflow-test.mydomain.com/login/oidc as redirection url in azure app registration

If relevant, upload your configuration files here using GitHub, there is no need
to upload them to any 3rd party services

Logs
Please provide all relevant logs (e.g., AuthService logs , OIDC Provider logs,
etc.)

time="2022-05-24T04:47:59Z" level=info msg="Starting readiness probe at 8081"
time="2022-05-24T04:47:59Z" level=info msg="No USERID_TOKEN_HEADER specified, using 'kubeflow-userid-token' as default."
time="2022-05-24T04:47:59Z" level=info msg="No SERVER_HOSTNAME specified, using '' as default."
time="2022-05-24T04:47:59Z" level=info msg="No SERVER_PORT specified, using '8080' as default."
time="2022-05-24T04:47:59Z" level=info msg="No SESSION_MAX_AGE specified, using '86400' as default."
time="2022-05-24T04:47:59Z" level=info msg="Starting web server at :8080"
2022/05/24 04:48:21 http: panic serving 10.244.0.249:57466: interface conversion: interface {} is nil, not string
goroutine 20 [running]:
net/http.(*conn).serve.func1(0xc0000968c0)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x88ee00, 0xc0001ca5d0)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
main.(*server).callback(0xc0000e4100, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc900)
/go/src/oidc-authservice/handlers.go:150 +0x1061
net/http.HandlerFunc.ServeHTTP(0xc0000d4330, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc900)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0000d60c0, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc700)
/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:212 +0xe2
main.whitelistMiddleware.func1.1(0x9b6ce0, 0xc00032f0a0, 0xc0001dc700)
/go/src/oidc-authservice/handlers.go:225 +0xf2
net/http.HandlerFunc.ServeHTTP(0xc000122040, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc700)
/usr/local/go/src/net/http/server.go:2007 +0x44
github.com/gorilla/handlers.(*cors).ServeHTTP(0xc000130000, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc700)
/go/pkg/mod/github.com/gorilla/[email protected]/cors.go:54 +0x1037
net/http.serverHandler.ServeHTTP(0xc0000e80e0, 0x9b6ce0, 0xc00032f0a0, 0xc0001dc700)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc0000968c0, 0x9b7ea0, 0xc000122280)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2927 +0x38e
time="2022-05-24T04:48:39Z" level=error msg="Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {"error":"invalid_grant","error_description":"AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.\r\nTrace ID: b5d24d9e-76fe-44ca-aced-cce900c16c00\r\nCorrelation ID: e0e1823d-1f9a-4f37-9dbe-85d53bd9ce25\r\nTimestamp: 2022-05-24

Environment:

• AuthService version: 28c59ef
• Platform: Azure
• Kubernetes version: 1.21.9

Additional context
Add any other context about the problem here.

Currently, only the RS256 signing algorithm is supported for IDToken verification.
This is a restriction of the go-oidc library: coreos/go-oidc#225
We should document this restriction in the README.

In order to setup OIDC with public providers (eg Google, LinkedIn, Github) we need to allow whitelisted URLs before the OIDC setup is complete.
This means that we should start the AuthService immediately without waiting for the OIDC setup, at least to allow for those requests.

Here is what happens:

1. OIDC AuthService starts and tries to setup by contacting the discovery endpoint of Dex, which is on a public IP (this is needed because Dex is a client for eg Google's oAuth service). This makes a request that exits and reenters the cluster.
2. When the request enters the cluster through the Istio Gateway, the ExtAuthz filter kicks in and tries to contact the AuthService to authorize the request. However, the AuthService server hasn't started yet, because it still tries to setup OIDC. The request times out and the authorization fails.

Kubeflow Issue: kubeflow/kubeflow#4517

Hi @yanniszark

I am using this service for multi-tenancy feature in Kubeflow.
As, oidc-authservice is used for authentication in Kubeflow dex+istio deployment.
I recently came up with one issue or bug, when using dex with ldap as an oidc connector.

Following are my dex logs, when user enters authentication info using oidc-authservice login page, which is configured using following example:
https://github.com/dexidp/dex/blob/master/Documentation/connectors/ldap.md#example-searching-a-active-directory-server-with-groups

time="2020-06-15T19:40:55Z" level=info msg="performing ldap search ou=users,dc=example,dc=com sub (&(objectClass=posixAccount)(uid=myldapuser))"
time="2020-06-15T19:40:55Z" level=info msg="username \"myldapuser\" mapped to entry uid=myldapuser,ou=users,dc=example,dc=com"
time="2020-06-15T19:40:55Z" level=info msg="performing ldap search 
cn=kubeflow,ou=groups,dc=example,dc=com sub (&(objectClass=posixGroup)(memberUid=myldapuser))"
time="2020-06-15T19:40:55Z" level=info msg="login successful: connector \"ldap\", username=\"LDAP_user\", preferred_username=\"\", email=\"[email protected]\", groups=[\"kubeflow\"]"

Here, the dex performs an user search in groupsearch filter, which allows user "myldapuser" to login if part of a ldap group "kubeflow" here.
But, even if user is not part of any group in ldapsearch filter like groups=[], it still allows user to login.
Ideally, which should not happen, if user is not part of a group.
Is there any way in oidc-authservice, where we can whitelist user groups, or reject the access request. as per the blog you posted.
https://journal.arrikto.com/kubeflow-authentication-with-istio-dex-5eafdfac4782

Will be looking forward to your reply.
Thanks.

Is this a bug report or feature request?

• Bug Report

Describe the bug
AuthService cannot connect to OIDC provider through a proxy if a CA_BUNDLE is set.
Error: connection timed out.
HTTPS_PROXY and HTTP_PROXY env vars are set.

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService with the env var CA_BUNDLE set to a custom CA certificates file.
2. Container is starting and an error is raised in the log:

OIDC provider setup failed, retrying in 10 seconds: Get \"https://<OIDC PROVIDER>/.well-known/openid-configuration\": dial tcp XXX.XXX.XXX.XXX:443: connect: connection timed out

Expected behavior
The connection should be established

Config Files
Here the manifest:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: authservice
spec:
  template:
    spec:
      containers:
      - name: authservice
        image: gcr.io/arrikto/kubeflow/oidc-authservice:e236439
        env:
        - name: http_proxy
          value: http://<PROXY>:3128
        - name: https_proxy
          value: http://<PROXY>:3128
        - name: no_proxy
          value: XXX
        - name: HTTP_PROXY
          value: http://<PROXY>:3128
        - name: HTTPS_PROXY
          value: http://<PROXY>:3128
        - name: NO_PROXY
          value: XXX
        - name: CA_BUNDLE
          value: <PATH>/certificates.crt
        resources:
          requests:
            memory: 64Mi
            cpu: 100m
        volumeMounts:
          - mountPath: <PATH>
            name: custo-ca
      volumes:
        - name: custo-ca
          configMap:
            name: custo-ca

Logs

time="2022-02-17T10:15:47Z" level=info msg="Config: &{ProviderURL:https://<OIDC PROVIDER>/dex ClientID:xxx ClientSecret:xxx OIDCAuthURL:/dex/auth RedirectURL:/login/oidc OIDCScopes:[openid profile email groups[] StrictSessionValidation:false OIDCStateStorePath:/var/lib/authservice/data.db AuthserviceURLPrefix:/dex/ SkipAuthURLs:[/dex/] AuthHeader:Authorization Audiences:[istio-ingressgateway.istio-system.svc.cluster.local[] HomepageURL:/dex/site/homepage AfterLoginURL: AfterLogoutURL:/dex/site/after_logout UserIDHeader:kubeflow-userid GroupsHeader:kubeflow-groups UserIDPrefix: UserIDTransformer:{rules:[]} UserIDClaim:email UserIDTokenHeader: GroupsClaim:groups IDTokenHeader:Authorization Hostname: Port:8080 WebServerPort:8082 ReadinessProbePort:8081 CABundlePath:<PATH>/certificates.crt SessionStorePath:/var/lib/authservice/data.db SessionMaxAge:86400 SessionSameSite:Lax ClientName:AuthService ThemesURL:themes Theme:kubeflow TemplatePath:[web/templates/default] UserTemplateContext:map[] GroupsAllowlist:[*]}"
time="2022-02-17T10:15:47Z" level=info msg="Starting readiness probe at 8081"
time="2022-02-17T10:15:47Z" level=info msg="Starting server at :8080"
time="2022-02-17T10:15:47Z" level=info msg="Starting web server at :8082"
time="2022-02-17T10:17:54Z" level=error msg="OIDC provider setup failed, retrying in 10 seconds: Get \"https://<OIDC PROVIDER>/.well-known/openid-configuration\": dial tcp <OIDC PROVIDER IP>:443: connect: connection timed out"
time="2022-02-17T10:20:11Z" level=error msg="OIDC provider setup failed, retrying in 10 seconds: Get \"https://<OIDC PROVIDER>/.well-known/openid-configuration\": dial tcp <OIDC PROVIDER IP>:443: connect: connection timed out"

Environment:

• AuthService version: e236439
• Platform: custom
• Kubernetes version: 1.19

Additional context
I built a custom image from gcr.io/arrikto/kubeflow/oidc-authservice where I put the custom CA certificates into /usr/local/share/ca-certificates/
When I deploy it, i don't set the CA_BUNDLE.
In this case AuthService works well, the connection with OIDC provider is done through proxy as expected.
So it seems when the CA_BUNDLE is set, the HTTP client does not use the PROXY env vars.

On the AuthService container, in the netstat result, we see the connection is done directly without proxy.

~ $ netstat -apn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address              State       PID/Program name
tcp        0      1 192.168.128.47:57590    <OIDC PROVIDER IP>:443       SYN_SENT    1/oidc-authservice
tcp        0      0 :::8080                 :::*                         LISTEN      1/oidc-authservice
tcp        0      0 :::8081                 :::*                         LISTEN      1/oidc-authservice
tcp        0      0 :::8082                 :::*                         LISTEN      1/oidc-authservice
...
~ $

Hi,

I am working on integrated Kubeflow for Azure AD, and I came across their implementation which uses your auth service.

I have largely followed the implementation except I had to update the container image they were pulling from your repo so that I could use the custom CA_BUNDLE for the dex service.

It feels like everything is almost there, I get through Azure AD, but the callback appears to be the function that's not working, because on the reply URL from Azure AD, I basically get back to the first authentication again.

I believe I am falling over on the 'AUTHSERVICE_URL_PREFIX' option which wasn't something that existed in the image they use in the Kubeflow examples. Could you advise what this should be?

We've got Go cobra code that makes it easy to add paths to the whitelisting env var. I wrote this because I want to whitelist paths programmatically from a shell script and I couldn't find any bash way to do it. Would like to be able to contribute it somewhere. Would it fit in kfctl? Or would it be worth having a ctl specifically for the auth service? Or perhaps mine is just a fringe use-case?

There are some cases where the OIDC provider is not aware of usernames, only emails (for example using Google as OIDC provider).
So there is a need to transform the identity that the provider returns to an internal username.

In a recent PR, go-oidc added support for multiple asymmetric signing algorithms (coreos/go-oidc#227).
We should update to a version that includes that commit, once it's available in a release.

Hello,

I am trying to connect kubeflow to keycloak now using the authservice. However, i get 404 whenever i get redirected to keycloak.

Here is my kustomizeconfig for the authservice

    - kustomizeConfig:
        overlays:
        - application
        parameters:
        - name: namespace
          value: istio-system
        - name: userid-header
          value: kubeflow-userid
        - name: oidc_provider
          value: http://keycloak-http.keycloak.svc:80/auth/realms/kubeflow
        - name: oidc_redirect_uri
          value: /login/oidc
        - name: client_id
          value: kubeflow
        repoRef:
          name: manifests
          path: istio/oidc-authservice
      name: oidc-authservice

Is this a bug report or feature request?

• Bug Report

Describe the bug

Currently, we rely on cookies to verify that the state parameter has originated from the user's browser, and has not been maliciously planted in the URL. This way, we protect the user from logging in accidentally with another user's account.

The problem with this approach is that if a user opens the page that is protected by the authservice in two or more tabs, the state cookie will be overridden, and the user won't be able to login from the first page.

A side-effect of this issue is that the page that the user intended to visit, which authservice would redirect them to after login, will be lost.

How to Reproduce
Steps to reproduce the behavior:

1. Deploy AuthService.
2. Open a page in the browser that is guarded by the AuthService.
3. Open a second one.
4. Try to login from the first page.
5. You will see the following error: CSRF check failed.This may happen if you opened the login form in more than 1 tabs. Please try to login again.

Expected behavior

The user should be able to login from either page. If the user is already logged in one page and they attempt to log in from another one, they should be redirected to the page they intended to visit.

Is this a bug report or feature request?

• Feature Request

What should the feature do:
Change kubeflow context path from "/" to "/kubeflow" or anything else

What is use case behind this feature:
There will be many services deployed in a kubernetes cluster which are accessed from "/" path. When kubeflow is deployed it takes "/" path and forwards all the requests to dex authentication.

It would better to change kubeflow path accessible to from "/kubeflow" and leave other apps accessible from "/" path

Additional Information:
If this feature is already available please direct me to its docs.

Thank you

Hi there,

We have encountered a problem deploying oidc-authservice, and this issue is more a question than a bug I think.

We have an istio gateway listening on wildcard hostnames, under which we want to authenticate only one hostname.

We want to authenticate all requests to kubeflow.foo.com, but allow all others.

According to this section in the README I think we can achieve that by setting SERVER_HOSTNAME to kubeflow.foo.com, but we encountered an error:

Is there something that I miss how to config the SERVER_HOSTNAME?

ServiceAccounts are accounts for machines (not humans).
Kubernetes has native support for ServiceAccounts for its workloads.
In addition, it can function as a ServiceAccount database and issue tokens with a custom audience, to accomodate authenticating to entities other than the K8s API Server.

The AuthService can leverage that to enable machine authentication.
The AuthService assumes a custom audience, e.g., istio-ingressgateway.istio-system.svc.cluster.local.
The user creates ServiceAccountTokens with that audience and presents them to the AuthService as bearer tokens.
The AuthService makes a TokenReview call to authenticate them and passes the auth result in headers, same as OIDC authentication.

While performing some tests on a long living session with strict session validation enabled, we noticed that requests started to fail after some point. We believe the reason was the following:

1. The client probably closed the TCP connection after sending a request. This can happen if a browser sends a request and gets immediately interrupted, e.g., due to a refresh.
2. The server detected the closed connection and send a cancellation signal to the context.
3. The goroutine that was querying the user info got cancelled midway.
4. We interpreted the failure to get the user info as an expired token, and we deleted the session. Unfortunately, we can't have an accurate description of the error, because the go-oidc library does not permit this (see: coreos/go-oidc#248).

We should properly detect the reason why the user info call fails, and delete the session only when we are positive that the token has expired.