Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,097
    • Issues 44,097
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,306
    • Merge requests 1,306
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #214523
Closed
Open
Created Apr 15, 2020 by Brad Downey@bdowneyDeveloper

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

  • Sidney (Systems Administrator)
  • Sam (Security Analyst)

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 (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.

Is this a cross-stage feature?

Links / references

/cc @dblessing

Edited Aug 11, 2020 by Melissa Ushakov
Assignee
Assign to
Time tracking