-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Add RBAC support to JupyterLab #11355
Comments
How does this proposal and PR fit together with the RBAC support implemented by JupyterHub team in 2.0 release (jupyterhub/jupyterhub#2245 and jupyterhub/jupyterhub#3438) and with the ongoing work in jupyter server in: jupyter-server/jupyter_server#165 and in jupyter-server/jupyter_server#540? Sorry if this is a trivial question, I would just like to understand the landscape a little bit more (and cross-reference the issues so we can navigate easily between projects). Is there a coordination activity/document so that someone who is not actively working in this domain could catch up? Thanks! |
Hey @krassowski! It is not a trivial question. It is the right one. |
Although this is tagged for Real-Time Collaboration, I did not move it to |
With the past changes in jupyter-server and JupyterHub is there any more work that needs to be done on JupyterLab side? |
Thinking out loud it could be useful to show that authorization layer of jupyter-server forbids certain actions. I think that we should not add authorization logic on the frontend side as it could be easily circumvented. This issue is not clear on the scope, nor specific addition to be made - input from the community is welcome. |
Problem
If we want to restrict actions to collaborators, we need to set different roles.
I'm already working on a PR to add a new package that represents the active user by introducing a new interface
IUser
, a new tokenICurrentUser
and an extension to implement a basic modelUser
that stores the user info in the browser. The interfaceIUser
has the attribute role defining four new roles ADMIN, READ, WRITE, RUN.For now, In #11180, I just added the attribute, but I'm not using it in any other place (I think we should open another PR to restrict the actions of a collaborator).
The main problem is that Jupiter Server doesn't have RBAC. For that reason, the new extension creates anonymous users with the role ADMIN. Every user can do any action.
Proposed Solution
Make core extensions depend on the new package user and limit the different actions by roles.
The text was updated successfully, but these errors were encountered: