2018-06-14: 11.0.2 exception request for gitlab-org/gitlab-ee!6126
Exception request
- Merge request to be considered for picking: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6126
Context
Allowing SAML authentication on GitLab.com is one of Sales' most highly demanded features, as without it many organizations feel they are limited to self hosting.
This is a GitLab.com feature that allows a Group admin to enable SAML sign in as a method for gaining access to a group.
The settings page merged in 10.7 with the bulk of this feature merging in 10.8. We've been conducting live usability tests on this feature over the past couple months and merged small fixes during 11.0. We're now happy with this feature and ready to remove the cookie restriction we had in place during this process.
Enabling this cookie was previously needed for a group Admin to view the settings page used to enable SAML for a group.
Issues and related:
- https://gitlab.com/gitlab-org/gitlab-ee/issues/4513
- https://gitlab.com/gitlab-org/gitlab-ee/issues/4217
- gitlab-org&40 (closed)
- Notes from our weekly meetings (internal only)
- https://gitlab.com/gitlab-org/gitlab-ee/issues/5899
- https://gitlab.com/gitlab-org/gitlab-ee/issues/4514
Why it needs to be picked
Takes Group SAML out of beta by removing the cookie restriction
Without this additional manual action is needed to use the feature meaning we couldn't really call it GA in the release post.
What is the urgency? We have companies waiting on us implementing multi-tenant SAML for GitLab.com which creates some of the urgency.
What are alternatives? The alternative would be waiting until the next release, or requiring each user to follow the documentation to manually set a cookie.
Potential negative impact of picking
Explain what could go wrong with the release if the MR is picked
The commit in this MR was cherry picked from a demo server where we have been testing with customers so there is little risk in the cookie code removal itself.
Include a description of the worst case scenario in case something breaks
There are risks relating to Group SAML as it introduces a new authentication method for GitLab.com, but these risks are already present if a user adds the cookie.
While we can use the omnibus setting to toggle Group SAML for GitLab.com this might not be acceptable once we've removed the cookie restriction, so the main risk is that removing this signals the feature as being ready to use and makes it harder to justify turning off.
Sign-off
The following need to provide initial approval for this exception request:
-
Release manager: @filipa -
Engineering team leader: @DouweM -
Engineering department leader (if different from team leader): @tommy.morgan -
Quality leader: @meks
If you are the last person to provide initial approval, assign this issue to the VPE for his approval:
-
VPE: @edjdev
After the VPE approves, check that the following is accurate before closing this issue:
-
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6126 has the correct milestone and label set so that the release managers will pick it. -
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6126 has a comment with a link to this issue: - Exception approved in ISSUE_LINK