Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46962

Github Users Outside Organisation get an authenticated user in Jenkins.

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • github-oauth-plugin
    • None
    • Jenkins 2.60.3

      We have detected that all Github users gets authenticated in Jenkins. The user did not get rights to read/write in project, but still they are authenticated. 

       

      We have tried to use the authentication matrix instead of  GitHub Committer Authorization Strategy, but the resulta is the same.

       

      Our expected behaviour was to authenticate just user within the Github Organisation. Looking at the documentation we were not able to found a solution for this use case

       

       

          [JENKINS-46962] Github Users Outside Organisation get an authenticated user in Jenkins.

          I've had to modify the plugin for this.

          Will soon publish a PR for this feature

          Aleksandr Panzin added a comment - I've had to modify the plugin for this. Will soon publish a PR for this feature

          jalexoid Kudos!

          Thanks for the job!
           

          Daniel Cesario added a comment - jalexoid Kudos! Thanks for the job!  

          Sam Gleske added a comment - - edited

          This is a known issue but I wonder if it is a problem with Jenkins core? I notice the LDAP plugin also suffers from this behavior.  i.e. an LDAP user with no access logs into Jenkins, their account is still created, but then their access is denied.

          jglick is this a known core behavior spanning across all authorization strategies? Or does this issue just so happen to affect two separate authorization strategies the same way?

          Sam Gleske added a comment - - edited This is a known issue but I wonder if it is a problem with Jenkins core? I notice the LDAP plugin also suffers from this behavior.  i.e. an LDAP user with no access logs into Jenkins, their account is still created, but then their access is denied. jglick is this a known core behavior spanning across all authorization strategies? Or does this issue just so happen to affect two separate authorization strategies the same way?

          Sam Gleske added a comment -

          cc danielbeck please refer to my question above as well.

          Sam Gleske added a comment - cc danielbeck please refer to my question above as well.

          Daniel Beck added a comment -

          Security realms define who they consider an authenticated user. So, in the cases of LDAP, AD, PAM, anyone with an account is authenticated (and a reasonably choice for those realms). Which is all that 'authenticated' means. Some security realms like GitHub/Google integrations may reasonably limit who they consider authenticated so that the term doesn't lose any meaning; but that's up to those implementations.

          It is the responsibility of the administrators to configure their authorization strategy to restrict the access of those they don't consider authorized to access Jenkins. If 'anyone with an account on GitHub' is considered authenticated (which is, again, all the term means), then the authorization realm must be configured so that authenticated users (with no additional group memberships etc.) aren't granted significant permissions.

          Daniel Beck added a comment - Security realms define who they consider an authenticated user. So, in the cases of LDAP, AD, PAM, anyone with an account is authenticated (and a reasonably choice for those realms). Which is all that 'authenticated' means. Some security realms like GitHub/Google integrations may reasonably limit who they consider authenticated so that the term doesn't lose any meaning; but that's up to those implementations. It is the responsibility of the administrators to configure their authorization strategy to restrict the access of those they don't consider authorized to access Jenkins. If 'anyone with an account on GitHub' is considered authenticated (which is, again, all the term means), then the authorization realm must be configured so that authenticated users (with no additional group memberships etc.) aren't granted significant permissions.

          Sam Gleske added a comment -

          I could see this enhancement being valid for users who want to restrict authentication to only specific organizations. I'll leave this open. Contributions are welcome to provide this feature!

          Sam Gleske added a comment - I could see this enhancement being valid for users who want to restrict authentication to only specific organizations. I'll leave this open. Contributions are welcome to provide this feature!

          Mark Stosberg added a comment -

          I'm noting that Google solves this issue by providing "Projects" which are limited to "No Organization" or a single G-Suite organization.

           

          Github could solve this on their side by providing OAuth API client credentials which only work for a specific organization.

           

          One simple way to implement this feature is to offer a list of "whitelisted domains" as a config option, perhaps just a comma separated list.  After Github authentication is successful, check the user's email address against the domain whitelist. That would require that user's have provided their email to Github and for Github to provide the email back to Jenkins. 

          Mark Stosberg added a comment - I'm noting that Google solves this issue by providing "Projects" which are limited to "No Organization" or a single G-Suite organization.   Github could solve this on their side by providing OAuth API client credentials which only work for a specific organization.   One simple way to implement this feature is to offer a list of "whitelisted domains" as a config option, perhaps just a comma separated list.  After Github authentication is successful, check the user's email address against the domain whitelist. That would require that user's have provided their email to Github and for Github to provide the email back to Jenkins. 

            sag47 Sam Gleske
            dcesario Daniel Cesario
            Votes:
            7 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: