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.
-
[2] https://github.com/marcospereirampj/django-rest-framework-keycloak
-
[5] swh/meta$961
Related to #2858 (closed)
Test Plan
tox
swh/meta$961
Migrated from D5137 (view on Phabricator)