[Globus] Users with the same userid in different identity domains map to the same user

[rmoreas]

Bug description

When using the GlobusOAuthenticator without restricting the identity provider, users with the same userid at different
identity providers are mapped to the same JupyterHub user.

Expected behaviour

Users coming from different identity providers should be mapped to different users in JupyterHub.

Actual behaviour

Example: A user with a google account john.doe@gmail.com and another user with userid john.doe@institute.edu, will both be mapped to user john.doe in JupyterHub.

The relevant code is at

oauthenticator/oauthenticator/globus.py

Line 279 in 5837ca9

def get_username(self, user_data):

How to reproduce

Create a google account with the same userid as your institutional userid. For example, if your institutional identity is "u1234567@institute.edu", then create a Google account u1234567@google.com.

Log in with both accounts, both will have access to the same user u1234567 on JupyterHub.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[manics]

Have you tried setting c.GlobusOAuthenticator.username_from_email = True?
https://oauthenticator.readthedocs.io/en/latest/api/gen/oauthenticator.globus.html#oauthenticator.globus.GlobusOAuthenticator.username_from_email

[rmoreas]

I didn't, but I think this will not make much a difference because the email domain is also chopped to form the username which results in the same issue.

[NickolausDS]

I believe originally disabling the identity provider restriction altogether used to raise an exception and was not allowed, but was relaxed in favor of some use-cases where admins wanted to use multiple identity providers but take on the task of generating unique usernames themselves. However, these two things aren't mutually exclusive. If an admin disables the identity provider restriction, then get_username also needs to be overridden to ensure the uniqueness of users in JupyterHub.

A simple solution would be to update the OAuthenticator docs to warn admins about overriding get_username when disabling the identity provider restriction. Alternatively, the default get_username method could be changed to include the domain to preserve the uniqueness of the original identity provider. I think a problem with the latter approach is it violates the constraints of some alternative use-cases, such as re-using JupyterHub usernames as POSIX users on a local POSIX filesystem, where person@domain.edu contains both invalid characters and may also result in usernames which are too long. I'm curious what the Jupyter folks think of the latter approach, and if there are any other constraints where splitting the domain is preferable.