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 aBootstrapApplicationRole
. - 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.