Skip to content

'SessionNotOnOrAfter' attribute at 'saml:AuthnStatement' SAML response element has to be optional #21042

@bitpavel-l25

Description

@bitpavel-l25

Is your feature request related to a problem?

During our migration of a self-hosted GitLab cluster from Okta to self-hosted Authentik, we encountered an issue where users could no longer approve merge requests (MRs) when the "Require user re-authentication (password or SAML) to approve" setting was enabled for a repository. GitLab has a three-year-old epic dedicated to this unresolved issue: https://gitlab.com/groups/gitlab-org/-/work_items/11084.

Issue Details
Our testing revealed that the problem stems from the SessionNotOnOrAfter attribute in the saml:AuthnStatement element of the SAML response:

  • When an SSO session is still active, GitLab prompts for the user's password, requiring users to configure one—which is impractical in an SSO-only environment.
  • When we set a short session TTL (e.g., 10 seconds), GitLab redirects to the SSO service to refresh the session instead of requesting a password. However, upon returning to GitLab, users see a 404 error.
  • When SessionNotOnOrAfter is omitted entirely, GitLab successfully redirects to SSO and accepts the MR approval upon the user's return.

While this appears to be a GitLab issue, two points suggest otherwise:

  1. Okta omits the SessionNotOnOrAfter attribute in SAML responses for all services.
  2. The SAML 2.0 specification marks this attribute as optional (https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, section 2.7.2, p.27)

Describe the solution you'd like

Let's make 'Session valid on or after' parameter optional.

Describe alternatives that you've considered

Do not send the SessionNotOnOrAfter attribute in the SAML response (as Okta does). However, this is not backward-compatible. Okta also maintains various integrations in its "App Catalog," where it manages app-specific differences automatically. SAML responses may therefore vary across different applications. Thus, such approach may be dangerous.

Additional context

How to reproduce:

  1. Configure SSO for Gitlab via SAML protocol
  2. Enable 'Require user re-authentication (password or SAML) to approve' approval parameter for a reposity
  3. Create a MR and try to click the 'Approve with SAML' button at the MR

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requeststatus/reviewingthanks for opening, we're taking a looktriageAdd this label to issues that need to be triaged

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions