Using LibreTexts SSO to allow "LibreTexts Users" to access the Hub

[moorepants]

Here are some initial thoughts.

Some definitions:

• LibreTexts Instructors: any instructor that is an author of a textbook on libretexts.org or a co-instructor of the author.
• LibreTexts Students: a student currently in a class of a LibreTexts instructor

We need a way for libretexts instructors to obtain an account on the hub. For example, if they have a libretexts account then they should be able to log in with that.

For the students we need a way for libretexts instructors to add/remove students. Students should probably only have access to the hub while they are enrolled in a class. Students shouldn't be required to have a gmail account if possible. They should be able to log in with any email address they prefer.

Someone in the LibreTexts tech team (Chuck Severance maybe?) is connecting LibreTexts to LMSs (canvas, blackboard, etc). This is supposed to somehow give students that have access to their course's LMS page access to Libretexts. If we can utilize this, that would be very nice, cause then the student access is controlled by the instructor through the LMS.

[Miniland1333]

Chuck is currently working on getting SSO as well as LMS integration operational, though we currently are still in the research phase as it is a big & costly undertaking and we must ensure that all of the applications are compatible with each other. Until Chuck & Delmar settle on a vendor, we won't even have a rough implementation timeline as we aren't sure what percentage will be pre-built and which parts have to be coded for.

I will post here once we make progress with SSO, but since it may be a ways off do you think we should build something as a stopgap? Also, what does UCB use to manage their users for their cluster?

[moorepants]

I don't know what SSO is, can you define that? But good to know that this isn't gonna happen anytime soon.

UCB likely uses their school's authentication system. We can do that with our UCD users, but that's not the issue.

I'm all ears for a stop gap. It isn't even clear to me how Libretexts manages users of libretexts.org. Can you explain that to us first? Last I understood was that Delmar gave specific people accounts to allow editing on the website. How does one get a libretexts account, for example? And who is allowed to have one? And is that account simply a silo-ed account for the libretexts software?

[Miniland1333]

It seems that like many applications, we are dealing with an authentication issue and an authorization issue.

SSO is an umbrella term for authentication systems that reuse credentials such as UC Davis does with Eduroam. In this case, the institution (or a federation of institutions) provide the authentication about whether a user is affiliated with the institution. LTI is an implementation of SSO in which the LMS certifies the user's identity. The CAS, SAML, and Kerberos authenticators are all implementations of SSO, one of which we probably will integrate with in the future.

The part that is less standardized is the authorization issue of determine which of the authorized users are allowed to access content in the form of permissions. While any user can try to login currently using OAuth (another form of SSO), your whitelist serves as an authorization mechanism that determines which users are allowed resources on the system.

Only some faculty currently have accounts on LibreTexts and not student users due to their numbers. One option is that we could use the LibreTexts account permissions or Instructor OAuth logins to act as an authentication/authorization gate for approved faculty. From there, approved faculty could access a restricted version of a class manager web-GUI that we build in order to modify the whitelist for their class. We would use the Jupyterhub API to enact changes. I believe this option solves both criteria about having a centrally approved list of instructors and allowing instructors to manage their students. If you want to pursue this, here is a list of things that need to be done:

1. Have all participating faculty get a LibreTexts account & permission them to have access to a class manager (easy) 1B. Piggyback on existing OAuth Instructor logins.
2. Build a class manager GUI that interacts with the API (depends on web-dev skill)
3. (optional) configure the tool to automatically remove accounts 1 month after class end date (not sure if deleting user with API also deletes data as well).
4. Configure a standard username/password authentication for approved, non-google accounts.

The Jupyterhub API seems very straightforward to use, though I don't know your team's familiarity with REST and/or developing front-end applications. I currently have two big tasks that are keeping me busy, but if your team decides that this is a worthwhile investment I can try allocating time to help out with this before school starts.

Discussion about step (1) vs (1B): We do not necessarily need to use LibreTexts accounts for faculty. If you set up faculty in your application with OAuth, we can try having the class manager GUI use the same OAuth credentials and bypass having to make a separate LT account. I don't know if it is something that is easy to do, but I would recommend it over step (1) if possible to limit user-side complexity. If on the other hand all of the faculty either want or need LT credentials, then having them use their LibreTexts accounts for this step may instead make more sense.

[moorepants]

Just wanted to ping this since we discussed in today's meeting. We are still waiting on any updates from LibreTexts on how they might be handling this. Mike (at the genome center) mentioned out shibboleth is a system that more universities use and could help us authenticate university users. We'd still need to handle the authorization of what they can do our our system with something else.

[Miniland1333]

For this issue, long-term we are hoping to implement Apero CAS to serve as our SSO handler. To integrate with CAS, Jupyterhub has an Authenticator ready due to its popularity. https://github.com/cwaldbieser/jhub_cas_authenticator

Since UC Davis and many other educational institutions utilize Apero CAS themselves already, you can then register your Jupyterhub as a CAS service. https://casmgr.ucdavis.edu/register/services

[moorepants]

Ok, whenever things are running for LibreTexts, let us know we can try to integrate.

[moorepants]

@Miniland1333 showed us that he's been working on something to centralize libretexts users authentication. This is something we could work on integrating over the next quarter (winter 2021). @Miniland1333, can you provide some details of what you are working on here?

[Miniland1333]

https://sso.libretexts.org/cas/login (feel free to try out!), based on https://github.com/apereo/cas

What is SSO, and what is LibreTexts SSO?

Single Sign-on (SSO) is an authentication mechanism so that users can sign-in once and gain access to a variety of services. SSO is meant to reduce the friction of logging in many times with many credentials. LibreTexts SSO is a configured version of Apereo CAS that allows users to reuse their institutional email accounts (Google, Microsoft) to access LibreTexts services. For LibreTexts users without an institutional email, we will also support a "LibreLogin" which is just a username/password combination. LibreTexts SSO abstracts away these complexities under-the-hood, so the relying service just receives the validated user email and name. LibreTexts SSO supports protocols CAS, OAuth, OIDC, and SAML.

Do note that logging in a user has two importantly distinct parts: Authentication and Authorization. Authentication: Who is the user? Authorization: Can the access the service and what are their permissions?

LibreTexts SSO will always provide the Authentication of a user, primarily as a verified email and name. Authorization is primarily the responsibility of the service, though we do plan on providing user attributes (isInstructor, institution etc.) so the service can incorporate the user attributes into its authorization decision. Do note that while anyone can Authenticate in using LibreTexts SSO, only Authorized users should be able to actually use the service based on the decided authorization policy.

Here are some benefits that the LibreTexts SSO provides over Google OAuth directly:

1. Allows SSO sessions across LibreTexts resources
2. Adds support for authentication using Microsoft Active Directory accounts
3. Adds support for LibreLogin username/password combinations
4. Maintains ability to authenticate using Google OAuth
5. Allows for LibreTexts to potentially centrally manage authorization using user attributes.
6. SSO can allow for Thebe to access user authentication/authorization, such as to determine resource allocation or access to a code block.

What are the ordered steps required to make this possible?

• [ ] [Delmar + Henry] Create user attributes database for authorization purposes.
• [ ] [Henry + Eric] Link user attributes with Canvas LMS to determine role & courses.
• [ ] [Henry] Stress-test SSO during Winter Quarter in preparation for Spring.
• [ ] [Delmar + Jason + JupyterTeam] Define policy of how much resources LibreTexts users get as part of authorization policy.
• [ ] [JupyterTeam+Henry] Update OAuth configuration and secrets to point to sso.libretexts.org.
• [ ] [JupyterTeam, optional] Adjust authorization to incorporate user attributes.
• [ ] [JupyterTeam, optional] Add support in Thebe if desired. There's a lot of work that needs to be done LibreTexts-side still first, but once we get there I will let JupyterTeam know that we can start testing this integration on staging.

Lastly, I have attached a video of how the LibreTexts SSO functions and how the SSO session can then be reused on other LibreTexts services:

https://user-images.githubusercontent.com/12994749/103306387-4b418400-49c2-11eb-84ef-85d043becf93.mp4

This project is not urgent, as it is only required once we are ready to open the Jupyter service more widely to authenticated LibreTexts users.

[moorepants]

[Delmar] Define policy of which LibreTexts users have paid vs free access to Jupyterhub.

Can you explain this more? We've never heard of paid access.

Also, can anyone get a libretexts account? I don't think we can handle letting anyone create an account for jupyterhub access, both for capacity and abuse reasons.

[moorepants]

[JupyterTeam, optional] Add support in Thebe if desired.

What will thebe have to do with this?

[Miniland1333]

[Delmar] Define policy of which LibreTexts users have paid vs free access to Jupyterhub.

Can you explain this more? We've never heard of paid access.

Also, can anyone get a libretexts account? I don't think we can handle letting anyone create an account for jupyterhub access, both for capacity and abuse reasons.

I'm not sure sure myself, but I assume there has to be some policy to determine which users can access the service since otherwise you are correct that anyone could get an account and abuse your capacity. Updated bullet point as this is actually more of an authorization issue in determining resource allocation.

[Miniland1333]

[JupyterTeam, optional] Add support in Thebe if desired.

What will thebe have to do with this?

If you want Thebe + binder.libretexts.org to use the authentication to determine resource allocation, it would involve:

1. A flag on a code cell that it requires a larger resource allocation.
2. When clicking Run, Thebe bundles the authentication with its requests to binder.libretexts.org.
3. binder.libretexts.org checks the authentication to determine what size of binder to spin up.