Giter Club home page Giter Club logo

oidc-authservice's Introduction

OIDC AuthService

This is a rewrite of the ajmyyra/ambassador-auth-oidc project.

An AuthService is an HTTP Server that an API Gateway (eg Ambassador, Envoy) asks if an incoming request is authorized.

For more information, see this article.

OpenID Connect

OpenID Connect (OIDC) is an authentication layer on top of the OAuth 2.0 protocol. As OAuth 2.0 is fully supported by OpenID Connect, existing OAuth 2.0 implementations work with it out of the box.

Currently it only supports OIDC's Authorization Code Flow, similar to OAuth 2.0 Authorization Code Grant.

Sequence Diagram for an Authentication Flow

OIDC AuthService Sequence Diagram

Design Docs

For more details on how various aspects of the AuthService are designed, see the design doc for the relevant section:

Architecture

The AuthService contains two server processes.

  • The Judge Server, which is used for communication with the proxy asking if a request is allowed. The proxy (Envoy, Ambassador, ...) will make a request, with the same method and headers as the request it wants to ask about, at the Judge Server. If the request is authenticated, the Judge Server replies with 200 and the original request is forwarded upstream. If the request is forbidden, the authservice will reply with a redirect to initiate the OIDC login.
  • A web server, to host necessary endpoints that need to be accessible to the user. These endpoints include the OIDC client redirect URL, the logout endpoint and helper HTML pages.

Options

Following environment variables are used by the software.

Compulsory

Setting Description
OIDC_PROVIDER URL to your OIDC provider. AuthService expects to find information about your OIDC provider at OIDC_PROVIDER/.well-known/openid-configuration, and will use this information to contact your OIDC provider and initiate an OIDC flow later on.
AUTHSERVICE_URL_PREFIX AuthService expects end users will be able to access its Web-based UI from the outside world at AUTHSERVICE_URL_PREFIX. Usually, it's in the form of <APP_URL>/authservice/ It expects that your API Gateway will route any URL that starts with AUTHSERVICE_URL_PREFIX to it, so it can expose its default Web-based UI and API endpoints. AuthService will use this value to auto-generate sane defaults for a number of settings, including HOMEPAGE_URL, LOGOUT_URL, and AFTER_LOGOUT_URL. The default value, /authservice/ will work out of the box with an Istio VirtualService specifying /authservice/ as its prefix.
CLIENT_ID AuthService will use this Client ID when it needs to contact your OIDC provider and initiate an OIDC flow.
CLIENT_SECRET AuthService will use this Client Secret to authenticate itself against your OIDC provider in combination with CLIENT_ID when attempting to access your OIDC Provider's protected endpoints

Optional

Setting Default Description
REDIRECT_URL AUTHSERVICE_URL_PREFIX/oidc/callback AuthService will pass this URL to the OIDC provider when initiating an OIDC flow, so the OIDC provider knows where it needs to send the OIDC authorization code to. It defaults to AUTHSERVICE_URL_PREFIX/oidc/callback. This assumes that you have configured your API Gateway to pass all requests under a hostname to Authservice for authentication.
OIDC_AUTH_URL <empty> AuthService will initiate an Authorization Code OIDC flow by hitting this URL. Normally discovered automatically through the OIDC Provider's well-known endpoint.
CLIENT_NAME AuthService A user-visible description for AuthService as an OIDC Client. It is recommended that you set it to a user-visible name for the application/domain that AuthService protects, e.g., MyApp. AuthService will not use this as part of contacting your OIDC Provider, but it will use it to auto-generate user-visible message in the frontend. , e.g., "You are now logged out of MyApp. Click here to log in again."
OIDC_SCOPES openid,email Comma-separated list of scopes to request access to. The openid scope is always added.
AUDIENCES istio-ingressgateway.istio-system.svc.cluster.local Audiences that the authservice identifies as. Used for authenticators that support audience-scoped tokens. Currently, that is only the Kubernetes authenticator. The default value assumes that the authservice is used at the Istio Gateway in namespace istio-system.
SERVER_HOSTNAME <empty> Hostname to listen for judge requests. This is the server that proxies contacts to ask if a request is allowed. The default empty value means all IPv4/6 interfaces (0.0.0.0, ::).
SERVER_PORT 8080 Port to listen to for judge requests. This is the server that proxies contacts to ask if a request is allowed.
SKIP_AUTH_URLS <empty> Comma-separated list of URL path-prefixes for which to bypass authentication. For example, if SKIP_AUTH_URL contains /my_app/ then requests to <url>/my_app/* are allowed without checking any credentials. Contains nothing by default.
CA_BUNDLE <empty> Path to file containing custom CA certificates to trust when connecting to an OIDC provider that uses self-signed certificates.
AFTER_LOGIN_URL <originally visited url> URL to redirect the user to after they login. Defaults to the URL that the user originally visited before they were redirected for login. For example, if a user visited <app_url>/example and were redirected for login, they will be redirected to /example after login is complete.
HOMEPAGE_URL AUTHSERVICE_URL_PREFIX/site/homepage Homepage of the application that can be accessed by anonymous users.
AFTER_LOGOUT_URL AUTHSERVICE_URL_PREFIX/site/homepage URL to redirect the user to after they logout. This option used to be called STATIC_DESTINATION_URL. For backwards compatibility, the old environment variable is also checked.
VERIFY_AUTH_URL AUTHSERVICE_URL_PREFIX/verify Path to the /verify endpoint. This endpoint examines a subrequest and returns 204 if the user is authenticated and authorized to perform such a request, otherwise it will return 401 if the user cannot be authenticated or 403 if the user is authenticated but they are not authorized to perform this request.
AUTH_HEADER Authorization When the AuthService logs in a user, it creates a session for them and saves it in its database. The session secret value is saved in a cookie in the user's browser. However, for programmatic access to endpoints, it is better to use headers to authenticate. The AuthService also accepts credentials in a header configured by the AUTH_HEADER setting.
ID_TOKEN_HEADER Authorization When id token is carried in this header, OIDC Authservice verifies the id token and uses the USERID_CLAIM inside the id token. If the USERID_CLAIM doesn't exist, the authentication would fail.
LOG_LEVEL "INFO" Set the log level to one of "FATAL", "ERROR", "WARN", "INFO", or "DEBUG" to specify the verbosity of the OIDC-Authservice logs.

The AuthService provides a web server with some defaults pages for a homepage and an after_logout page. The following values are about these pages. To learn more about how these pages work, see the templating guide.

By default, this web server listens at port 8082 and its endpoints are:

Endpoint Description
/site/homepage Landing page
/site/after_logout After Logout page
/site/themes Themes

To expose the web server in an environment like Kubernetes with Istio, you need to:

  • Create a Service pointing to the AuthService's web server port (8082).
  • Create an Istio VirtualService to match traffic with the $AUTHSERVICE_URL_PREFIX path-prefix and direct it to the Service you created. Usually, the AUTHSERVICE_URL_PREFIX is in the form of <url>/<path> (e.g,. <url>/authservice). Make sure your VirtualService captures requests with the <path>.
Setting Default Description
TEMPLATE_PATH web/templates/default A comma-separated list of dirs to look under for templates. Templates with the same name override previously registered ones. For more information, see the templating guide. It always contains the default templates.
CLIENT_NAME AuthService A human-readable name for the client. Used in the web server's pages.
THEMES_URL themes URL where the themes are served. Theme assets are found under THEMES_URL/THEME. To learn how you can create your own theme, see the templating guide.
THEME kubeflow Path under THEMES_URL where the theme assets are served.
TEMPLATE_CONTEXT_<key> empty Variables that will end up in the user-defined map in the template context. For example, if you define TEMPLATE_CONTEXT_KEY=VALUE, then a KEY: VALUE entry will be added to the user-defined map in the template context. Used to pass values to site templates and allow for further customization.

OIDC-AuthService stores sessions and other state in a local file. The users can select between using BoltDB which is the default option or redis for the session store. Session store-related settings:

Setting Default Description
SESSION_STORE_PATH "/var/lib/authservice/data.db" Path to local session store. Backed by BoltDB.
OIDC_STATE_STORE_PATH "/var/lib/authservice/oidc_state.db" Path to the session store used to save the sessions for the OIDC state parameter.
SESSION_MAX_AGE "86400" Time in seconds after which sessions expire. Defaults to a day (24h).
SESSION_SAME_SITE "Lax" SameSite attribute of the session cookie. Check details of SameSite attribute here. Its value can be "None", "Lax" or "Strict".
SESSION_STORE_TYPE "boltdb" Set SESSION_STORE_TYPE to either "boltdb" to use BoltDB as the session store, or "redis" to use redis as the session store. Note that only one of the two can be used, also if you select redis then depending on your redis configurations then you might need to set the password and the number of the database that OIDC-AuthService will use as a redis-client.
SESSION_STORE_REDIS_ADDR "127.0.0.1:6379" Set the host:port address for the redis session store.
SESSION_STORE_REDIS_PWD "" Set the password to connect with the redis session store.
SESSION_STORE_REDIS_DB 0 Set the number of the database that AuthService should use. If not configured and if the redis session store is selected, then AuthService will use the default redis database.

By default, the AuthService keeps sessions to check if a user is authenticated. However, there may be times where we want to check a user's logged in status at the Provider, effectively making the Provider the one keeping the user's logged in status to enable access revocation scenarios and centralized management.

Setting Default Description
STRICT_SESSION_VALIDATION false Be strict about session validity by quering the OIDC provider for the validity of the token at each individual request, by hitting the userinfo endpoint. This ensures the authservice can detect an OIDC token has been revoked on the OIDC provider immediately, and destroy its own session. However, it may increase the load on the OIDC provider and introduces additional latency. Disabled by default, enable with "on" OR "true".

OIDC AuthService can add extra headers based on the userid that was detected. Applications can then use those headers to identify the user.

Setting Default Description
USERID_CLAIM "email" Claim whose value will be used as the userid (default email).
GROUPS_CLAIM "groups" Claim whose value will be used as the user's groups (default groups)
USERID_HEADER "kubeflow-userid" Name of the header containing the user-id that will be added to the upstream request.
USERID_PREFIX "" Prefix to add to the userid, which will be the value of the USERID_HEADER.
USERID_TRANSFORMERS "" List of transformations for the userid value (from USERID_CLAIM) in JSON format [{"matches": "regex", "replaces": "value"}, ...]. OIDC AuthService will evaluate the transformation rules in order and if the matches pattern matches the userid, the match is replaced by the replaces value. If multiple rules match, only the first one is applied and if no rule matches the userid, the original userid will be used. For the matches regular expression, use the standard golang syntax (more info). Note that a regular expression is a string and the \ must be escaped (using \\). For example using USERID_TRANSFORMERS = '[{"matches": "user@domain\\.com$", "replaces": "internal"}, {"matches": "@domain\\.com$", "replaces": ""}]', AuthService will do the following transformation: [email protected] -> internal and [email protected] -> another.
GROUPS_HEADER "kubeflow-groups" Name of the header containing the groups that will be added to the upstream request.
AUTH_METHOD_HEADER "Auth-Method" Name of the header that is included in the proxied requests to inform the upstream app about the authentication method used (cookie / header).

OIDC AuthService can authenticate clients based on the bearer token found in the Authorization header of their request. It caches the bearer token and the respective user information. If the incoming request has a cached bearer token then AuthService authenticates this client and proceeds with the basic authorization checks. The following settings are related to the caching mechanism:

Setting Default Description
CACHE_ENABLED false Set CACHE_ENABLED to true to enable caching.
CACHE_EXPIRATION_MINUTES 5 (minutes) Set the CACHE_EXPIRATION_MINUTES value to define how many minutes it takes for every cache entry to expire.

By default, OIDC AuthService attempts to authenticate client requests with each one of the available authentication methods that it supports. In certain use cases the admins may want to skip the checks performed by one or more of the authentication methods. OIDC AuthService can be configured to skip a particular authentication method via the following configurations:

Setting Default Description
IDTOKEN_AUTHN_ENABLED true Set IDTOKEN_AUTHN_ENABLED to false to disable the ID token authentication method.
KUBERNETES_AUTHN_ENABLED true Set KUBERNETES_AUTHN_ENABLED to false to disable the Kubernetes authentication method.
ACCESS_TOKEN_AUTHN_ENABLED true Set ACCESS_TOKEN_AUTHN_ENABLED to false to disable both the access token authentication methods.
ACCESS_TOKEN_AUTHN "jwt" Set ACCESS_TOKEN_AUTHN to either "jwt" to enable the JWT access token authentication method, or "opaque" to enable the opaque access token authentication method. Note that only one of the two access token authentication methods can be used.

OIDC AuthService can also perform basic authorization checks. The following settings are related to authorization:

Setting Default Description
GROUPS_ALLOWLIST "*" List of groups that are allowed to pass authorization. By default, all groups are allowed. If you change this option, you may want to include the system:serviceaccounts group explicitly, if you need the AuthService to accept ServiceAccountTokens.
EXTERNAL_AUTHZ_URL "" Use an external authorization service. This option is disabled by default, to enable set the value to the target external authorization service (e.g. EXTERNAL_AUTHZ_URL=http://authorizer/auth). If you have enabled this option then for a request to be authorized, both the group and the external authorization service will have to allow the request.

Usage

OIDC-Authservice is an OIDC Client, which authenticates users with an OIDC Provider and assigns them a session. Can be used with:

  • Ambassador with AuthService
  • Envoy with the ext_authz Filter
  • Istio with EnvoyFilter, specifying ext_authz

Build

  • Local: make build
  • Docker: make docker-build

E2E Tests

For E2E tests, we use K3d, a very lightweight way to run a K8s cluster locally using Docker. For E2E tests to work, you need the following external tools:

  • go (>=1.13)
  • kustomize
  • kubectl
  • k3d

You can use make bin/deps to install them locally under ./bin/deps. Then simply run make e2e.

oidc-authservice's People

Contributors

apyrgio avatar asetty avatar cmurphy avatar edwardzjl avatar grgalex avatar johnbuluba avatar klolos avatar phoevos avatar tsuna avatar yanniszark avatar yhwang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

oidc-authservice's Issues

Getting access denied 403 from OIDC login with Azure AD in Kubeflow

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

Cannot use oidc-authservice along with kubeflow

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?

Error opening bolt store: open /var/lib/authservice/data.db: permission denied

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.
    image
    image

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.

GitLab OIDC provider results in ext_authz_denied

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
  1. 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
  1. 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.

Support specifying a custom CA

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.

ERROR: CSRF check failed. This may happen if you opened the login form in more than 1 tabs. Please try to login again.

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.
    image
  3. I can get the below window after I input my username and password.
    image
  4. I got the issue shown below if I click the button "Grant Access" from the above window.
    image

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.

Reject user as 403 if not part of a oidc connector group

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.

Using with Ambassador AuthService proxying to several hosts

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

http: panic serving 10.233.66.18:43668: interface conversion: interface {} is nil, not string goroutine 273

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

Please let me know if you need additional configuration details ?

Connecting authservice of kubeflow to keycloak as an oidc provider

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

Propagate initial URL when using AFTER_LOGIN_URL

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.

Authservice pod "Failed to save state in store: error trying to save session: input/output error"

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?

Set LOG_LEVEL not work

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

Start server immediately to allow whitelisted URLs

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

Occasional stale sessions that canโ€™t be refreshed

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.

Enable openID token based authentication

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.

all URIs are whitelisted and cannot be secured by OIDC provider

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

HTTP(S) proxy not used when CA_BUNDLE is set

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
...
~ $

Possibly memory leak

Is this a bug report or feature request?

  • Bug Report

Describe the bug
After a while, the authservice pod consume a lot of memory
Screen Shot 2022-03-23 at 11 39 05

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

AuthService assumes tokens are expired when the UserInfo call fails

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.

External Authentication with Updated OIDC authservice image

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.

Connecting authservice of kubeflow to keycloak as an oidc provider #REOPENED

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}

Opening a page protected by AuthService in multiple tabs while logged out will produce an error during login

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.

Enable oidc-authservice repository CI for power(ppc64le) architecture.

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

cli for whitelisting

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?

Pass the raw ID Token to downstream requests

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

w.Header().Set(s.userIDOpts.tokenHeader, session.Values["idtoken"].(string))

User info fails to unmarshal when email_verified is a string

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

if err := json.Unmarshal(body, &userInfo); err != nil {
.

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
 }

Support access token based authorization

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.

Failed to exchange authorization code with token: oauth2: cannot fetch token: 400 Bad Request Using Azure AD OIDC

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.

Update container image on gcr.io

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:

Kubernetes ServiceAccountToken Authentication

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.

Access kubeflow from path "/kubeflow" instead of "/"

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

Code panics if userid claim is not found

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:

session.Values["userid"] = claims[s.userIDOpts.claim].(string)

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

Wildcard support for GROUPS_ALLOWLIST

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:

Arrikto with Istio and Dex for Kubeflow

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?

Error configuring SERVER_HOSTNAME

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:

image

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

Support ES256 signing algorithm

  • 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\""

sessions: Store hashed session values

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.

The SKIP_AUTH_URI parameter description is incorrect.

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

http: panic serving 10.233.66.18:43668: interface conversion: interface {} is nil, not string goroutine 273

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

Please let me know if you need additional configuration details ?

oidc-authservice panics when using Azure as OIDC provider

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
'

Upgrade oidc-authservice

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.