-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to z2jh 3.1.0 with oauthenticator 16.1 #3144
Upgrade to z2jh 3.1.0 with oauthenticator 16.1 #3144
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
73cadc3
to
b948b13
Compare
@ckrzysik @lheagy @hmodzelewski could one of you make a quick verification that you have access to https://staging.ubc-eoas.2i2c.cloud by logging in (if needed logout first) and reply if it worked out or not? |
This worked for me! |
This change is expected to rolled out 2023-10-04. I'm planning on sending the following email to our hub champions for their information:
We don't expect any issues but we are using this PR to iterate on how we notify our hub communities of changes that may impact them. Depending on how this goes, I'll make a correspond change in the Team Compass for a procedure to adopt in these cases. Update: Email sent. See https://2i2c.freshdesk.com/a/tickets/101 |
The default scope in oauthenticator 16 includes what we need. Let's rely on the default for simplicity.
In oauthenticator 16 its possible to allow a github organization/team and separately allow individual users. Instead of the intersection of allowed_users and users allowed via allowed_organization, oauthenticator 16 allows the union of these users. This makes this validation check no longer relevant.
79414b3
to
25d52b7
Compare
I rebased and force pushed to ensure this PR is easier to revert if needed, and I caught one config mistake for a cloudbank hub thanks to the second review, as fixed via 25d52b7. With nasa-ghg and nasa-veda credentials refreshed, this is good to go I think. I'm going for a merge once tests pass. |
🎉🎉🎉🎉 Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/6404219319 |
Summary
This PR updates from our use of z2jh 3.0.0-beta.1 (where we manually had upgraded KubeSpawner) to z2jh 3.1.0, and with it we get oauthenticator 16.1.0, up from 15.1.0. With this, we have significant amount of changes to review manually as the authentication configuration is not something we test automatically (its very hard).
Pre-merge review
I checked with two utoronto accounts
Asked representatives in Upgrade to z2jh 3.1.0 with oauthenticator 16.1 #3144 (comment)
I checked with
consideratio-demo
, first not getting access, then addig that user and getting access, then deleting the user and no longer having access. This was the intented behavior.I performed a check like for openscapes
I performed a check like for openscapes
I checked with community admin via Cloudbank followup to review auth config #3196
I performed a check like for openscapes
I performed a check that a google user from a unknown domain wasn't allowed, and one from an allowed domain was. I also checked that I could authenticate with a microsoft account, but could only check I got denied as I had no allowed microsoft account.
Help on how to review
These are key changes in OAuthenticator 16 to be aware about:
OAuthenticator.allow_all
andCILogonOAuthenticator.allowed_idps[].allow_all
is new config that needs to be explicitly set to True if all authenticated users by the authenticator or specific CILogon identity provider are to be authorized. Previously all users could be authorized automatically if no config existed to indicate only some should be authorized access.OAuthenticator.allow_existing_users
is introduced to explicitly toggle a behavior that previousy was decided based on ifAuthenticator.allowed_users
was declared or not. In v15 whenallowed_users
was set, any user in JupyterHub's user database (as updatable via /hub/admin panel) was allowed access as well. In v16, this needs to be explicitly configured via the new config option.allowed_users
that together withGitHubOAuthenticator.allowed_organizations
required authenticated users to be part of both the list ofallowed_user
andalowed_organizations
. That led to us never configuring both, only one or the other. In v16 a user can be authorized by being part of either.Reference links
Related