Step-up auth: Apply global step-up auth enforcement like 2FA enforcement

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

Problem Statement / Context

We have implemented step-up authentication for groups, which allows group owners to require additional authentication before accessing protected group resources. While testing this feature internally (by enabling the omniauth_step_up_auth_for_namespace feature flag), we noticed a few limitations with the current enforcement approach.

Current Limitations

Step-up auth is only enforced when users directly access protected group or project pages. This is a valid approach — it follows the spirit of step-up authentication where only certain resources require elevated authentication. However, in the context of GitLab, this scoped enforcement causes several problems:

  1. Information leakage via dashboard views: Users can see content from protected groups on their dashboard (activity feeds, merge request lists, issue lists) without completing step-up authentication
  2. Information leakage via global search: Users can discover and view content from protected groups through global search results
  3. Inconsistent security model: Group owners can access their step-up auth protected groups without completing the authentication challenge, creating a bypass path
  4. Delayed enforcement: Step-up auth is only triggered when the user navigates to the protected resource, not immediately upon session creation

Fixing these on a page-by-page basis would be complex, fragile, and prone to gaps as new features are added.

Comparison with 2FA Enforcement

Looking for a more robust solution, we investigated existing enforcement patterns in GitLab. The 2FA enforcement for groups follows a stricter, global enforcement model that addresses these exact challenges:

  • When a user is a member of a group requiring 2FA and hasn't set up 2FA yet, they are immediately redirected to the 2FA setup page
  • The user cannot access ANY page in GitLab until they complete 2FA setup
  • This applies globally via ApplicationController, not just to the protected group's pages

The current step-up auth implementation does not follow this established pattern.

Proposal

Implement global step-up auth enforcement that aligns with the 2FA enforcement behavior. When a user is a member of a group requiring step-up authentication, they must complete the step-up auth challenge before accessing ANY page in GitLab—not just the protected group's pages.

🛠️ with ❤️ at Siemens

Current Behavior Proposed Behavior (Aligned with 2FA)
graph TD
    A[User logs in] --> B[Session created]
    B --> C[User visits dashboard]
    C --> D[User can browse freely dashboard, search, other groups]
    D --> E[User visits protected group]
    E --> F[Step-up auth required]
    F --> G[User can STILL browse OTHER content while step-up auth is pending]
    style G fill:#f99,stroke:#c00
graph TD
    A[User logs in] --> B[Session created]
    B --> C[User visits ANY page]
    C --> D{Is user member of ANY group requiring step-up auth?}
    D -->|Yes + Not completed| E[REDIRECT to step-up auth]
    E --> F[User LOCKED to step-up auth page cannot browse ANY content]
    F --> G[User completes step-up auth]
    G --> H[User can now access ALL pages]
    style F fill:#ff9,stroke:#c90
    style H fill:#9f9,stroke:#0a0

Benefits and Trade-offs

Benefits Trade-offs
Immediate enforcement: Step-up auth is triggered immediately, not delayed until the user visits the protected group Stricter enforcement: Users must complete step-up auth before accessing ANY GitLab page, even if they only intended to work on unprotected resources during that session
Consistent security model: Aligns with the well-established 2FA enforcement pattern, providing consistency for administrators and users This is intentional and aligns with 2FA enforcement for groups: "Users without 2FA enabled who are not in an enforcement grace period are unable to access any GitLab resource when they are members of a group requiring 2FA."
Closes security gaps: All users (including group owners) must complete step-up auth before accessing any GitLab content Membership in a step-up auth protected group implies the user handles sensitive resources and should complete verification before accessing the platform
Addresses information leakage: Addresses #581316 (dashboard views) and #581317 (global search) — users can no longer see or discover content from protected groups without completing step-up auth
Simplified mental model: Users authenticate once per session and then work normally — similar to 2FA enforcement

Technical Approach

Follow the established EnforcesTwoFactorAuthentication pattern: add a global before_action in ApplicationController that redirects users to a step-up auth page when required, and skip it in essential controllers (logout, help, terms, OAuth callback).

Implementation Checklist

  • Create global enforcement concern and include in ApplicationController
  • Replace existing namespace-scoped enforcement with global enforcement
  • Skip enforcement in essential controllers (following the 2FA pattern)
  • Add fallback profile page for step-up auth completion
  • Add tests (unit, request, integration)
  • Update documentation

Related Resources

  • #581316 — Step-up auth: Protect content in dashboard views and navigation
  • #581317 — Step-up auth: Protect content in global search results
  • #579283 — Step-up auth: Improve recovery mechanism for group owners (not addressed here)
  • 2FA enforcement for groups — The established pattern this proposal aligns with
Edited Feb 12, 2026 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading