What does this MR do and why?

Display a warning when creating LDAP or SAML synchronizations if restricted access is enabled.

Changelog: changed

EE: true

References

• #567749
• Design

Screenshots or screen recordings

	Result	Copy (self-managed)	Copy (gitlab.com)
LDAP		With restricted access active and no seats available, new users provisioned through LDAP sync are assigned the non-billable Minimal Access role. Learn more about provisioning behavior with LDAP.	N/A
SAML		With restricted access active and no seats available, new users provisioned through SAML/SCIM group sync are assigned the non-billable Minimal Access role. Learn more about provisioning behavior with SAML/SCIM.	With restricted access active and no seats available, new users provisioned through SAML/SCIM group sync are assigned the non-billable Minimal Access role. Learn more about provisioning behavior with SAML/SCIM.

How to set up and validate locally

Configure LDAP and SAML - Self-managed

1. Configure GDK to run in Self-managed mode: export GITLAB_SIMULATE_SAAS=0

2. Enable LDAP gdk config set openldap.enabled true && gdk reconfigure

3. Set up SAML for the instance by adding the following to config/gitlab.yml

   development:
     <<: *base
     omniauth:
       providers:
       - {
           name: 'saml',
           args: {
             assertion_consumer_service_url: 'http://<gitlab-host>:<gitlab-port>/users/auth/saml/callback',
             idp_cert_fingerprint: '11:9b:9e:02:79:59:cd:b7:c6:62:cf:d0:75:d9:e2:ef:38:4e:44:5f',
             idp_sso_target_url: 'https://<gitlab-host>:8443/simplesaml/saml2/idp/SSOService.php',
             issuer: 'http://<gitlab-host>:<gitlab-port>',
             name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
           }
         }

4. Start GDK: gdk start

5. Open the rails console and enable the feature flag: ::Feature.enable(:bso_minimal_access_fallback, :instance)

6. Enable restricted access at /admin/application_settings/general#js-signup-settings in Seat Control section

7. Navigate to the LDAP synchronizations page for a group: /groups/<group>/-/ldap_group_links

   1. Verify the warning is visible
   2. Turn of restricted access and verify the warning is not shown

8. Navigate to SAML group links page for the group: /groups/<group>/-/saml_group_links

   1. Verify the warning is visible
   2. Turn off restricted access and verify the warning is not shown

Configure SAML - SaaS

8. Configure GDK to run in SaaS mode: export GITLAB_SIMULATE_SAAS=1
9. If enabled from step 2 above, disable LDAP: gdk config set openldap.enabled false
10. Enable SAML group sync: gdk config set && gdk reconfigure
11. Repeat step 3 above to configure SAML group sync
12. Start GDK: gdk start
13. Enable the feature flag for a top-level group: ::Feature.enable(:bso_minimal_access_fallback, group)
14. Navigate to the group's settings and enable Restricted Access: Settings > General > Permissions and group features > Seat Control
15. Navigate to SAML group links page for the group: /groups/<group>/-/saml_group_links
    1. Verify the warning is visible
    2. Turn of restricted access and verify that the warning is not shown

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Updated designs in the description. Changed workflow to read for dev.

@m_frankiewicz Yes. The content doesn't need to convey everything RA. I think conveying what is blocking me, why is this the case and what can I do about it should be good enough.

From the UX perspective, the all or nothing provisioning of a group feels bit rigid. There is definitely a better approach + flexibility that can be afforded to users to improve this experience.

@m_frankiewicz @lciutacu Updated copy for review

Current	Updated
Restricted access is turned on for your organization by default.	Restricted access is turned on for your organization by default. This prevents overages when no seats are available. Purchase more seats to add users.

@lwanko This happened a few weeks ago. Here is the Slack convo that stirred up that scenario. TLDR guest users on Premium forked repos into their personal namespaces, when the upgrade happened, their roles were promoted to owner I guess so became billable when they should have been un-billable on Ultimate. In a SAM world, their seat type ideally that would drive the billable status so even if their role changes they wouldn't be billable.

I think that SAM would disallow for this to happen, as the seat type will limit roles available to user.

I was just trying to map this scenario, let me know if this aligns. Their role can change but the seat wont change so they remain non-billable.

here you mean that you'd want to show the customer the amount of users that would become non-billable with the upgrade? Yes. I remember from that scenario users having to dig for role elevation and no easy way to do it. Essentially, making it for users to understand the distribution of roles across their space.

Updated the final designs in the description w/ link to the figma.

Made the updates. Moving to -workflowready for development

@jagood @m_frankiewicz Thanks for the information. From the user perspective, I see value in showing the highest role that a member occupies especially in the instances where subscription upgrades happen and we see some users move from guest to owner roles because they had some projects in their personal name space. But ultimately I think this might be a research question to answer.

Agree with all these also:

• showing the user seat type
• ability to sort by seat type
• ability to show what role user has where

@m_frankiewicz Agreed. Do we have any data around csv downloading feature usage? I would also side with keeping it in SAM.

I watched the video walkthrough. You have to enable FF first, so that new users over the licence seats are provisioned with MA role - I don't know if you did that, you didn't show it in the video.

I was working off a git branch of @karichards (for the SAML settings) that I thought would work. I didn't activate the FF. Have to learn how to do that.

Your instance has Ultimate license, and Guest users are non-billable on Ultimate. That uncovers interesting point - on Ultimate, with RA enabled, FF for provisioning behaviour (provision with MA role) enabled and no more billable seats available, the new users could still be provisioned with Guest role, as that would not add more billable users. Right now they would be provisioned with MA role instead. We should consider what the behaviour should be in that case.

In this case, for better parity and future tech debt, wouldn't it be easier to keep it as new users get provisioned with MA instead of guest. How would provisioning happen with LDAP/SAML + Ultimate licence? Would it be guest or MA? @paulobarros @karichards @lwanko

Perhaps we're also missing info/warning about RA enabled and how that affects overages on this page

Yes. Maybe we might have to look into some preemptive way to set better expectations for users. before they hit their seat limit.

I see context for what might happen in settings, but I still have to read through all the documentation. It's not clear to me when you had to do it, could you elaborate?

This is more a call out for how much documentation and is it clear what a user needs to go through to understand what that radio button toggle actually does. (More assessable with testing)

I assume the exercise is to see how the scorecard score for RA improves with the changes we've implemented and are still working on for RA, right? So the scorecard exercise will be repeated when the issues in RA completion epic are all done (apart from roll-out related). Is this correct understanding?

Yes ... this can be revisited to evaluate updates.

@m_frankiewicz just to clarify:

I think we should show the same informational content explaining that RA is preventing overages and how provisioning works.

The current designs in the description doesn't have any radio buttons compared to the screenshot you shared from the scorecard. Are you recommending we update the copy to be more descriptive from what it is currently?

Current	Updated
Restricted access is turned on for your organization by default.	Restricted access is turned on by default . This prevents overages when no seats are available by assigning new users the non-billable Minimal Access role.

@m_frankiewicz Is this part accurate? "assigning new users minimal access role" in this scenario. Provisioning through LDAP/SAML force user creation but does it operate the same way for self-serve?

@m_frankiewicz Updated the the designs in the description with the latest UI copy. If we are good, I can move this issue to dev review.

@dstull & @karichards Appreciate looping me in.

On top of the above stated reason, UX went through a recent banner clean up and purge so any new banners need to be well validated for use.

@m_frankiewicz

Thanks @erhan.dsilva! What about the banner? Should it be shown on top level group members page (.com ) and user list (SM) respectively? Or we don't show banners?

Yes to both top level for .COM and user list for SM. In this scenario, I think it still warrants a banner for the user to understand they are restricted and needs to take action.

Everything looks good with the banner except for the last point

Links point to relevant documentation for restricted access and seat purchasing

Checked with the ux team. Generally any kind of cta should link to enabling the user to that action. We usually link to CDOT directly vs documentation. Maybe a secondary link to documentation

:: [Purchase more seats] ( Links to CDOT) | Learn more ( Links to documentation )

@m_frankiewicz @paulobarros I did the UX scorecard the video above. It was a bit tough to get my local instance of GDK to run exactly for this SAML scenario which I point out in the video. Let me know what you think. I guess the big question I discovered is that setting under SAML SSO configuration where it has the option to set a role. What happens here if they set this to something else under RA. We might have to disable this or add some note here.

cc @esybrant @dzubova @paulobarros

@m_frankiewicz @lciutacu

Updated email copy:

.COM

SM

Hello {Admin} We're notifying you that {count} users provisioned through {SCIM/SAML/LDAP} have been assigned the Minimal Access role because restricted access is on and no seats are available in your subscription. Review your usage quotas or purchase more seats. To identify the affected users, go to your top level group members page and sort the members table by User created in descending order. Users provisioned on {sync_date} and assigned the Minimal Access role will appear at the top of the list. Users with the Minimal Access role can only view limited group information without access to projects. To grant more permissions to these users, you should first review your seat usage. Then either: Change the users' role in the group or project. Purchase more seats. If you have any questions or need help, contact GitLab support. Thanks, The GitLab Team

Hello {Admin} We're notifying you that {count} users provisioned through {SCIM/SAML/LDAP} have been assigned the Minimal Access role because restricted access is on and no seats are available in your subscription. Review your user list or purchase more seats. To identify the affected users, go to your user list page in your admin area and sort the members table by Last created. Users provisioned on {sync_date} and assigned the Minimal Access role will appear at the top of the list. Users with the Minimal Access role can only view limited group information without access to projects. To grant more permissions to these users, you should first review your seat usage. Then either: Change the users' role in the group or project. Purchase more seats. If you have any questions or need help, contact GitLab support. Thanks, The GitLab Team

Key changes: Updated the references to the different tables + filter reference (.COM can filter by last created + descending but user list on SM can only shows last created w/ default sort as descending)

Closing this issue.

UX work done in the following issues

#580421

#567750 (closed)

#567749 (closed)

#580284