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.
[1] https://github.com/Peter-Slump/django-keycloak
[2] https://github.com/marcospereirampj/django-rest-framework-keycloak
[3] https://github.com/marcelo225/django-keycloak-auth
[4] https://tools.ietf.org/html/rfc6749#section-4.3
[5] P964
Related to T2858