Replies: 3 comments 6 replies
-
@stebenz @livio-a @muhlemmer what do you think about this? |
Beta Was this translation helpful? Give feedback.
-
It would make sense if there is an option to pick which attribute must be used as the unique user ID. I've seen this flexibility also in OIDC client libraries like symfony-oidc. Both proposed solutions sound reasonable to me. |
Beta Was this translation helpful? Give feedback.
-
We've been attempting to set up SAML SSO with Entra ID, following the documentation available at (https://zitadel.com/docs/guides/integrate/identity-providers/introduction) and have been struggling with the same issue as discussed in this discussion. Decoding the SAML request, it seems that Zitadel actually requests a transient Name ID: When requesting the correct Name ID policy, Entra ID will respond with a persistent Name ID attribute (https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol). However, the current implementation will lead to the same issue as described in this discussion. Just leaving this as note for everyone that spends hours on debugging the issue, I have disclosed the details with the support. |
Beta Was this translation helpful? Give feedback.
-
After experimenting with Zitadel and looking at the source code, I realized the Subject NameID element of the SAML response is always used as the external user ID. We'd like to have the ability to configure one of the attributes present in the SAML response as the external user ID instead.
Why is this important to us?
Some of our customers' IDPs use transient Name IDs for subjects (see
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
on section 8.3.8 of the specification). This means these IDs cannot be relied on as they can change between logins.At the same time, the NameID is optional according to the specification: see section 2.4.1.
What happens in Zitadel when transient Name IDs are used?
Zitadel fails to create/update the user with a "User already exists" error after Zitadel receives the SAML response from the IDP:
I believe this happens because the user's Subject Name ID differs from the previous login, while the username remains the same. Zitadel understands there is a new user logging in that has to be created, but since the username is already in use it raises that error.
Possible Solutions
setExternalId
function to Actions configured to run for external authentication flows.How do other solutions solve this problem?
Auth0 allows setting a User ID Attribute when configuring a SAML identity provider (more details can be found here).
Beta Was this translation helpful? Give feedback.
All reactions