Skip to content

Migrate deposit to use keycloak as authentication mechanism

This reworks the internal authentication mechanism to delegate that part to keycloak. Through a Direct Grant access.

It's transparent for the deposit clients. They will continue their authentication against the deposit server. Internally, the deposit server will require authentication on their behalf.

What works [5]:

  • tryouts from within docker (user hal/test):
    • rejects unknown user or invalid creds
    • service document is served with the right creds
    • metadata-only deposit...
  • actual (manual) deposit tests are ok (curl on servicedocument url, metadata-only deposit, status, ... )
  • use cache to avoid authentication at each http connection (cf. django cache mechanism)
  • leverage keycloak scope to allow keycloak user with the right "swh.deposit.api" permission (decrypt token and read role there to authorize/reject authenticated user)
  • adapt user django model to permission (-> swh.auth)

Remains to:

  • Installs actual users (with their password) to keycloak (either manual or script)
  • update docs
  • split this one diff into multiple ones or squash all incremental commits into one (incremental code got rewritten anyway and pushed into swh-auth).
  • (?) adapt the deposit admin cli so it creates user in keycloak

Note that I checked other python modules [1] [2] [3].

They seem to have little movement (for some, last actions dates back at best 2 years ago). They don't entertain in their documentation the authentication scheme [4] we want to use ([1] source code seems to be able to support it though). They are not packaged for debian.

So in the end, a new module swh-auth (T3079) reused most of what has been done for that purpose. And then slightly adapted (incrementally) to allow the Direct Grant flow for the deposit.

Related to #2858 (closed)

Test Plan



Migrated from D5137 (view on Phabricator)

Merge request reports