[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
Edited by James Edwards-Jones