Change Details

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 - (?) 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, auth.py has the necessary code (in this diff) to deal with the authentication we want). [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

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

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, auth.py has the necessary code (in this diff) to deal with thea new module swh-auth (T3079) reused most of what has been done for authat purpose. And thentication we want) 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