feat(vcs): support for new VCS integration

[palkerecsenyi]

Closes #552

---

• The new OAuth remote for GitLab will use the same system as all other remotes (i.e. being registered via invenio-oauthclient). This will allow us to plug in custom handlers at various points. Notably, we can override the GitLab-specific account_info_serializer function and perform our own validation on the raw userinfo object, even before it gets turned into the generic object with significantly less information.

• GitLab returns an identities field in the userinfo, containing a list of external authentication providers the user has linked to their account, and the ID each provider uses to represent the user.

  For example:

  {
      "id": 1234,
      "username": "johnsmith",
      "identities": [
          {
              "provider": "openid_connect",
              "extern_uid": "johnsmith",
              "saml_provider_id": null,
          },
          {
              "provider": "ldapmain",
              "extern_uid": "cn=johnsmith,ou=users,ou=organic units,dc=cern,dc=ch",
              "saml_provider_id": null,
          },
          {
              "provider": "kerberos",
              "extern_uid": "[email protected]",
              "saml_provider_id": null,
          },
      ],
      ...
  }

  In this case, we can see the GitLab user johnsmith has a CERN username of johnsmith. It is possible for the GitLab username to be different to the CERN username, so we cannot simply rely on the GitLab username.

• We already store the user's CERN username in the database as part of the extra_data field for the CERN/keycloak RemoteAccount. We just have to look this up (based on the OAuth client ID of the CERN remote app) and compare the two values.

• This way, we ensure the user has logged in with the GitLab account associated with the same CERN account as their CDS account, which avoids some security issues and bugs.

• The function gitlab_account_info_serializer overrides the account_info_serializer (but still makes a call to the original once validation has passed). This override can be enabled in invenio.cfg which I will also update soon.

Error handling

Right now, the error handling means a 500 Internal Server Error is returned when there's a mismatch between the user IDs. This could be an acceptable outcome, since such behaviour is not likely to happen without careful and deliberate interference with the authentication process. The following error is logged on the backend:

cds_rdm.errors.KeycloakGitLabMismatchError: GitLab user 1234 has a different CERN SSO identity (cdsgltest) to currently signed-in CDS user 1 (pkerecse)

Since we don't have direct control of the view handler (that's in invenio-oauthclient) it's a little tricky to customise the error that's returned to the end user.

Testing

Running this locally is a little complicated due to the need to connect to various services.

Here's what you need:

• A CERN-internal or public URL to access your instance. You can always use hostname.cern.ch internally but you'll need a CA certificate from https://ca.cern.ch/ca/ ("New CERN Host certificate"). Make sure to set this URL in all the relevant places in invenio.cfg
• CERN GitLab OAuth credentials (gitlab-dev.cern.ch)
  • You'll need to contact the Git service via SNOW, see Create dev GitLab OAuth credentials #534
• Public GitHub OAuth credentials (https://github.com/settings/applications/new) if you want to test the GitHub integration
• CERN SSO OIDC credentials from https://application-portal-qa.web.cern.ch/. You might need to contact the SSO Service via SNOW if you don't already have access to this.