Users with restricted email domain are assigned SAML identity but get 404 when accessing the group
Summary
Users have SAML and group links configured, as well as "Restrict membership by email domain" enabled as well. When a user with an email domain that is not allowed attempts to login with SSO login link, they get the message "Signed in with SAML", get a SAML identity linked to their account, but get 404 error on both the parent group and subgroups.
Ticket: https://gitlab.zendesk.com/agent/tickets/264624
Steps to reproduce
- Set up SAML with OKTA on one GitLab.com group
- Configure some group links on parent group and subgroups
- Add some email domain in the "Restrict membership by email domain"
- On OKTA, add at least 2 users; one of the domain that is allowed (X) and one that is not (Y), and assign them to the mapped AD groups.
- Attempt to trigger the authentication process from OKTA, or follow the SSO login link
Example Project
I was able to reproduce it in asmaa-gold
.
What is the current bug behavior?
The user Y is able to sign in, and get a SAML identity, but not see the content of the group or underlying subgroups and projects.
The logs show them successfully signing in and group sync running, but the user never ends in the members list
What is the expected correct behavior?
- The user Y not allowed to sign in and get SAML identity in the first place
- We provide a better error message, like the one they get when attempting to invite a user with a restricted email domain: "you can not add this email address. Please consult your administrator"
Relevant logs and/or screenshots
From the audit events, it appears that the user (Y)is signed in and given access:
From Kibana:
Output of checks
This bug happens on GitLab.com, GitLab Enterprise Edition 14.8.0-pre 6510a18c