You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At time of writing, we must directly associate JupyterHub users with JupyterHub roles to support RBAC. Those roles are then associated with JupyterHub services (ie OAuth2 clients) to grant users authenticated access to the applications' underlying services (see JupyterHub RBAC - Roles: Defining Roles).
This is a bit of an onerous task and won't scale well for systems with large user bases. Instead, a more elegant solution would be to grant groups access to the JupyterHub Applications. Ideally, users would then be automatically assigned to groups based on information associated with their identity as specified by the identity provider (ie GitHub, perhaps this could be based on membership of a GitHub group?) I'm admittedly not sure as to what the capabilities are for this within JupyterHub. For reference, Grafana has a nice system allowing the use of JMES expressions to assign users to groups upon login (docs).
The text was updated successfully, but these errors were encountered:
Users who login get automatically added to some default group / groups
I would think that automatically adding users to a default group should have been easy, but asking ChatGPT how to do that tells me something like this:
Automatically Add Users to a Group:
JupyterHub supports automatic group assignment, but this might require custom scripting.
You can write a custom pre-spawn hook or use a custom Authenticator class to add users to a group. This is an example of how to add users to a group:
def add_user_to_group_hook(spawner):
user = spawner.user
group_name = 'your-group-name'
if group_name not in spawner.user.groups:
spawner.user.groups.append(group_name)
# Here, you can also integrate with JupyterHub's internal database to save the group information.
c.Spawner.pre_spawn_hook = add_user_to_group_hook
This seems a bit overly complicated to me - am going to try and find out if there's an easier / recommended way to automatically add users to groups and then we should just be able to assign the scopes to groups, @alukach ?
@alukach it seems like there is some discussion and work happening upstream around this issue of making it easier to configure user groups and permissions without needing to edit config: jupyterhub/jupyterhub#3858 .
Though I also think it's reasonable to do some kind of hack to make this "adding scopes to groups" and "automatically adding users to groups" to work, otherwise this authentication mechanism does get onerous.
Is there a better place to ticket this? Am just worried that this repo is going to be focussed on the eoapi-risk work and this authentication related ticket may get lost.
Feel free to leave open here ofc - just not sure if we're going to be able to prioritize this - of course, feel free to make changes and use this jupyterhub instance to test (just leave it alone between Feb 5-8 :D )
At time of writing, we must directly associate JupyterHub users with JupyterHub roles to support RBAC. Those roles are then associated with JupyterHub services (ie OAuth2 clients) to grant users authenticated access to the applications' underlying services (see JupyterHub RBAC - Roles: Defining Roles).
eoapi-risk/deploy/helm/jupyterhub/values.yaml
Lines 70 to 78 in b3912f5
This is a bit of an onerous task and won't scale well for systems with large user bases. Instead, a more elegant solution would be to grant groups access to the JupyterHub Applications. Ideally, users would then be automatically assigned to groups based on information associated with their identity as specified by the identity provider (ie GitHub, perhaps this could be based on membership of a GitHub group?) I'm admittedly not sure as to what the capabilities are for this within JupyterHub. For reference, Grafana has a nice system allowing the use of JMES expressions to assign users to groups upon login (docs).
The text was updated successfully, but these errors were encountered: