-
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
Move openscapes hub to GitHub Auth with Teams #1222
Comments
What I did
ConclusionRemoving a user from a GitHub Team does remove their access to a JupyterHub, but not necessarily immediately. The user needs to logout of the hub and so they will retain access to the hub until they logout/an admin revokes all tokens from the OAuth app/a token expires. Two courses of action to ensure this period of access after removal from the GitHub Team doesn't remain are:
1 is probably ok short-term, but slightly annoying from a UX POV. We should do 2 for longer-term sustainability. cc: @yuvipanda |
@sgibson91 I think deleting the user from the hub admin interface also logs them out explicitly - so we can document that as the thing for people to do when they remove them from a GitHub team? |
I think if do that, that means that admins have to remove a user from both the GitHub Team and the JupyterHub admin panel, which seems to be adding complexity rather than simplifying the process as originally requested quoted above? |
@sgibson91 ah, true. But that seems better than making everyone log in each time they want to start a server no? Or we could use this as a way to prioritize adding refresh_user functionality for GitHubOAuthenticator, and hold off until that lands. |
This would be my preferred long-term solution as I think most hub admins would prefer to only need to carry out admin tasks in one place, whether that's the admin panel or GitHub Teams interface. I already had a chat with Min in Gitter and I'm happy to put some cycles into the upstream work providing I have some guidance (I've not worked with the OAuthenticators before!) |
(while this looks like I'm doing work on my day off, I'm actually comatose in a hotel after eating a lot of delicious Indian food 😋) |
@sgibson91 yeah, I think doing this in OAuthenticator is the 'right' way to do it, and I think we should prioritize that now. Especially with auth / security stuff, doing it the right way is probably going to save us headaches in the long and short term. |
cc: @damianavila FYI for planning purposes: the above will likely become a project for me since I don't know anything about the OAuthenticator and it'll likely not be something I can complete quickly. |
I do agree with both of you about prioritizing the upstream work. Users will be mad if we force them to log in each time. |
@yuvipanda asked me if he could take over the upstream oauthenticator work for this issue and I agreed since I am quite swamped by admin stuff atm |
Can somebody clarify what our next steps are here? In this comment it seems like there are two things proposed, a short-term thing and a long-term thing. Can we update the top comment with the steps that need to be taken to close this issue, and if there's a long-term thing we can open a new issue about it? |
I think we could just enable GitHub Auth on the openscapes hub for now and tackle refresh_user separately? I'd be interested in @yuvipanda's estimation of time/work for implementing refresh_user and then @GeorgianaElena agreed to help me with this if no one else can take the lead. |
Since I'm currently blocked waiting for more info about the Callysto hub I spent a bit of today documenting about the upstream side of this task, i.e. implementing So, I was planning to self-assign this and come up with an initial implementation for the upstream issue or at least a plan to push this forward hopefully tomorrow. A short summary of the current upstream stateThere is support for P.S. I've updated the top comment with the main two sub-tasks remaining of this issue. |
Thanks for taking the lead on this one, @GeorgianaElena! |
Thanks a lot for taking this on, @GeorgianaElena! |
Currently blocked on jupyterhub/oauthenticator#526 :( |
We briefly discussed in the sprint meeting the problem of "visibilizing" what we do upstream since @GeorgianaElena is doing a lot of work upstream of us. |
Pause for now waiting for feedback from the upstream team. |
Closing in favor of #3240 which is much more tightly scoped |
Context
We currently use auth0 for the Openscapes hub, and the admins have to manage users manually. In #1213, @erinmr asked for features to make that process easier. One way to do that is to just switch to GitHub auth and provide access via teams - so admins can manage access outside of the JupyterHub!
Proposal
Updates and actions
The text was updated successfully, but these errors were encountered: