Docs feedback: SAML SSO and SCIM user management update
What does this issue address
- The Update access and linking setup does not thoroughly describe the user creation process.
While testing SCIM from Azure AD to gitlab.com I've noticed the following, which should be highlighted in the docs:
- Both primary and secondary emails are considered when checking whether a user account exists
- This makes sense as you also cannot create a new user manually with a duplicate email (one that is used for an existing account as either primary or one of the secondaries)
- Duplicate usernames are also handled, by adding suffix
1
upon user creation (e.g. due to already existingpprokic
username,pprokic1
is used)
- In Azure configuration steps the following should be pointed out:
-
Synchronize Azure Active Directory Groups to AppName
should be disabled but this does not mean Azure AD users cannot be provisioned in groups as they can as individual users. Leaving it enabled does not break the SCIM user provisioning but causes errors in Azure AD that may be confusing and misleading.
- SCIM setup - Blocking access and SAML SSO - Blocking access should be joined as a single source of truth as this way they might suggest manual user removal (by group owner) is required.
- Remove the user from the GitLab.com group.
While testing blocking user access to group via SCIM I've noticed:
- If SSO is enforced, the user is immediately blocked from accessing the group, but will take a SCIM (Azure AD) sync (every Xmin by default in Azure) to completely remove the user as a SAML SSO member.
- Without SSO enforced it will take a SCIM sync (every Xmin by default in Azure) to completely remove the user as a SAML SSO group member and therefore block access to the group.
Edited by Petar Prokić