SSO Proxy LoA5

With setting SSO Proxy, LoA 5 must be set in order to deny access from non-CERN accounts.

On a technical level, the current SSO Proxy leverages the same OIDC credentials of the application layer to set the SSO flow. This means that it sets the same LoA that is set for the Drupal application, as well any uses all other set configurations (Redirect URI, etc.). This means, we have to update an element in order to have the SSO Proxy with LoA5 without necessarily affecting all Drupal instances within the same namespace from having LoA5 enforced.

Possible approaches and consequences:

• Setting a new required role with LoA5

  Pro: it is fully set as expected for all the instances with SSO Proxy on the namespace
  Con: it will be enforced on applications of the same namespace which we don't want to have it set, example: primary instance would require LoA5 to login on the Drupal itself

• New OIDC registration

  Not viable, as in the end it will share the same roles as the other(s) OIDC registrations for the same application

• Creating a new ApplicationRegistration on the same namespace

  Not viable, as the AuthzOperator works with the expectation of just one ApplicationRegistration per namespace

• One shared SSO credential for all deployments, where the LoA5 is required

  Pro: easy to update settings for all proxies from one endpoint
  Con: Unknown if viable, Auth side might not support/handle a great number of OIDC Return URIs, or OIDC registrations, TBS with their end and validate

Update

After discussing with Vincent(IAM), he suggested having on the SSO layer an enforcement of a role on the SSO-Proxy layer. This was already tested and validated as a viable solution (and preferred one).

Requirements in order to fit this model:

• Use the role cern_registered as it matches uniquely LoA5, and is guaranteed on new projects through the template and creation with a BootstrapApplicationRole.
• New variables on the deployment to have this role as required

We do not enforce BootstrapApplicationRole so users could, if aware of this behavior, remove such roles and have the action reverted. TBD how we can fully enforce on the Portal side.