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

Support global default authorization strategy in Authorize Project

      Due to security reasons, sometimes Jenkins admins may want to completely restrict running jobs as a system/anonymous and setup custom security limitations. In such case it would be useful to add the following features:

      • Global default strategy (if no one configured at the project level)
      • Enforced global strategy, which prevents setting other strategies on the project level

          [JENKINS-30574] Support global default authorization strategy in Authorize Project

          Oleg Nenashev created issue -

          Jesse Glick added a comment -

          I think the motivation here is misstated. If you have configured the ProjectQueueItemAuthenticator, then if any project lacks an AuthorizeProjectProperty, it will be given no authentication, and callers of Tasks.getDefaultAuthenticationOf are obliged to treat this condition as if the associated authentication were ACL.ANONYMOUS (cf. JENKINS-22949), so there is no security risk in a particular project being unconfigured—it merely will not be able to do anything requiring special permissions.

          Jesse Glick added a comment - I think the motivation here is misstated. If you have configured the ProjectQueueItemAuthenticator , then if any project lacks an AuthorizeProjectProperty , it will be given no authentication, and callers of Tasks.getDefaultAuthenticationOf are obliged to treat this condition as if the associated authentication were ACL.ANONYMOUS (cf. JENKINS-22949 ), so there is no security risk in a particular project being unconfigured—it merely will not be able to do anything requiring special permissions.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-22949 [ JENKINS-22949 ]
          Oleg Nenashev made changes -
          Description Original: Due to security reasons, sometimes Jenkins admins may want to completely restrict running jobs as a system. In such case it would be useful to add the following features:
          * Global default strategy (if no one configured at the project level)
          * Enforced global strategy, which prevents setting other strategies on the project level
          New: Due to security reasons, sometimes Jenkins admins may want to completely restrict running jobs as a system/anonymous and setup custom security limitations. In such case it would be useful to add the following features:
          * Global default strategy (if no one configured at the project level)
          * Enforced global strategy, which prevents setting other strategies on the project level

          Oleg Nenashev added a comment -

          jglick, I definitely vote for JENKINS-22949, but I doubt it can be deployed soon due to the serious regressions scope (if we don't use a new system property).

          This feature request presumes a more generic approach, which would allow to globally set ACL.ANONYMOUS or set up another custom strategy

          • e.g. on my previous installations I would authorize builds by the job owner using the strategy in Ownership plugin.
          • another use-case it to use a generic "jenkins" account on restricted instances, where anonymous user is even unable to READ anything.

          This approach is more flexible than JENKINS-22949

          Second bullet...
          In particular cases it is useful to totally prevent the manual strategy management in jobs at all => it's a justification for the second bullet (could be a separate JIRA issue BTW).

          Oleg Nenashev added a comment - jglick , I definitely vote for JENKINS-22949 , but I doubt it can be deployed soon due to the serious regressions scope (if we don't use a new system property). This feature request presumes a more generic approach, which would allow to globally set ACL.ANONYMOUS or set up another custom strategy e.g. on my previous installations I would authorize builds by the job owner using the strategy in Ownership plugin. another use-case it to use a generic "jenkins" account on restricted instances, where anonymous user is even unable to READ anything. This approach is more flexible than JENKINS-22949 Second bullet... In particular cases it is useful to totally prevent the manual strategy management in jobs at all => it's a justification for the second bullet (could be a separate JIRA issue BTW).

          Jesse Glick added a comment -

          I doubt it can be deployed soon due to the serious regressions scope (if we don't use a new system property).

          I think you misunderstand. Code checking permissions during builds (such as BuildTrigger) already replaces “undefined” with anonymous. JENKINS-22949 would simply make that more automatic and thus easier to implement for new code checking permissions during builds.

          Jesse Glick added a comment - I doubt it can be deployed soon due to the serious regressions scope (if we don't use a new system property). I think you misunderstand. Code checking permissions during builds (such as BuildTrigger ) already replaces “undefined” with anonymous . JENKINS-22949 would simply make that more automatic and thus easier to implement for new code checking permissions during builds.

          Stephen Connolly added a comment - https://github.com/jenkinsci/authorize-project-plugin/pull/13

          jglick FYI the authorize project plugin currently assumes a strategy returning null will get run as SYSTEM:

          https://github.com/jenkinsci/authorize-project-plugin/blob/master/src/test/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticatorTest.java#L145

          (of course that is incorrect, returning null means fall through to the next strategy... and if you fall off the end of all strategies then you default to SYSTEM modulo JENKINS-22949 because of backwards compatability)

          Stephen Connolly added a comment - jglick FYI the authorize project plugin currently assumes a strategy returning null will get run as SYSTEM: https://github.com/jenkinsci/authorize-project-plugin/blob/master/src/test/java/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticatorTest.java#L145 (of course that is incorrect, returning null means fall through to the next strategy... and if you fall off the end of all strategies then you default to SYSTEM modulo JENKINS-22949 because of backwards compatability)
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-32770 [ JENKINS-32770 ]

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator.java
          src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/config.jelly
          src/main/resources/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator/config.jelly
          src/main/resources/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator/help.html
          src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties
          src/main/resources/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator/config.jelly
          src/main/resources/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator/help.html
          src/main/resources/org/jenkinsci/plugins/authorizeproject/form/dropdownDescriptorSelector.jelly
          src/main/resources/org/jenkinsci/plugins/authorizeproject/form/taglib
          src/test/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticatorTest.java
          http://jenkins-ci.org/commit/authorize-project-plugin/20d2ba35fa7aebd062987a7e9c3070d597c1a4c6
          Log:
          [FIXED JENKINS-30574] Support global default authorization strategy in Authorize Project

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator.java src/main/resources/org/jenkinsci/plugins/authorizeproject/AuthorizeProjectProperty/config.jelly src/main/resources/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator/config.jelly src/main/resources/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticator/help.html src/main/resources/org/jenkinsci/plugins/authorizeproject/Messages.properties src/main/resources/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator/config.jelly src/main/resources/org/jenkinsci/plugins/authorizeproject/ProjectQueueItemAuthenticator/help.html src/main/resources/org/jenkinsci/plugins/authorizeproject/form/dropdownDescriptorSelector.jelly src/main/resources/org/jenkinsci/plugins/authorizeproject/form/taglib src/test/java/org/jenkinsci/plugins/authorizeproject/GlobalQueueItemAuthenticatorTest.java http://jenkins-ci.org/commit/authorize-project-plugin/20d2ba35fa7aebd062987a7e9c3070d597c1a4c6 Log: [FIXED JENKINS-30574] Support global default authorization strategy in Authorize Project
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

            ikedam ikedam
            oleg_nenashev Oleg Nenashev
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: