Server auth for on-premise setup and client authorization

[aldanor]

For a sealed-off on-premise setup, github auth is almost surely out of question, are there any plans to provide something like LDAP or another authentication method?

Another use case where conda is also lacking is having multiple on-premise channels with different permission configurations. E.g., there's teams 1, 2, 3, all of them have access to channel A, only teams 1 and 2 have access to channel B, and teams 2 and 3 have access to channel 3. I believe this would be the most common enterprise setup if you're running a single server instance. You could run multiple instances and manage it at the network layer but then it becomes harder to manage, upgrade etc as you end up with a bajillion of servers. I don't have an exact suggestion but maybe that's something you've considered?

Thanks for great work 👍

[wolfv]

Hi @aldanor thanks for opening an issue.

yeah, indeed we would like to support pluggable authentication methods similar to how JupyterHub works. In the future one should be able to configure any kind of auth method.

Yes, we currently have per-channel and per-package permissions but we definitely need to refine all of this further.

[tom--pollard]

@wolfv Do you think there'd be any benefit right now of providing another oauth2 endpoint, as to provide a base for further configurable auth methods. Maybe gitlabs openid etc? If so I could take a look at a simple implementation to match the github integration.

[wolfv]

yeah I definitely think so. Google OAuth could also be interesting as many people & devs are using it. And bitbucket?

We could also take a https://github.com/jupyterhub/oauthenticator and maybe re-use it?

[wolfv]

ok that seems to depend on jupyterhub so maybe not ideal.

[SylvainCorlay]

Oauth2 is already quite specific. I think that we want a generic base authenticator that we could specialize for e.g.

• PAM (using the unix credentials of the server)
• OAuth2
• LTI
• LDAP

etc.

[tom--pollard]

FWIW I've currently got a WIP ready for adding google oauth2 (specifically OpenID Connect) as an optional auth endpoint. This will also potentially have the basis for decoupling any cross module assumptions on the auth provider.

[wolfv]

cool @tom--pollard ! Looking forward to that

[beenje]

To add more oauth providers support, loginpass could maybe be used?
They recently added support for FastAPI: authlib/loginpass#73

Is it something worth investigating?

[wolfv]

Yes, I think that would be worth investigating!

[btel]

we have now support for the following authentication methods:

• PAM,
• Oauth2 (based on authlib)
  • github
  • google
  • jupyterhub

the system is quite extensible, so other authentication methods can be easily added (with API inspired by jupyterhub authenticators).

see more in docs:
https://quetz.readthedocs.io/en/latest/deploying/authenticators.html