consideRatio
commented
1 year ago I understand it as we planned to phase out auth0 entirely, but that its considered to meet a need for a hub that wants to self manage users without an identity provider, by offloading the password management to Auth0.
Overall, I'd greatly value reduction of complexity to favor robustness and sustainable maintenance of the complexity we comitt to having. I understand it as even if we would isolate logic related to Auth0, that we would retain significant complexity.
Here are complexities I'm considering if we would retain Auth0:
- "There are currently limited options for limiting who can sign up" (from 2i2c docs) I believe community representatives would absolutely require an ability to limit who is authorized, so that an self-signup can't be used directly. If we don't already feel confident Auth0 can meet the needs of robust username/password management, its more work right away for us to investigate this.
- 2i2c <-> Auth0 We would need to manage accounts for all 2i2c engineers, retain the need to spread knowledge on how to work their UI etc even if we just use one small functionality from them. This becomes a long term maintenance commitment.
- 2i2c <-> Community representatives We would need to help community representatives learn how to manage users via Auth0 etc.
I think it makes sense for 2i2c to define a line that we only cross if sufficient motivation is mounted:
- 2i2c only supports CILogonOAuthenticator and GitHubOAuthenticator
- CILogonOAuthenticator can be coupled to various other identity providers
- Communities can suggest coupling to a specific identity provider via CILogon where they may have control of users themselves via username/passwords, perhaps Auth0, but the communities need to set that up themselves and not rely on 2i2c for it.
Tricky topic! I'd like to have a discussion about this in product and engineering I think, thinking that we could acquire insights about the value of supporting this vs leaving it to the communities to figure out themselves.
GeorgianaElena
damianavila
Context
The issue with Auth0 right now is that we are encoding Auth0 config in the deployer and we are relying too much on this non open source product.
Wondering if instead of removing it as proposed in https://github.com/2i2c-org/infrastructure/issues/1304, there's value in turning it into a deployer subcommand similar to the setup we have for CILogon.
One potential benefit of this one, is the username-password authentication option using Auth0's database connection (see point 3 of https://docs.2i2c.org/en/latest/admin/howto/manage-users.html#authentication) for which there's no clear easy alternative at the moment.
Proposal
Extract auth0 client creation into a deployer subcommand and add the Auth0OAuthenticator config manually instead of relying on the deployer to do it (same with what we're doing for CILogon). We would only use this rarely when explicitely requested or when we have no alternatives and not as a default like it it right now.
Updates and actions
No response