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
What works :
- 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)
- 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   .
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  we want to
use ( source code seems to be able to support it though). They are not packaged for
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 T2858