Allow cluster admins to opt-out of ServiceX user management system

[AndrewEckart]

As discussed in ssl-hep/ServiceX#217 with @bbockelm, clusters / analysis facilities with their own authentication system may wish to opt-out of the authentication system which is currently built into ServiceX (OAuth via Globus + user table in PSQL database).

This PR facilitates this use case by adding a new config value called DISABLE_USER_MGMT. When toggled, the authentication decorators will only check for a valid JWT - they will not check against the database to make sure the user exists, is not pending, is an admin, etc.

If this flag is used, cluster admins must generate JWT refresh tokens using the same JWT_SECRET_KEY and provide them to end users in some other way. ServiceX will still expect all API requests to protected endpoints to carry a JWT access token, which is obtained by the Python client in the same fashion as usual using the refresh token.

This flag renders many other config values associated with the user management system irrelevant (those for Slack, Globus, Mailgun, etc.) as well as their related endpoints. It does nothing if ENABLE_AUTH is set to False, in which case there is no user management system, internal or external.

[AndrewEckart]

One bump in the road: the TransformationRequest.submitted_by column expects an integer (we've been storing the autoincrementing user IDs issued by the PSQL db). It would be more flexible to store a string, so that external authentication systems can pass an OAuth sub as the identity claim. Unfortunately, that would require a db migration and some other changes to the app (e.g. the GET /servicex/transformation?submitted_by=... request should query for requests submitted by a given sub, rather than a given user ID).

@bbockelm - for Coffea casa, do users have unique integer IDs that could be passed as the identity claim? Or do they only have a sub?

EDIT: Nevermind, I think this will be fairly tricky, since the submitted_by column requires the value to be a foreign key in the users table anyway. Unfortunately, I think this means that DISABLE_USER_MGMT requires giving up this feature. We could probably add a memo field or something similar on transformation requests to support this in the future. I suppose we could alternately remove the foreign key constraint.

[codecov]

Codecov Report

Merging #73 (217156e) into develop (b8e8da7) will increase coverage by 0.85%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop      #73      +/-   ##
===========================================
+ Coverage    91.04%   91.90%   +0.85%     
===========================================
  Files           49       49              
  Lines         1329     1371      +42     
  Branches       108      117       +9     
===========================================
+ Hits          1210     1260      +50     
+ Misses         106       98       -8     
  Partials        13       13              

Impacted Files	Coverage Δ
servicex/decorators.py	100.00% <100.00%> (ø)
servicex/resources/servicex_resource.py	100.00% <100.00%> (ø)
servicex/resources/users/token_refresh.py	100.00% <100.00%> (+61.53%)	⬆️
servicex/transformer_manager.py	96.72% <0.00%> (+1.26%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8e8da7...217156e. Read the comment docs.

[AndrewEckart]

This is ready; we now have full test coverage and I've added some more instructions on how to generate the tokens. I've also tested manually with refresh tokens generated externally using the jwt.io debugger with the HS256 algorithm and our default JWT_SECRET_KEY (both in plaintext and base64-encoded).

[oshadura]

@AndrewEckart if you want I can quickly deploy it in dev namespace in flux?

[oshadura]

Do you have somewhere pushed image I should use?

[AndrewEckart]

@AndrewEckart if you want I can quickly deploy it in dev namespace in flux?

Yes please! Keep in mind that you'll need the disable-user-mgmt branch of the Helm chart as well, which is not published to our chart repo. Will you still be able to do it with Flux?

[oshadura]

Ah, since we deploying servicex from chart repo (as a dependency of coffea-casa), it will be hard...
cc: @jthiltges

[BenGalewsky]

What is the status of this? Is @oshadura using it on coffea-casa?

[oshadura]

@BenGalewsky I will try to retest it ASAP, thanks for reminder!