Honor saml assurance level to allow 2FA bypassing

What does this MR do?

It adds a configuration option (upstream_two_factor_auth) to the gitlab.rb/gitlab.yml:

      - {
          name: 'saml',
          args: {
                 assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
                 idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
                 idp_sso_target_url: 'https://login.example.com/idp',
                 issuer: 'https://gitlab.example.com',
                 name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
                 upstream_two_factor_auth:
                   [
                     'urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport',
                     'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS',
                     'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN'
                   ]

               },
          label: 'Company Login' # optional label for SAML login button, defaults to "Saml"
        }

which allow to specify SAML authn_contexts to count as a two factor login. So when a user for example did an authentication with a smartcard and a username/password, he won't be forced to authenticate again with two factors inside gitlab.

Are there points in the code the reviewer needs to double check?

Right now the authn_context is extracted from the raw xml response that was sent by the IdP Server. Is this a save approach or could a user tamper the SAMLResponse which passes trough his browser? Like changing the authn_context to a higher level? Or would this invalidate the SAMLResponse anyway?

Why was this MR needed?

Many SAML provider already support authentication with a second factor or even enforce such an authentication. Pairing this with the 2FA enforcement on GitLab side creates a really bad user experience, since a user has to provide a second factor twice. SAML already cover such cases by providing a property called assurance level to the application to represent the level of trust which the user provided (e.g. SmartCard).

Our proposal is to provide a new option in the SAML configuration in gitlab.rb called upstream_two_factor_auth which sets the assurance level which GitLab requires to treat the SAML response as two factor authenticated. After a user reached such a level when authenticating, GitLab shall not promt for a second factor even if enforce 2fa is enabled. This feature therefore consists out of two parts:

Extend SAML login to allow interpretation of SAML AssuranceLevel Bypass 2FA / Interpret login as 2FA when the idP response with a marching/high enough SAML AssuranceLevel

The development of this MR is sponsored by @ siemens (/cc @bufferoverflow @koffeinfrei).

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests added for this feature/bug
• Conform by the code review guidelines
  • Has been reviewed by a UX Designer
  • Has been reviewed by a Frontend maintainer
  • Has been reviewed by a Backend maintainer
  • Has been reviewed by a Database specialist
• Conform by the merge request performance guides
• Conform by the style guides
• If you have multiple commits, please combine them into a few logically organized commits by squashing them
• Internationalization required/considered
• End-to-end tests pass (package-and-qa manual pipeline job)

What are the relevant issue numbers?