Skip to content
GitLab
Next
Closed
Issue created by Melissa Ushakov@mushakov🌻Developer

SAML user provisioning

Release notes

Previously, users needed to complete a sign-up form as part of onboarding into a SAML-enabled group. In GitLab 13.7, we have introduced user provisioning for SAML-enabled groups. When a user logs into a SAML-enabled group for the first time, a user account will be created for them automatically if there's not an existing user with the same email. SAML provisioning improves the onboarding experience for new users and ensures that the account created contains the right information.

https://docs.gitlab.com/ee/user/group/saml_sso/#user-access-and-management

Problem to solve

Some groups are using IdPs that don't support SCIM but they want the benefits of automated account creation. We implemented this for Group Managed Accounts in #9153 (closed) but this functionality would be useful for all groups.

Intended users

User experience goal

Accounts are created easily and with the right information.

Proposal

Make the functionality built for GMA available to all groups.

  • The group administrator must enable this option.
  • We have a default mapping for attributes like what was built for GMA https://docs.gitlab.com/ee/user/group/saml_sso/group_managed_accounts.html#assertions
  • If we get a SAML request that contains an email that matches an existing GitLab account, we ask the user to log into that account. The username is read-only and we ask the user to enter the password for that account.
  • If we see a SAML request that contains an email that doesn't match an existing GitLab account, we create one using the details in the assertion.
    • We set a password as we do for SCIM accounts.
    • If we have a username conflict, we use the same logic that we use for SCIM to generate a new username.
  • Users created by JIT should receive the same email as SCIM provisioned users: #276018 (closed)

The high-level flow should be:

  • If this SAML identity is already mapped, then log the user in.
  • If a GitLab account exists that has a verified email that matches that in the SAML assertion, then ask the user to log in with that account. After login, the account will be linked to that SAML identity.
  • If a GitLab account doesn't exist that has a verified email that matches that in the SAML assertion, then create the account using the details in SAML.
  • Tie the user to the group that provisioned the account.
  • After login, the user will be linked to that SAML identity.

Further details

This functionality exists in GMA. The difference is that we should not have a flow where we make existing accounts become managed.

This functionality also exists in self-managed SAML.

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

https://help.salesforce.com/articleView?id=sso_jit_requirements.htm&type=5 https://support.jumpcloud.com/support/s/article/SAML-Supported-JIT-Provisioning

Edited by Melissa Ushakov