Investigate using CILogon instead of Auth0

[GeorgianaElena]

As part of #315, we decided to Investigate a deeper integration with CILogon - to replace our current Auth0 setup.

Current setup:

CILogon is configured as an Auth0 social connection as described here and then registered as a CILogon client. This means, that for any 2i2c hubs that enable login through CILogon (like the 2i2c demo hub) the authentication flow is:

Hub login page ➡️ Auth0 Login screen presenting the CILogon option ➡️ CILogon IDP selection page ➡️ IDP login page ➡️ hub access

Context

Jim from the CILogon project suggested that it would be possible to use a paid CILogin API to automate client creation. We would require a 12.5k USD/year subscription for access to this API. This also comes with other features described here https://www.cilogon.org/subscribe. Docs about the API here https://cilogon.github.io/oa4mp/server/manuals/dynamic-client-registration.html.

Would using CILogon instead of Auth0 simplify our login process + make it more flexible?

• CILogon is a very cool project and is generally more aligned with 2i2c mission and needs (focused on research and academia , while Auth0 is more enterprise oriented and logging in through social connections)
• We won't need to maintain both Auth0 setup and subscription and the CILogon one (GitHub & Google auth can be achieved through CILogon)
• We can use the JupyterHub CILogon oauthenticator, so we we'd be able to specify list of allowed idps instead of using username_pattern to provide authentication by a given domain.
  HOWEVER
• The cheapest CILogon subscription that allows automating client creation seems expensive (probably also because we dont yet need all the cool features the come with the subscription)
• We would need to change the current infra for creating OAuth2 Clients from auth.py - that uses the Auth0 API to using the CILogon REST API.

Does CILogon have all of the same features that Auth0 does? What are the differences?

If we buy the subscription and gain access to the REST API that enables us to create dynamic client registrations, then that will enable us to replace our current Auth0 setup ➡️ from the perspective of 2i2c needs, yes, CILogon has the same features of Auth0

The differences:

• CILogon offers around 4000 identity providers (GitHub & Google included), but doesn't support all the social connections of Auth0 (Facebook, Twitter, etc) - (apart from GitHub and Google we weren't using the others anyway)
• Costs ➡️ we are currently paying 23$/month for our Auth0 subscription, while the CILogon one is 12.5k/yr (with the dynamic client creation).

CILogon costs ~$13,000 a year, is that worth the value we'd get?

Auth0 costs us 23$/month -> 276/yr (the essential plan). There is also a Business plan of 240$/m -> 2880/yr and an Enterprise one but the price is available on request only.

The Auth0 Enterprise subscription seems to be offering what the essential CILogon subscription does (Auth0 Enterprise (SAML, Open ID Connect, Google Workspace, Microsoft Azure AD, ADFS, Active Directory / LDAP, Ping Federate)), which makes me thing that might be similar in price with the CILogon one. So the value we'd get for this amount of money might be similar for both Auth0 and CILogon.

However, since we don't need all of these features right now, my impression is that the switch to CILogon paid subscription might not yet make sense.

To Do

• Discuss with CILogon team if we can get API access without an annual subscription yet
• Get an API key from CILogon
• Prototype a deeper CILogon authentication using their API key -> Full Cilogon integration #1089
• Deploy this authenticator with the ANU hub -> Migrate the ANU hub to use the JupyterHub CILogonOAuthenticator #1174
• Fix a security issue upstream -> https://github.com/2i2c-org/meta/issues/317
• Open a new issue that will track the longer-term question of replacing Auth0. -> Simplify our authentication workflow by migrating all communities to CILogon authenticator and away from Auth0 #1304

[damianavila]

Wondering if is there any place to explain CILogon who we are and that fact we are going to use JUST the dynamic subscription and ask for a cheaper price?

[damianavila]

Another question... is the CILogon bias towards academia maybe some limiting factor for interaction with future communities?

[GeorgianaElena]

Wondering if is there any place to explain CILogon who we are and that fact we are going to use JUST the dynamic subscription and ask for a cheaper price?

Maybe we could follow-up with them via the freshdesk ticket that we have open? They seemed pretty open to questions. Though, I don't know a lot about their business model (and business in general as a matter of fact) so I'm not sure what is and is not possible from this point of view. Wondering if @choldgraf has time to help out with this?

Another question... is the CILogon bias towards academia maybe some limiting factor for interaction with future communities?

I don't think so, most of 2i2c hubs are too, right?

[choldgraf]

That sounds good @GeorgianaElena - I am happy to try and connect with them. I'll respond to their email and maybe we can set up a meeting? Would you (@GeorgianaElena) be able to join? Do you think others on the team should join?

[choldgraf]

Update: we're planning to meet

I sent them an email asking if they could meet and discuss potential "trial periods" for using their API, and mentioned that we like the idea of working with an organization that is so mission-aligned. They were quite receptive, and we're going to set up a time to meet when I'm back from vacation next week!

If anybody would like to join this meeting, please let me know and I'm happy to include you (maybe @GeorgianaElena since she is our resident CILogon expert? :-) )

[choldgraf]

Update from meeting

I had a meeting with Jim from CILogon today, here are some notes from the meeting! There were three main things that we discussed, each below:

Token to try CILogon

• They are happy to provide us an API token to try out their service for free
• They will send us a form to fill out and then get us the token afterward.
• In general, they just want to know that there is a pathway to us paying for an annual fee if we want to after trying it out. I told them that if it made sense we'd be happy to pay a fee, just need time to determine if the service was useful in the way we need it.
• They are also a non-profit trying to figure out a sustainable service model, so are eager to work with us and learn from one another
• They also said they'd be happy to chat with us if there are features/functionality we need in CILogon - many orgs use JupyterHub but they provide very little feedback, if we'd be willing to do so this would help them a lot.

There were also a few Jupyter-specific projects they were interested in working on, and wanted to know if we'd be interested in collaborating etc:

Token management inside of JupyterHub

• Would be interested in collaborating with us around how to pass more authorization tokens inside of a JupyterHub / session
• SciAuth.org is where they worked on this in the past

cc @yuvipanda - I feel like we have discussed this one before as well right?

TrustedCI and Jupyter security

• They are interested in making improvements in security for Jupyter / JupyterHub
• https://www.trustedci.org/ is another org they're involved with. here's a blog post they recently published

Next steps

• They will send us a form to fill out: they've sent instructions here: https://2i2c.freshdesk.com/a/tickets/88
• We fill it out and save the generated credentials
• Client credentials are approved
• We use those credentials to prototype a deeper CILogon integration
• Decide what to do from there

[choldgraf]

Update

I spoke with @GeorgianaElena about this recently, and we decided that it'd be a good use of her time to investigate this deeper integration with CILogon as an extension of #65. Since she has the CILogon context in mind already, we should avoid the context penalty that would come with trying this later on.

@GeorgianaElena could you describe a rough plan of what you're going to try doing? I think we should all align on the major questions that we need to answer in order to make a decision about whether to use their API key.

[GeorgianaElena]

Overview of current state of things

The current 2i2c Auth0 client management happens in https://github.com/2i2c-org/infrastructure/blob/master/deployer/auth.py, which is based on auth0 python integration lib which is a wrapper of their REST api.

For CILogon on the other hand, we have a bunch of bash scripts that exemplify how to use the REST api.

Technical plan

I was thinking we could:

• write a CILogonAdmin class that wraps their REST api and knows how to create/update/delete clients
• abstract KeyProvider into an interface (formally or informally, based on what design decisions we wish to make) and create a CILogon specific KeyProvide
• have the staging hub use the JupyterHub CILogonOAuthenticator
• use the CILogon KeyProvider to create/update the CILogon OAuth2 client for the staging hub

Switching decision questions

After we have implemented the technical part above, this would mean that we could completely change our auth infra to use CILogon instead of Auth0. Why should we change it, boxes to check:

• CILogon mission is aligned with ours and our communities can help each other (I beleive this one is aleardy checked)
• it doesn't break any existing functionality
• there is desire from communities to use identity providers other than Google/GitHub and these are supported by CILogon
• we can afford it in the longer term
• todo: think about what other decision points we could analyze

[consideRatio]

2i2c team meeting notes:

• A challenge for a transition to use CILogon more would be that there isn't a python client to interact with the CILogin's REST API as there is with Auth0.
  • Should we make a CILogin API wrapper?
• Next steps: clarify value outcomes of switching to CILogin so we can motivate relying and paying on CILogon.
• What are the questions we need to answer to decide if we make the switch?
  • Time invested to make a switch
  • More.
• We have agreement on investing time to pilot further work with CILogon's REST API

[yuvipanda]

#1089 is a great step forward here. I think we can aim to move off auth0 exclusively towards CILogon. It also will allow us to remove some of the dynamic code generation we do for auth0 in our deployer.

[choldgraf]

Update: nearly done

We discussed this in the team meeting today, here are major takeaways:

• Most of the infrastructure work is done! 🎉
• Since this issue is scoped to investigating and prototyping, we can consider this "done" when we have it piloted with at least one hub and resolved major issues (see task list above)
• We should then open another issue to track the experience using this over time w/ ANU, and make a plan for when to switch away from Auth0 in general

[damianavila]

We should then open another issue to track the experience using this over time w/ ANU, and make a plan for when to switch away from Auth0 in general

We are supposedly in a "trial", right? When does that trial end? That might affect the timing for those changes...

[choldgraf]

My 2 cents: trial it for roughly a month (we can focus on other development projects during the trial) and try to get up to 3 hubs using the authenticator. So maybe we set a checkpoint for May 15th with a goal of deploying this in at least 2 more hubs. At the checkpoint we can discuss how this has gone and whether to plan for a bigger switch?

[damianavila]

Sorry, I was not clear enough... when I say trial, I am asking about the CILogin trial subscription we currently have for testing the new stuff... the end day for that trial subscription will affect the timing (and be discussed ;-) you are suggesting above.

[choldgraf]

Ah - my understanding is that it is semi-indefinitely, with an informal understanding that we will begin paying them when we believe it is sustainable for us and fair for them. I think there is a lot of trust and assumptions of "good faith" here, so we have flexibility, but should be thoughtful about not abusing that trust.

[damianavila]

OK, thanks for the additional context!! Super useful.

[GeorgianaElena]

I believe we should close this issue since it's gone pretty stale.
I opened #1304 to cover one of the last remaining bullet points here.
That issue, together with https://github.com/2i2c-org/meta/issues/317 should be enough to continue the work here once there's interest again.

Please feel free to reopen if you think we should still use it for tracking.