Skip to content

SSO Enforcement expiry

James Edwards-Jones requested to merge jej/sso-enforcment-expiry into master

What

Adds a 7 day expiry for SSO Session Enforcement on GitLab.com SAML for Groups.

Introduces a :enforced_sso_expiry feature flag to allow us to gradually roll out the change.

Closes #5015 (closed) and #214816 (closed)

Why

Some organizations expect this to force users back through the SSO flow more often than the default session expiry duration used for GitLab.com.

Why 7 days

For organizations that don't use SCIM to add/remove users from a group it can be preferable to have this a short as possible to ensure that access to resources is lost when permissions are removed or someone leaves their company. While some have asked for 24h expiry or 1h expiry this could lead to frequent failures when a user attempts to submit a form. Some users will also have to enter a password or complete a 2FA challenge each time, adding to the inconvenience. For that reason SCIM is preferred and can have immediate effect. 7 to 14 days is a middle ground that should reduce disruption, but we could theoretically allow customization at a later date.

How session enforcement works

We currently store the date when signing in with Group SSO, with this MR using the date that is already being stored.

We store this in the rails session (on Redis, linked to a cookie) using a hash of { saml_provider_id => DateTime }.

This can later be used to checked outside of the browser such as in !12594 (closed).

Dangers

  • 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.

Acceptance criteria

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by James Edwards-Jones

Merge request reports