Group SAML redirect loop when extern_uid changes
When a user with an existing Group SAML identity is signed in to GitLab locally, and then signs in to their group but the extern_uid
sent by the identity provider changes, the user is stuck in a loop and cannot sign in.
This scenario can be avoided by configuring the IdP to use an internal ID value that is guaranteed to never change. For example, in our Okta setup notes we recommend using user.getInternalProperty("id")
which is Okta's internal ID for each user and never changes.
However, if a group configures the IdP to use a value that may change, such as email address, then this causes an extern_uid
mismatch on sign-in.
We should handle this situation, but we should consider the security implications, too. It would be easy for us to simply take the new extern_uid
value and update it in the database and let the user sign-in. But is this secure? I suspect it's mostly secure but there are some edge cases to consider. For example, what if a user accidentally signs in to the IdP using a different account? Then that account would be associated with their GitLab account vs. the correct one. Under most circumstances this is probably not a concern as most users would only have one account with the given group IdP.
This scenario is only an issue for users that sign-in to GitLab locally, and also via IdP. If users exclusively use Group SAML to sign-in they won't experience this issue. Well, to be complete, if users exclusively use Group SAML to sign-in and their extern_uid
changes GitLab will try to create a new account for them. This is why we recommend choosing the internal ID that's guaranteed static.