argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
18.02k stars 5.49k forks source link

ArgoCD Dex doesn't read attribute properly #15561

Open jonasz-lasut opened 1 year ago

jonasz-lasut commented 1 year ago

Checklist:

argocd-server: v2.7.7+4650bb2.dirty

BuildDate: 2023-07-05T19:42:32Z

GitCommit: 4650bb2817c3c81405f40cf77e93ef2b5fb275fb

GitTreeState: dirty

GoVersion: go1.19.10

Compiler: gc

Platform: linux/amd64

Kustomize Version: v5.0.1 2023-03-14T01:32:48Z

Helm Version: v3.11.2+g912ebc1

Kubectl Version: v0.24.2

Jsonnet Version: v0.19.1


**Describe the bug**

ArgoCD Dex server reads proper SAML response from the microsoft azure however it fails to authenticate because it can't find the attribute with the name email, which is present in the response. This leads to failed login using SAML. SSO was configured using the documentation linked above

**Expected behavior**

ArgoCD should allow user login as email attribute is present in the SAML response

**Screenshots**

![image](https://github.com/argoproj/argo-cd/assets/93281932/75e2a627-b6ba-413a-a5d8-085f4e1ce840)

**Logs**

argocd-dex-server-ID logs with censored IDs/emails

{"level":"info","msg":"parsed and verified saml response attributes \http://schemas.microsoft.com/identity/claims/tenantid\ = \"****----****\", \http://schemas.microsoft.com/identity/claims/objectidentifier\ = \"****----****\", \http://schemas.microsoft.com/identity/claims/identityprovider\= \https://sts.windows.net/****----****/\, \http://schemas.microsoft.com/claims/authnmethodsreferences\ = [\http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password\ \http://schemas.microsoft.com/claims/multipleauthn], \http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname) = \"**\", \http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname\ = \"**\", \http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/name\ = [**@email.com], \http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/emailaddress\ = [**@email.com], \http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email\ = [**@email.com], \"Group\" = \"****----****\"","time":"2023-09-19T08:15:17Z"}

{"level":"error","msg":"Failed to authenticate: no attribute with name \"email\": http://schemas.microsoft.com/identity/claims/tenantid http://schemas.microsoft.com/identity/claims/objectidentifier http://schemas.microsoft.com/identity/claims/identityprovider http://schemas.microsoft.com/claims/authnmethodsreferences http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email Group]","time":"2023-09-19T08:15:17Z"}


argocd-cm

apiVersion: v1

kind: ConfigMap

metadata:

name: argocd-cm

namespace: argocd

data:

admin.enabled: "true"

application.instanceLabelKey: argocd.argoproj.io/instance

dex.config: |

logger:

  level: debug

  format: json

connectors:

- type: saml

  id: saml

  name: saml

  config:

    entityIssuer: https://argocd-url/api/dex/callback

    ssoURL: [https://login.microsoftonline.com/********-****-****-****-************/saml2]

    caData: |

      BASE64-ENCODED-CERT

    redirectURI: https://argocd-url/api/dex/callback

    usernameAttr: email

    emailAttr: email

    groupsAttr: Group

exec.enabled: "false"

server.rbac.log.enforce.enable: "false"

timeout.hard.reconciliation: 0s

timeout.reconciliation: 180s

url: https://argocd_url/


argocd-rbac-cm

apiVersion: v1

kind: ConfigMap

metadata:

name: argocd-rbac-cm

namespace: argocd

data:

policy.csv: |

p, role:readonly, applications, get, /, allow

p, role:readonly, certificates, get, *, allow

p, role:readonly, clusters, get, *, allow

p, role:readonly, repositories, get, *, allow

p, role:readonly, projects, get, *, allow

p, role:readonly, accounts, get, *, allow

p, role:readonly, gpgkeys, get, *, allow

p, role:readonly, logs, get, /, allow

p, role:dev-role, applications, , /*, allow

p, role:dev-role, clusters, get, *, allow

p, role:dev-role, repositories, get, *, allow

p, role:dev-role, repositories, create, *, allow

p, role:dev-role, repositories, update, *, allow

p, role:dev-role, repositories, delete, *, allow

p, role:dev-role, applicationsets, , /*, allow

p, role:dev-role, logs, get, /, allow

g, "****----****", role:admin # Comment: <---- That's the group that's returned in the info-level log

g, "****----****", role:dev-role

g, "****----****", role:dev-role

policy.default: ""

scopes: '[groups]'

JohnLBevan commented 1 year ago

Are you sure you're getting email in your SAMLResponse?

Here's some notes for how to find this in Chrome:

One other possibility is that often people use a mail attribute but some accounts don't have email addresses / this subtley often gets overlooked as most accounts have email. Using a userPrincipalName in the SAML mapping can avoid this. That's true for AAD at least; I'm less familiar with other identity providers (IdPs).

FYI: I came here as we're seeing a similar issue; but in our case it's with group rather than email. On the AAD side we've found that the value is assigned from user.groups; which I believe lists all groups the user's in; so think that where a user's in a lot of groups it goes out of bounds the system returns a http://schemas.microsoft.com/claims/groups.link attribute instead of a group attribute (that's currently a working theory; waiting for our AAD team to assist in this investigation / those not experiencing the issue to help confirm this theory). Some support for this theory: https://help.mulesoft.com/s/article/Azure-AD-SAML-group-attribute-limitation ... and https://github.com/argoproj/argo-cd/issues/8754.

Hope that's some help to others.