Pull groups from datahub into other hubs

[ryanlovett]

Bug description

The following hubs use GenericOAuthenticator, with configuration for bCourses:
astro, data8, ischool, publichealth, stat159, stat20

While these hubs use CanvasOAuthenticator:
biology, data100, data102, datahub, dlab, eecs, julia, prob140

A small number of other deployments use dummy, google, and lti auth.

The cookiecutter template is set to use generic as well.

When we enable groups within CanvasOauthenticator, the generic-based hubs will not receive this feature. I don't think there is any loss of functionality in moving all GenericOAuthenticator-based hubs (and the cookiecutter template) with login_service of bCourses to CanvasOAuthenticator.

Thoughts? My feeling is that if we do this, we should do it at least a couple weeks before Fall.

Environment & setup

• Hub: astro, data8, ischool, publichealth, stat159, stat20

Tasks to be done

Hub which needs to get moved to canvas auth

• Data 8 Hub
• Data 100 Hub
• Data 101 Hub
• Data 102 Hub
• Stat 102 Hub
• Stat 159 Hub
• Prob 140 Hub
• Public Health Hub
• Biology Hub
• EECS Hub
• Ischool Hub
• DLab Hub
• R Hub
• Julia Hub
• Shiny Hub
• CEE Hub
• Astro Hub
• High School Hub
• Workshop Hub

[ryanlovett]

The hubs that do use CanvasOAuthenticator are getting that viahub/values.yaml.

[yuvipanda]

@ryanlovett so if we move everything except datahub to genericoauthenticator, and provide groups in canvasoauthenticator, then all the hubs using genericoauthenticator can get list of groups from datahub!

[ryanlovett]

@yuvipanda and I slacked and he said that the idea was for datahub to be canvasoauth, the others genericoauth. The others could query the groups from datahub.berkeley.edu/hub/api/user presumably during spawning in order to do resource allocation.

I could confirm that using a token to GET /hub/api/user from my laptop does have the user's groups in the output.

Some questions for @yuvipanda :

• With this model, the other hubs could query groups in the spawner, but they still wouldn't have them in their ORM. Maybe that's not a problem initially, but will other hubs will eventually need to have groups?
• If a user logs into one of the other hubs and not datahub, do they even exist in datahub's orm? If not, they won't appear to be in any groups.
• Do we need to use service tokens instead of user tokens? I think a user's access token will work everywhere, so service tokens probably wouldn't be necessary.

[balajialg]

@ryanlovett Is this issue in scope for the August sprint? or it should be scoped in the backlog? Trying to move around the cards and identify the right spot mirroring its current status.

[ryanlovett]

@balajialg It could be. A lot of the work is done but I need to get @yuvipanda 's thoughts on the questions above.

[balajialg]

@ryanlovett Sounds good. Thanks!

[ryanlovett]

After chatting with @yuvipanda:

1. Make a PR to convert the following hubs to Generic: data100, data102, dlab, eecs, julia, prob140 (this is merged)
2. The generic hubs will use a custom generic oauthenticator (like a replicator) which will query datahub for groups. They will then add these groups in the downstream hub.
3. When users authenticate with the generic, they're also authenticating to datahub so they will exist in that ORM.

Edit: 2022-11-03: This is no longer the case. See below.

[shaneknapp]

reference for canvsoauth PR: jupyterhub/oauthenticator#406

[ryanlovett]

After today's meeting, it was suggested that it would be easier for most hubs to just use CanvasAuthenticator and not GenericOAuthenticator. So instead of the genericoauth hubs pulling group data from datahub, they will get it by virtue of using canvasauth. This greatly simplifies the configurations of all the non-datahub datahubs. The tradeoff is that the hub URLs must be entered into the Canvas (bCourses) configuration. @felder will make this happen in the short term (directly, or through the local Canvas lead). It may be possible to enable @shaneknapp to either request such changes in the future or make them directly as @felder is permitted.