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

Github Users Outside Organisation get an authenticated user in Jenkins.

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: github-oauth-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.60.3
    • Similar Issues:

      Description

      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

       

       

        Attachments

          Issue Links

            Activity

            Hide
            jalexoid Aleksandr Panzin added a comment -

            I've had to modify the plugin for this.

            Will soon publish a PR for this feature

            Show
            jalexoid Aleksandr Panzin added a comment - I've had to modify the plugin for this. Will soon publish a PR for this feature
            Hide
            dcesario Daniel Cesario added a comment -

            Aleksandr Panzin Kudos!

            Thanks for the job!
             

            Show
            dcesario Daniel Cesario added a comment - Aleksandr Panzin Kudos! Thanks for the job!  
            Hide
            sag47 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.

            Jesse Glick 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?

            Show
            sag47 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. Jesse Glick 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?
            Hide
            sag47 Sam Gleske added a comment -

            cc Daniel Beck please refer to my question above as well.

            Show
            sag47 Sam Gleske added a comment - cc Daniel Beck please refer to my question above as well.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            sag47 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!

            Show
            sag47 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!
            Hide
            markstosberg 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. 

            Show
            markstosberg 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. 

              People

              • Assignee:
                sag47 Sam Gleske
                Reporter:
                dcesario Daniel Cesario
              • Votes:
                6 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated: