SSO Enforcement requires SSO to access public groups for non-members

Summary

When enabling the SSO Enforcement feature for a public GitLab top-level group by checking the Enforce SSO-only authentication for web activity for this group option, non-members are required to go through SSO before accessing the public group or its sub-groups.

Accessing public projects in the group is allowed.

As per the SSO Enforcement description table non-members, non-signed it users should be able to access public objects without SSO:

Project/Group visibility	Enforce SSO setting	Non-member or not signed in
Public	On	Not enforced

Steps to reproduce

1. Create a GitLab top-level group and set its visibility to Public.
2. Enable and configure SAML SSO for groups for the group.
3. Check the Enforce SSO-only authentication for web activity for this group SSO setting for the group.
4. Create a sample, public sub-group under the top-level group.
5. Create a sample, public project under the created sub-group.
6. Try to access the public project without a GitLab session, this works as expected and the project can be accessed.
7. Try accessing either the sub-group or the top-level group and SSO is enforced.

What is the current bug behavior?

Non-members, not-signed-in users are forced to log in via SSO when accessing a public group/subgroup.

What is the expected correct behavior?

Non-members, not-signed-in users should be able to access public groups/subgroups if SSO is enforced, the same way they can access public projects.

Output of checks

This bug happens on GitLab.com