Generating a ServiceX token

[bbockelm]

In the coffea-casa analysis facility at Nebraska, we auto-generate tokens for all the internal services upon login. That is, based on the login credentials, we generate an xrootd token (a macaroon) for accessing data and a HTCondor token (a JWT) for submitting jobs.

@oshadura noted that ServiceX asks folks to first authenticate against an IdP, then there's a separate manual authorization step to approve the user. That's not needed here -- we don't want a second user database for the facility.

So: is it possible to generate a JWT for ServiceX use directly? What's the signing key (is it kept as a secret in Kubernetes)? What are the claims that ServiceX looks for?

[bbockelm]

Looking through the code, it seems that the JWT_SECRET_KEY is used directly as the input for the JWT secret (e.g., there's no separate key generation). Further, it defaults to HS256.

Other relevant pieces:

• jti can be set and used from within the framework.
• type must be set to access
• The identity claim is set to identity instead of the standard sub.

[bbockelm]

Finally, on ServiceX side - it seems that the identity stored in the JWT is cross-referenced against the local database. So, if we want an externally-generated token to work then we would need to be able to conditionally disable this code.

[AndrewEckart]

Thanks for digging into this Brian.

Current implementation

To review, when auth: true is set in the ServiceX chart, then all API requests must supply a bearer token (access token) in the authorization header. The API server decodes this token via Flask-JWT-Extended's get_jwt_identity (as you noted, this looks for an "identity" claim rather than a "sub" claim, and then checks the PostgreSQL database included with ServiceX to make sure that the user exists and does not have a status of pending.

This leaves two questions:

1. How do users get into the database?
2. How does the client obtain access tokens?

The current solution to the first question is to have users go to the frontend, complete the OAuth flow manually and then save them to the database along with their sub.

The second question is answered by giving users a long-lived "ServiceX API token" which is a JWT refresh token with an identity claim that contains their sub. This is provided as a config value to the client which uses it to obtain access tokens as needed. In order to get their API token, users must have completed the OAuth flow (so their sub is stored in their session data). An API token is given to each new user on signup.

Coffea-casa use case

For your use case, we need to make several changes:

• Users should be able to skip the OAuth step entirely and still get an API token. The best way to do this is probably to generate the refresh tokens externally using the same secret, as you mention, rather than using the ServiceX frontend /api_token endpoint which relies on OAuth and session data.
• The auth_required decorator which guards ServiceX API endpoints should be updated as follows:

    @wraps(fn)
    def decorated(*args, **kwargs) -> Callable[..., Response]:
        if not current_app.config.get('ENABLE_AUTH'):
            return fn(*args, **kwargs)

        elif current_app.config.get('DISABLE_USER_MGMT'):
             return jwt_required(*args, **kwargs)

        return jwt_required(inner)(*args, **kwargs)

This adds a new config value called DISABLE_USER_MGMT. The inner function contains the code which checks against the ServiceX user database, so it would only run when this flag is not true.

• Presumably, you would still like to keep track of who submitted each transformation request. If so, SubmitTransformationRequest should be updated so that the submitted_by attribute is set to the OAuth sub returned by get_jwt_identity() instead of the user.id attribute on a user record retrieved from the database.

All of this seems doable. We should probably do a bit more, such as only registering the various user management endpoints when DISABLE_USER_MGMT is false, and making sure that everything is nicely decoupled.

[bbockelm]

Indeed - I can create the refresh token through an appropriate hook inside JupyterHub that runs as part of the JupyterLab spawning (and do this already for other required tokens).

I agree that something like DISABLE_USER_MGMT is exactly what we're looking for here.

I think if you implement what you write above, it'll be exactly what coffea-casa is looking for!