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.
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 (closed) 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.
As a GitLab organization administrator, I want the ability to configure SSO on the top-level group (as it is now) and then be able to assign multiple IdP groups to a specific role for both the top-level group and subgroups.
In our organization we are doing this manually by creating GitLab groups that replicate our IdP groups that we manually assign users to. Then we provided access to those groups in other groups. All users, except for GitLab organization administrators, are top-level guests because we do not want our users to have access to every subgroup in the top-level group.
@walkafwalka in this scenario, i imagine we'd need to have some way for you to map your idp groups to gitlab groups/roles. is that what you were thinking?
cc: @dblessing i spoke to a prospect today that described this same scenario.
Exactly. Ideally a one-to-many instead of a one-to-one for GitLab group to IDP group(s). One-to-one could also work but I have had some difficulties getting access control between groups to work how I expect it to.
For example, created teams that represent all of our developers. I put each developer in their respective team as maintainers. I then gave developer access to to each group to every other group. I would expect this would result in every developer being a maintainer of their group and a developer in the other groups. I may be doing this incorrectly, but instead, every developer is a maintainer in their own group and a guest in the other groups. We opted to give top-level developer access to every developer even though it gives them developer access to repositories that we do not want them to have developer access to.
P.S. I apologize for the delayed response. Had a little hiatus.
@mushakov I missed the ping before. Sorry about that.
I can see a desire for this, especially if we move toward the no access idea for the top-level group. Do we have a separate issue for this? Or maybe with the no access concept this issue becomes irrelevant as written and we morph it into the subgroup access issue?
Melissa Ushakovchanged title from Add GitLab User Role mapping to SCIM for user provisioning at specific access level to Set default role for SSO in Gitlab.com
changed title from Add GitLab User Role mapping to SCIM for user provisioning at specific access level to Set default role for SSO in Gitlab.com
Hi @mksionek. As per our refinement process, please could you review and estimate this issue. If you are happy with the scope of the issue please add a weight and assign to another engineer in the team for review so they can add the workflowready for development label.
@mksionek would you need frontend support on this at all? Sounds like you'd have it under control! Let me know and I can have Peter take a look at this.
@mksionek I agree with the estimation, but I think that we have an inconsistency on the description of the issue, not sure if it is something that I'm not following but within the proposal we say: ...This is not the most robust solution but allows small teams to bring everyone in at a more trusted level... and within type of buyer: This would be for larger organizations that use SSO.
Maybe something small, but it will be relevant to add to the checklist is to check that the audit event for the user 'creation' reports the new default role properly.
@ebrinkman They are two distinct issues. This issue covers choosing a default role for new SSO users, whereas #220203 (closed) introduces a new role 'No Access'. Only by delivering both issues will users be able to set No Access as the default role.
@manojmj I've filled the "Availability & Testing" section with a note for updating/adding to the e2e tests. Let me know if you have any questions. Thanks.
Hello @sliaquat, thanks so much! :) I just checked the code, but it appears that we do not have a test to assert that the user is being added with "Guest" permission currently. If we were to add this new assertion, what would be the best way to do it? Would it be visiting the members page of the group and seeing the role?
Another possibility is allowing SCIM to add directly to a subgroup.
If all repository hierarchies are created outside that group, then I believe users would automatically have "no access" to the parallel groups in the namespace?
I have no idea how difficult this would be to code - but it is one way I have though of to get around this without having to wait for a new "no access" role level to be created.