Session variable to store provider two factor bypass

What does this MR do and why?

We are storing two factor auth status for SAML SSO login request in a session variable to bypass the enforcing of 2fa on Gitlab end.

Solution for #196131 (closed)

File https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/concerns/enforces_two_factor_authentication.rb does not have any reference of omniauth hash that is passed along with SAML SSO procedure, this makes it difficult to figure out whether user has Two factor configured at its IDP end or not. In-fact we don't even know if the user is a SAML user or not. We need this information to figure out whether we should render this prompt

Or not like this -

Demo

ByPass2FADemo

How to set up and validate locally

1. Create a developer okta account

2. Follow the guide https://developer.okta.com/docs/guides/mfa/ga/main/ to setup Multifactor authentication via Google authenticator in your developer.okta.com account

3. Set up Gitlab application to support instance level SAML SSO using guide - https://docs.gitlab.com/ee/integration/saml.html

4. Enforce Two factor authentication for all users using guide - https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users

5. Add configurations to gitlab.yml to bypass two factor authentication https://docs.gitlab.com/ee/integration/saml.html#bypass-two-factor-authentication For okta the authentication context that needs to be added to array upstream_two_factor_authn_contexts is urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport since okta does not support standard Authentication context classes like Mobile Two factor

6. Login to gitlab application via SAML SSO and observe the global settings prompt is not rendered

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.