[Feature flag] Enable 7 day SAML SSO Enforcement expiry

What

Roll out and then remove the :enforced_sso_expiry feature flag.

See !29786 (merged).

Owners

• Team: Manage::Access
• Most appropriate slack channel to reach out to: #g_manage_access, #s_manage
• Best individual to reach out to: NAME

Expectations

Dangers (via issue)

• Enabling this could effectively 'sign out' a large number of users who would previously have had access but will now be sent back through the auth flow. We might want to roll it out to a gradually increasing percentage of groups using the feature flag, and possibly to do that during periods of low activity to spread load.
• If users try to submit form data after the session has expired they could lose data they had worked on, such as an issue description. For some things we have these cached in the browser, but we'll want to verify edge cases to reduce the burden of this. Setting a shorter (24h, or 1h) expiry would increase the frequency that users hit those edge cases.

What are we expecting to happen?

• To see a spike in users having to re-authenticate, but for them to only have to do so every 7 days after that
• We might see a spike in errors from users unable to complete tasks having been signed out

What might happen if this goes wrong?

• The consequence of being signed out could be disruptive to users, such as on POST requests
• We might see unexpected errors checking the validity of a session in SsoEnforcer
• Users may be unable to sign in if their identity provider is misconfigured, but were relying on an already authorized session

What can we monitor to detect problems with this?

Which dashboards from https://dashboards.gitlab.net are most relevant?

SsoEnforcer? Groups::OmniauthCallbackController? SsoController

Beta groups/projects

We should roll this out to individual groups, followed by a tiny percentage of groups initially.

If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.

• gitlab-org/gitlab-com groups
• ...

Roll Out Steps

• Enable on staging
• Test on staging
• Ensure that documentation has been updated
• Enable on GitLab.com for individual groups/projects listed above and verify behaviour
• Coordinate a time to enable the flag with #production and #g_delivery on slack.
• Announce on the issue an estimated time this will be enabled on GitLab.com
• Enable on GitLab.com by running chatops command in #production
• Cross post chatops slack command to #support_gitlab-com (more guidance when this is necessary in the dev docs) and in your team channel
• Announce on the issue that the flag has been enabled
• Remove feature flag and add changelog entry
• After the flag removal is deployed, clean up the feature flag by running chatops command in #production channel