Expected behavior with org_whitelist ?

[rsignell-usgs]

With jupyter-config.yaml auth set up as:

  auth:
    admin:
      access: true
      users:
        - jreadey
        - rsignell-usgs

    type: github
    github:
      clientId: "SECRET"
      clientSecret: "SECRET"
      callbackUrl: "http://pangeo.esipfed.org/hub/oauth_callback"
      org_whitelist:
        - "HDFGroup"
        - "pangeo-data"
        - "ESIPFed"
        - "USGS-CMG"
    scopes:
      - "read:org"

I find that members of the above organizations, unless they are public, get challenged with:

Is that expected, even though auth.scopes is read:org?

[choldgraf]

Specifically, are you concerned that the message is asking it to be able to modify organization data, as opposed to being read-only?

[rsignell-usgs]

I'm concerned that is involves getting a manager of the organization involved to approve, even though they've been whitelisted, but I guess there is no way around that if their group setting is set to private?

[betatim]

From the list of scopes it is also not quite clear to me why this happens. After staring at the available scopes a bit (and their ambiguous descriptions) I wonder if read:user would let you see all organisations a user is a member of even if those are private?

[rsignell-usgs]

@betatim, interesting! I'll try that out and report back.

[manics]

It's related to the permissions set on the GitHub organisation. Under Organization settings Third-party access admins can optionally restrict access to third party applications to information in the org, in which case you'll see the Request approval button

[choldgraf]

So it sounds like this is something that needs configuring at the organization level within github as opposed to within jupyterhub?

[rsignell-usgs]

Thanks @manics! I didn't know those restrictions were there, and I'm guessing those are the defaults when you setup an org.

When I remove those restrictions, folks seeking access don't get stopped by the "request approval anymore".

Alternatively, if you don't have access to the org settings, I was able to verify that adding read:user to the scopes also works!

[betatim]

Is this something we can/should document in the "User management" section?

[manics]

GitHub OAuth scopes are just very confusing! I thought I understood them but after changing my JupyterHub config a couple weeks ago and running into this problem (and also a problem with private org memberships, not sure if this is a bug that somehow crept in) I'm now pretty lost.

It would be good to test and document exactly what works. I think there are at least three factors which contribute to the confusion:

• public vs private membership of a GitHub organisation
• third party access policies on the GitHub organisation
• which auth scopes are useful out of: None, read:user, read:org
• owner of the Application (If the OAuth client belongs to an org it might be able to see org stuff).

I'm willing to help figure this out and update the docs when I get time, but due to the number of factors any help would be appreciated

[choldgraf]

@manics if you'd like to, just give a shot with each one and write down the general results of each test, and I am happy to put together a docs PR explaining it in more verbose detail etc. Would that work?

[manics]

@choldgraf It's the testing that's complicated, once the results are known updating the doc is easy :-). I'm wondering whether we could simplify things- instead of covering all combinations thoroughly test and document just two configs:

• public org membership, no scope (this definitely works)
• private org membership, scope read:user (sounds likes @rsignell-usgs has this working, I'll also test this when I get a chance)

And for everything else link to this issue or a community wiki?

[choldgraf]

I think that's fair: if read:user will work regardless of whether their membership is public, we can just recommend this. Then we can link to this issue or the github scopes page for more info.

[manics]

How does this sound? #704

[rsignell-usgs]

Actually, from my tests we need both both user and org scopes set for this to work, e.g:

    scopes:
      - "read:org"
      - "read:user

I just reconfirmed that setting read:user only is not sufficient. Here's the relevant part of my working jupyter-config.yaml:

   ...
  auth:
    admin:
      access: true
      users:
        - jreadey
        - rsignell-usgs

    type: github
    github:
      clientId: "SECRET"
      clientSecret: "SECRET"
      callbackUrl: "http://pangeo.esipfed.org/hub/oauth_callback"
      org_whitelist:
        - "HDFGroup"
        - "pangeo-data"
        - "ESIPFed"
        - "USGS-CMG"
    scopes:
      - "read:org"
      - "read:user"

  proxy:
    secretToken: "SECRET"

[choldgraf]

ah - I thought somebody had tested this out with only read:user, I didn't realize that it was both...@manics can you confirm this behavior as well? If not, I wonder what's different about your and @rsignell-usgs 's orgs

[manics]

I tested it with only read:user before updating the docs and it worked!

[manics]

@choldgraf I'm pretty busy over the next couple weeks, but I'll try and draw up a "test plan". In the meantime could you reopen this issue as a reminder?

[choldgraf]

Cool - done!

[rsignell-usgs]

I just went through a bunch of tests with a member in a whitelisted organization whose organization visibility is set to private. If the whitelisted organization has the "Third-party application access policy" set to "access restricted", and the JupyterHub application is owned by another organization, I now think there is no scopes setting in the Jupyter config that will allow allow immediate access after being challenged by Github.

With "access restricted", Github says "Only approved applications can access data in this organization. Applications owned by this organization always have access."

So I now think setting "scopes" to either read:org or read:user still requires one of these 3 things to happen:

1. the whitelisted organization member changes their organization visibility from private to public
2. the whitelisted organization owner approves the JupyterHub application
3. the whitelisted organization owner goes to "Third-party application access policy" and clicks "remove restrictions"

Previously I thought adding read:user worked, but that was because the owner of the whitelisted organization had approved the JupyterHub application using the "Third-party application access policy".

Sorry for all the confusion. I guess it would be good to have someone else verify this, considering my shaky track record on this issue thus far...

[EnigmaCurry]

I can confirm that using both scopes fixed my case. I was setting this up the same way according to the docs, and I just got 403 access denied everytime. Setting both scopes (read:org and read:user) fixes it. The only difference in my case is that the org is created with the same account as the app, so it would seem that its not just Third Party organizations that needs this setting.

[rahuldave]

Can confirm i needed both as well. Not sure I understand..., but perhaps custom auth docs need changing?