Set default role for SSO in Gitlab.com
Problem to solve
Currently when using SAML SSO for GitLab.com groups the default Role of a newly created user is Guest. The requires users/administrators to have a second process to add users to projects and groups at their desired access level. Many customers have a secondary homegrown process that goes back and changes the role for all users.
Intended users
Further details
Giving administration and security teams the ability to use their already centralized user and application management systems (i.e. Okta, ADFS, etc.) to ensure an appropriate level of access would cut down on the administration time required to onboard new users into GitLab.
Proposal
Allow for the default role to be changed from Guest to any other option for the top-level group. This allows organizatons to bring everyone in at a more trusted level (i.e. Developer) or lower level (i.e. No Access). If a more permissive role is granted explicitly then this setting would no longer apply (ie a user would not be able to be "downgraded" by SSO). This setting should apply to users created via SCIM and users that join a group by following an SSO link.
This would be a small iteration and further enhanced by #118 in the future.
Permissions and Security
This would use existing permissions required to add/update/delete existing users.
Documentation
Availability & Testing
What risks does this change pose to our availability?
This is a low risk feature that should not affect GitLab.com availability.
What additional test coverage or changes to tests will be needed?
We have existing coverage for Group SAML SSO at e2e level that should be updated to add a test that ensures the users are assigned the selected roles.
What does success look like, and how can we measure that?
What is the type of buyer?
This would be for larger organizations that use SSO. Auditing and Reporting of access levels would be ideal for a compliance team.
Is this a cross-stage feature?
Links / references
/cc @dblessing