Cloudbank followup to review auth config

[consideRatio]

Should users of urn:mace:incommon:berkeley.edu generally be authorized?

@sean-morris in #3144 I've migrated a lot of auth configuration from oauthenticator v15.1.0 config to oauthenticator v16.1.0 confg. Doing so I observed something that may not be intented in the auth config for cloudbank hubs and wanted to check with you the intent.

In almost all hubs configured to authenticate with the CILogon IdP urn:mace:incommon:berkeley.edu, all of the idps users get authorized access to the hub. The exception is those hub that username_pattern is configured as that is a separate check that needs to be passed to be authorized.

Is is your intent to authorize all users from that identity provider? If not, additional options arise in oauthenticator 16.1 that we are transitioning to now.

I've for now configured this previous behavior to remain the same by adding allow_all under that idp, but after this we can make any individual jupyterhub user listed in admin_users be authorized without authorizing all users from an idp like urn:mace:incommon:berkeley.edu.

[sean-morris]

The username_pattern is configured in ccsf, demo, and srjc.

In these three cases, we had a request to allow a specific personal Gmail account access to the hub.

In the demo hub, we could remove the two gmail addresses there now but it might be easier to leave the username_pattern config because we sometimes have a need to let someone play around on the demo hub while we deal with configuration issues on their institution's hub.

CCSF made a specific request to allow a specific email address access to the hub -- although they didn't need admin access for this user.

SRJC has not started using their hub yet but I know we had some problems with the srjc.edu address that we punted on. They are a while off from course approval.

I am not sure if your solution works because we don't necessarily want them to be admins. Maybe I am not getting this part right.

I guess I am still a bit confused. For example, the SJCC config looks like this:

         shown_idps:
          - http://login.microsoftonline.com/common/oauth2/v2.0/authorize
          - http://google.com/accounts/o8/id
          - urn:mace:incommon:berkeley.edu
        allowed_idps:
          http://login.microsoftonline.com/common/oauth2/v2.0/authorize:
            username_derivation:
              username_claim: "email"
            allowed_domains:
              - "sjcc.edu"
              - "stu.sjcc.edu"
              - "stu.evc.edu"
              - "evc.edu"
          http://google.com/accounts/o8/id:
            username_derivation:
              username_claim: "email"
            allowed_domains:
              - "2i2c.org"
              - "berkeley.edu"
          urn:mace:incommon:berkeley.edu:
            username_derivation:
              username_claim: "email"
      Authenticator:
        admin_users:
          - [email protected]
          - [email protected]
          - [email protected]
          - [email protected]
          - [email protected]

We don't need to allow anyone from berkeley.edu access to this hub. We just need Eric, Ksenyia, and myself. How do we set this up so it is cleaner?

Maybe this is what you have done and I am good!

[consideRatio]

@sean-morris ah excellent thanks for summarizing this!

With oauth 16, you can allow an individual user without username_pattern involved by specifying the username in allowed_users (of admin_users). Before that caused other issues. Username patterns may no longer be needed.

Should i tighten access configured in all hubs granted to users of the berkeley identity provider down to you/erik/ksenyia?

[sean-morris]

Yes that would be great

[consideRatio]

@sean-morris I like to minimize the complexity of auth config to make future maintenance easier, and sometimes it seems both berkeley and google as identity providers to help you/Erik/Ksenyia sign in with your @berkeley.edu emails. Can we reduce that to only use one identity provider instead?