Change jupyter authorization header to bearer-token

[bigglesandginger]

Currently the jupyter library uses a hardcoded key as the layer of security which is flawed in a few ways (a single key for all users, the key has a very long lifetime, ie months). Instead it would be nice to use the Keycloak Bearer Token instead.

The easiest method for the hmi-client to provide the Bearer-Token would be to simply alter the existing jupyter token, thus instead of Authorization: token <jupyter-token> the request would provide Authorization: token <bearer-token>. This would allow us to not modify the jupyter client library making it easier to keep the library updated if needed.

This would additionally allow beaker to perform simple tasks like getting the user's details (like name and id), but additionally could check to see if the bearer-token was valid, and maybe even grant certain capabilities based on groups if desired (admin page viewable by only admins - that sort of idea).

[mattprintz]

@bigglesandginger

What is the preferred way for the header to be used? I'm assuming we want to pass the auth header to calls to hmi-server unchanged, but not for calls to, say, S3. Is there a list of domains/services that expect this bearer token?

Also, are you able to confirm if/what is provided to the beaker dev interface from keycloak? Will it be the same, or different somehow?
Obviously fine if the beaker dev interface requires keycloak login, but don't want to make changes that would prevent it from being used at all.

[bigglesandginger]

For the first pass I think beaker should be able to inspect the bearer token for the user id and then be able to segment on the admin UI that way (for fun and profit).

Next we could figure out how to have beaker test the bearer token against keycloak (ask keycloak is this a valid bearer token). I worry that this might require a Keycloak configuration change, I will need to test this.

As for beaker talking to the hmi-server, it should continue to use the api-service info it is given (AUTH_USERNAME, AUTH_PASSWORD)

[mattprintz]

@bigglesandginger What would it take to move http://beaker.terarium.ai/ behind keycloak, but at the same time maybe not proxy 'ws://beaker.terarium.ai/' if keycloak interferes with the websocktet?

It would be best if the two ways of interfacing with Beaker, through the dev interface above and through the workbench, had the same auth mechanism.

[bigglesandginger]

There are two things to make that path happen. 1) I would need to resurrect the apache httpd layer that we used to have (it is a big task but should work, it did in the past), 2) deal with the issue that there can be only one Authentication header - ideally apache httpd could replace the bearer token with the jupyter token but this is untested capability.

[mattprintz]

If we did make this happen, I think point 2 would be moot because the whole idea is to have jupyter/beaker just use keycloak header.

Right now, as far as I can tell, the beaker dev interface and the beaker admin page don't get any keycloak headers, unless they are being added/hidden from me. Without the keycloak headers, I don't know what we can do limit replace the jupyter token. If there are headers available, even if separate from the auth header, we should be able to use those for authentication/authorization.

[bigglesandginger]

Are you suggesting (if possible), I add a new Header (say BearerToken) and provide the keycloak bearer token for beaker to check against? That way the jupyter library does not need to be monkeyed with and beaker can get the user info it desires

[mattprintz]

No, I'm trying to figure out what Keycloak provides to Beaker so that Beaker can use whatever is available to check against.