Handling when using unverified e-mail address at auth0

[junoriosity]

As mentioned earlier (#4219) I deployed kubeapps with

kubectl apply -f https://get.pinniped.dev/v0.13.0/install-pinniped-concierge-crds.yaml
kubectl apply -f https://get.pinniped.dev/v0.13.0/install-pinniped-concierge-resources.yaml

cat <<EOF | kubectl apply -f -
kind: JWTAuthenticator
apiVersion: authentication.concierge.pinniped.dev/v1alpha1
metadata:
  name: jwt-authenticator
spec:
  issuer: https://my-auth.eu.auth0.com/
  audience: my-client-id
  claims:
    groups: groups
    username: email
EOF

cat <<EOF | kubectl apply -f -
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubeapps-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: test@test.com
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: kubeapps-operators
EOF

kubectl create ns kubeapps
helm install kubeapps bitnami/kubeapps --namespace kubeapps -f myvals.yaml 

where myvals.yaml is

useHelm3: true
authProxy:
  additionalFlags:
    - --oidc-issuer-url=https://my-auth.eu.auth0.com/ # Example: https://antoniogamez.eu.auth0.com/  # mind the last "/" character
  # If you are using a different ingress config, you might need to tweak these flags. More info in the "oauth2-proxy" official docs
    - --redirect-url=http://127.0.0.1:3000/oauth2/callback
    # - --cookie-domain=localhost
    # - --whitelist-domain=localhost
    # - --cookie-secure=false
  clientID: my-client-id
  clientSecret: my-client-secret
  cookieSecret: bm90LWdvb2Qtc2VjcmV0Cg==
  enabled: true
  provider: oidc

pinnipedProxy:
  enabled: true # if using Pinniped, you'll need to enable this option here
#  defaultAuthenticatorType: jwt
#  defaultAuthenticatorName: jwt-authenticator

clusters:
  - name: default
    apiServiceURL: https://... # impersonation proxy URL
    certificateAuthorityData: ... #  impersonation proxy CA
    pinnipedConfig:
      enabled: true

Now, I can reach the login panel

But when I want to sign in with an e-mail, that is unverified at auth0, I receive

Now that experience could perhaps be improved. What about one of the following?

• A nicely looking page, that explains that the e-mail address is not verified yet plus a panel to resend the verification e-mail
• Allowing users access with unverified e-mail addresses

Is one of these possible with little effort (like adapting helm chart values) or just some adaptions in the code? If you could tell me, where in the code this e-mail verification aspect is handled, I would be happy to improve it myself.

[absoludity]

Now that experience could perhaps be improved. What about one of the following?

* A nicely looking page, that explains that the e-mail address is not verified yet plus a panel to resend the verification e-mail

* Allowing users access with unverified e-mail addresses

Is one of these possible with little effort (like adapting helm chart values) or just some adaptions in the code? If you could tell me, where in the code this e-mail verification aspect is handled, I would be happy to improve it myself.

Thanks for the offer! As it turns out, it's actually not part of Kubeapps itself but rather part of the configuration of the oauth2-proxy service that we use to handle the oauth2 for us. As per their docs for the command-line args, they include an option --insecure-oidc-allow-unverified-email which can be used to allow unverified emails, rather than returning an error - with the knowledge that it is completely insecure then (since anyone can potentially use an unverified email to get RBAC on your cluster).

So it should be possible to update your values.yaml with the authProxy.additionalFlags option with this argument. You can see other examples for this field in the values.yaml file. Let me know how you go.

[junoriosity]

@absoludity Many thanks for getting back to me on that aspect. I now used to set the configs in the values yaml as follows

authProxy:
  additionalFlags:
    - --oidc-issuer-url=https://my-domain.eu.auth0.com
    - --insecure-oidc-allow-unverified-email=true
  clientID: my-client-id
  clientSecret: my-client-secret
  cookieSecret: bm90LWdvb2Qtc2VjcmV0Cg==
  enabled: true
  provider: oidc

Now, when I try to login with a verified e-mail address things are usual - and desired.

If I use an unverified, however, I do not get to see the 500 error, but now I am immediately forwarded to the login page

The logs say the following for pinniped-proxy

INFO pinniped_proxy::service > GET https://my-k8s-url/ 401 Unauthorized
ERROR pinniped_proxy::service > Unauthorized by pinniped: authentication failed

Caused by:
authentication failed

and the auth-proxy says

...
10.244.0.238:46912 - 82bb7643658afb8467e7e5d1c7e8212d - test4@test.com [2022/02/22 13:53:40] kubeapps.my-domain.com GET / "/" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 304 0 0.002
10.244.0.238:46912 - 15b1691c72f0417f4d788b879b63d0fc - test4@test.com [2022/02/22 13:53:41] kubeapps.my-domain.com GET / "/custom_locale.json" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 200 2 0.002
10.244.0.238:46912 - 93d859119e308d2c5bcb826f2fc7600d - test4@test.com [2022/02/22 13:53:41] kubeapps.my-domain.com GET / "/custom_style.css" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 200 0 0.004
10.244.0.238:46912 - 86cb93454c5270f4bcbfc748a580ad44 - test4@test.com [2022/02/22 13:53:44] [AuthSuccess] Authenticated via OAuth2: Session{email:test4@test.com user:auth0|6214ead41f466500695785e2 PreferredUsername: token:true id_token:true created:2022-02-22 13:53:44.038554151 +0000 UTC m=+338.782961718 expires:2022-02-23 13:53:44.03808447 +0000 UTC m=+86738.782492059}
10.244.0.238:46912 - 86cb93454c5270f4bcbfc748a580ad44 - - [2022/02/22 13:53:43] kubeapps.my-domain.com GET - "/oauth2/callback?code=PshPsOkmUGlUe4ssiufoiQ6Ta_Aq8ymyjYlUj8w5cTWsl&state=vO8ZXsKyLG3QzZDDOZo4Diyf-S6xtERN9MixbBXu3fo%3A%2F" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 302 24 0.461
10.244.0.238:46912 - 7f6a789e88aa45449575d92846b64bad - - [2022/02/22 13:53:45] kubeapps.my-domain.com GET - "/oauth2/start" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 302 317 0.000
10.244.0.238:46912 - 54c2d227cc6f79868f1e19eedb78fd0d - test4@test.com [2022/02/22 13:53:46] kubeapps.my-domain.com GET / "/api/clusters/default/" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36" 401 47 0.103
...

[absoludity]

OK, so it looks like we satisfied oauth2-proxy, so it's running with the insecure option and allowing you to authenticate successfully, but pinniped is rightly rejecting the token and not willing to authenticate the user with the unverified email. I've checked the pinniped docs and don't see any --insecure-* flag to change this behaviour (nor would I expect to, as they are very strong on not allowing insecure options like this). Sorry, I don't think it'll be possible to use an unverified email to authenticate via pinniped.

[junoriosity]

@absoludity Thanks for your input again. This was very helpful, as usual. :)

[absoludity]

Great, yes I saw you got some good info from the pinniped team too!