Allow GitLab.com to use the assertion "nickname" and "username" when integrating with SAML
The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Problem to solve
At this point is not possible to have customers that use SAML and want to connect to GitLab.com to make use of the assertion nickname or username in their configuration. This is implemented for self-managed instances but not yet for our SaaS product
Intended users
Developers
User experience goal
Users will be capable of entering nickname or username into their assertion attributes and it will be identified and used properly by GitLab.com
Proposal
Further details
A case in which this could be useful is this one from a client that uses a non-supported SAML provider which doesn't work properly with the assertion username we tried with the assertion nickname but found out later that the same cannot be used on our SaaS product.
Permissions and Security
Access:Manage
Documentation
The Docs will need to be updated once this issue is finished. Please refer to !61198 (merged)
Availability & Testing
Add a feature test for SaaS where a user is able to login by providing assertion nickname.
Available Tier
What does success look like, and how can we measure that?
Customers are able to use the assertion nickname or username with GitLab.com when integrating SAML
What is the type of buyer?
Is this a cross-stage feature?
Links / references
The following use case shows the inability to use these assertions by a customer who doesn't have a supported SAML tool.
This is the conversation we had with the Access team about the possibility to implement these configuration changes
On second thought it appears it might be dependent on configuration within the app, too. And I think we may have to define an attribute statement within GitLab in order for SAML to allow that in the auth hash
Yeah, I'm pretty sure we would have to specify the expected attribute statements, which we do not currently specify nickname.
It could work for self-managed but not gitlab.com. The docs you linked are most relevant for self-managed. We don't mention username or nickname on https://docs.gitlab.com/ee/user/group/saml_sso/
The reason it works for self-managed, is due to attribute_statements configuration documented at https://docs.gitlab.com/ee/integration/saml.html#attribute_statements. If the admin configures the nickname or username statement, and it's present in the response, it works
Yes, we should create a feature proposal. It wouldn't be too much work to either look up the username/nickname differently or specify a default attribute statement for GitLab.com