Add authentication fallback mechanism for users without an active token

[pmeulen]

Add an authentication fallback mechanism for users without an active token in Stepup when they use the Second Factor Only authentication flow (SFO flow).

Openconext-engineblock sends one or more user attributes in a custiom SAML extension: OpenConext/OpenConext-engineblock#1826 in the AuthnRequest to the Stepup-gateway.

When:

1. a user authenticates using the SFO flow
2. AND the user does not have an active token
3. AND a LoA1.5 (i.e. self asserted) authentication is requested
4. AND a fallback GSSP is configured
5. AND this "fallback" option is enabled for the institution that the user belongs to.
6. AND the configured user attribute is present in the AuthnRequest
   THEN handle authentication by forwarding it to a designated GSSP using the GSSP protocol instead of returning an error.

Do all the normal checks on the AuthnRequest from engine that are part of the SFO flow before starting the fallback e.g. check the AuthnRequest's signature, verify that the Subject in the AuthnRequest of the configued second_factor_only_nameid_patterns.

If the fallback authentication fails, handle this in the same way as for a normal GSSP authentication. E.g. it could be because the user cancelled the authentication, because the GSSP returned a SAML error response or because something was wrong in the SAML response.

The gateway must check that the Subject in the SAML Response from the fallback GSSP matches the Subject that it set in the SAML AuthnRequest to the fallback GSSP.

The gateway needs the institution identifier (i.e. the schacHomeOrganization) to check that the fallback GSSP is enabled for the user's institution. This configuration is read from the database. The gateway schema already has a institution_configuration table for enabling/disabling SSO per institution. Add a fallback_gssp_enabled column to this table.

Discuss:

• How to get the institution identifier when doing the fallback?
  • How is this currently done in the Stepup-gateway?
  • Parse it from the Subject NameID? (hackish, assumes the urn:collab:person:: is used)
  • Because the name_id does not exists in the second_factor table (because the user has no active tokens) we cannot read the user's institution from this table.
  • We could let engineblock send the institution identifier along, and add configuration option for the user attribute to use for this purpose.

[pablothedude]

#447