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

Job DSL Authorization does not add USER/GROUP from Matrix Authorization 3.0

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • job-dsl-plugin
    • None
    • Jenkins: 2.319.1 on Windows
    • 1.88

      When using Job DSL for generating folders (where I have noticed this issue), the authorization permission command does not add the new USER/GROUP prefix from Matrix Authorization 3.0 in the XML files.

          [JENKINS-67411] Job DSL Authorization does not add USER/GROUP from Matrix Authorization 3.0

          Daniel Beck added a comment -

          https://github.com/jenkinsci/job-dsl-plugin/blob/b3bd3488f6c7389be8df0c7e473d0144c364a6ad/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/Job.groovy#L296-L308 appears to be specific functionality related to matrix-auth in job-dsl, operating directly on the serialized XML of the configuration.

          Unfortunately, this approach means that job-dsl plugin does not declare a dependency (even optional) on matrix-auth, so it doesn't show up in https://plugins.jenkins.io/matrix-auth/#dependencies at all and I was unaware this existed.

          Note how this directive has been working with obsolete configurations for quite a while — blocksInheritance was replaced with a more powerful inheritance management in matrix-auth 2.0 (Oct 2017).

          So there's nothing matrix-auth can do about this — job-dsl works directly on serialized configuration XML.

          Daniel Beck added a comment - https://github.com/jenkinsci/job-dsl-plugin/blob/b3bd3488f6c7389be8df0c7e473d0144c364a6ad/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/Job.groovy#L296-L308 appears to be specific functionality related to  matrix-auth in job-dsl , operating directly on the serialized XML of the configuration. Unfortunately, this approach means that job-dsl plugin does not declare a dependency (even optional) on matrix-auth , so it doesn't show up in https://plugins.jenkins.io/matrix-auth/#dependencies at all and I was unaware this existed. Note how this directive has been working with obsolete configurations for quite a while —  blocksInheritance was replaced with a more powerful inheritance management in matrix-auth 2.0 (Oct 2017). So there's nothing  matrix-auth can do about this —  job-dsl works directly on serialized configuration XML.

          Rich added a comment - - edited

          Is there a solution to this yet ? I am facing same issue with matrix auth 3.0.

          Following works fine, but results in a warning on UI:

          _authorization

          { permissions(this.myADGroup, ['hudson.model.Item.Read','hudson.model.Item.Configure'])}

          _

          When I try changing it to:

          _authorization

          { permissions(this.myADGroup, ['GROUP:hudson.model.Item.Read','GROUP:hudson.model.Item.Configure'])}

          _

          I get error:

          ERROR: (unknown source) permission must be one of com.cloudbees.plugins.credentials.CredentialsProvider.Create,com.cloudbees.plugins.credentials.CredentialsProvider.Delete,com.cloudbees.plugins.credentials.CredentialsProvider.ManageDomains,com.cloudbees.plugins.credentials.CredentialsProvider.Update,com.cloudbees.plugins.credentials.CredentialsProvider.View,hudson.model.Item.Build,hudson.model.Item.Cancel,hudson.model.Item.Configure,hudson.model.Item.Delete,hudson.model.Item.Discover,hudson.model.Item.Move,hudson.model.Item.Read,hudson.model.Item.Workspace,hudson.model.Run.Delete,hudson.model.Run.Replay,hudson.model.Run.Update,hudson.scm.SCM.Tag

          Rich added a comment - - edited Is there a solution to this yet ? I am facing same issue with matrix auth 3.0. Following works fine, but results in a warning on UI: _authorization { permissions(this.myADGroup, ['hudson.model.Item.Read','hudson.model.Item.Configure'])} _ When I try changing it to: _authorization { permissions(this.myADGroup, ['GROUP:hudson.model.Item.Read','GROUP:hudson.model.Item.Configure'])} _ I get error: ERROR: (unknown source) permission must be one of com.cloudbees.plugins.credentials.CredentialsProvider.Create,com.cloudbees.plugins.credentials.CredentialsProvider.Delete,com.cloudbees.plugins.credentials.CredentialsProvider.ManageDomains,com.cloudbees.plugins.credentials.CredentialsProvider.Update,com.cloudbees.plugins.credentials.CredentialsProvider.View,hudson.model.Item.Build,hudson.model.Item.Cancel,hudson.model.Item.Configure,hudson.model.Item.Delete,hudson.model.Item.Discover,hudson.model.Item.Move,hudson.model.Item.Read,hudson.model.Item.Workspace,hudson.model.Run.Delete,hudson.model.Run.Replay,hudson.model.Run.Update,hudson.scm.SCM.Tag

          Precision Support added a comment - - edited

          richmond I struggled with this workaround too and got the same error as you. The key is to not use the permissions() method off of authorization, because that's a method defined by the DSL which is not updated to support the new syntax. You have to start at the job level and get all the way to the the authorizationMatrix. The other problem might be the way you specify the permission because this is technically a different permissions() method.

          You want to try something more like this but you'll have to replace jobvar with whatever your variable that represents the job is:

          jobvar.properties {
            authorizationMatrix {
              permissions([ "GROUP:Job/Read:${this.myADGroup}", "GROUP:Job/Configure:${this.myADGroup}" ])
            }
          }

          Precision Support added a comment - - edited richmond I struggled with this workaround too and got the same error as you. The key is to not use the permissions() method off of authorization, because that's a method defined by the DSL which is not updated to support the new syntax. You have to start at the job level and get all the way to the the authorizationMatrix. The other problem might be the way you specify the permission because this is technically a different permissions() method. You want to try something more like this but you'll have to replace jobvar with whatever your variable that represents the job is: jobvar.properties { authorizationMatrix { permissions([ "GROUP:Job/Read:${ this .myADGroup}" , "GROUP:Job/Configure:${ this .myADGroup}" ]) } }

          Erik Purins added a comment -

          Hit this a month ago (linux container host version 2.332.3 with job dsl plugin 1.79) and just got around to hacking together a fix for my pipelines. I wasn't able to get the simple permissions( ) list to work with the versions of plugins I have, and ended up writing configure blocks to manipulate the auth xml blocks.
           

          def matrix = it / 'properties' /'hudson.security.AuthorizationMatrixProperty'
          matrix / inheritanceStrategy(class: "org.jenkinsci.plugins.matrixauth.inheritance.InheritParentStrategy")
          matrix.appendNode('permission', "GROUP:com.cloudbees.plugins.credentials.CredentialsProvider.Create:${myADGroup}".toString())

           It's gross but worked.

          Erik Purins added a comment - Hit this a month ago (linux container host version 2.332.3 with job dsl plugin 1.79) and just got around to hacking together a fix for my pipelines. I wasn't able to get the simple permissions( ) list to work with the versions of plugins I have, and ended up writing configure blocks to manipulate the auth xml blocks.   def matrix = it / 'properties' /'hudson.security.AuthorizationMatrixProperty' matrix / inheritanceStrategy(class: "org.jenkinsci.plugins.matrixauth.inheritance.InheritParentStrategy") matrix.appendNode('permission', "GROUP:com.cloudbees.plugins.credentials.CredentialsProvider.Create:${myADGroup}".toString())  It's gross but worked.

          Adam Krapfl added a comment -

          My team was able to work around this just recently with the following syntax, which does not delve into the messy configure blocks:
           
                      properties {
                          authorizationMatrix {
                              users.each

          { user ->                         permissionMatrix.add("USER:hudson.model.Item.Build:$user")                         permissionMatrix.add("USER:hudson.model.Item.Workspace:$user")                         permissionMatrix.add("USER:hudson.model.Item.Configure:$user")                     }

                              groups.each

          { group ->                         permissionMatrix.add("GROUP:hudson.model.Item.Build:$group")                         permissionMatrix.add("GROUP:hudson.model.Item.Workspace:$group")                         permissionMatrix.add("GROUP:hudson.model.Item.Configure:$group")                     }

                              permissionMatrix.add("GROUP:hudson.model.Item.Read:authenticated")
                              permissions(permissionMatrix)
                          }

                      }

           

          Anyone want to confirm that the *authorizationMatrix{ permissions

          {[]}

          }* works for them?

          Adam Krapfl added a comment - My team was able to work around this just recently with the following syntax, which does not delve into the messy configure blocks:               properties {                 authorizationMatrix {                     users.each { user ->                         permissionMatrix.add("USER:hudson.model.Item.Build:$user")                         permissionMatrix.add("USER:hudson.model.Item.Workspace:$user")                         permissionMatrix.add("USER:hudson.model.Item.Configure:$user")                     }                     groups.each { group ->                         permissionMatrix.add("GROUP:hudson.model.Item.Build:$group")                         permissionMatrix.add("GROUP:hudson.model.Item.Workspace:$group")                         permissionMatrix.add("GROUP:hudson.model.Item.Configure:$group")                     }                     permissionMatrix.add("GROUP:hudson.model.Item.Read:authenticated")                     permissions(permissionMatrix)                 }             }   Anyone want to confirm that the *authorizationMatrix{ permissions {[]} }* works for them?

          Mateusz added a comment -

          I can, properly sets permissions and removes warning

              multibranchPipelineJob(jobName) {
                  properties {
                      authorizationMatrix {
                          permissions(['GROUP:hudson.model.Item.Build:authenticated'])
                      }
                  }
          ... 

          Mateusz added a comment - I can, properly sets permissions and removes warning     multibranchPipelineJob(jobName) {         properties {             authorizationMatrix {                 permissions([ 'GROUP:hudson.model.Item.Build:authenticated' ])             }         } ...

          Dirk Heinrichs added a comment - - edited

          For the "properties/authorizationMatrix" is there a way to have a "permissionAll" or is it working just like one permission for one group/user per line?

          I guess this can be achieved by granting "Overall/Administer", right?

          Dirk Heinrichs added a comment - - edited For the "properties/authorizationMatrix" is there a way to have a "permissionAll" or is it working just like one permission for one group/user per line? I guess this can be achieved by granting "Overall/Administer", right?

          Could someone please translate the (Job-DSL) example from akrapfl  above into the new "entries {}" based syntax? I tried 

           properties {
            authorizationMatrix {
              entries {
                config['authorization'].each { entry ->
                  if (entry['type'] == 'group') {
                    group {
                      name(entry['name'])
                      permissions(entry['permissions'])
                    }
                  }
                  else {
                    user {
                      name(entry['name'])
                      permissions(entry['permissions'])
                    }
                  }
                }
              }
              inheritanceStrategy {
                nonInheriting()
              }
            }
          }

          but that only results in the two empty default entries for "anonymous" and "authenticated" being added to the job.

          Dirk Heinrichs added a comment - Could someone please translate the (Job-DSL) example from akrapfl   above into the new "entries {}" based syntax? I tried  properties {   authorizationMatrix {     entries {       config[ 'authorization' ].each { entry ->         if (entry[ 'type' ] == 'group' ) {           group {             name(entry[ 'name' ])             permissions(entry[ 'permissions' ])           }         }         else {           user {             name(entry[ 'name' ])             permissions(entry[ 'permissions' ])           }         }       }     }     inheritanceStrategy {       nonInheriting()     }   } } but that only results in the two empty default entries for "anonymous" and "authenticated" being added to the job.

          See JENKINS-72263 for a follow-up on my previous comment.

          Dirk Heinrichs added a comment - See JENKINS-72263 for a follow-up on my previous comment.

          Basil Crow added a comment -

          Fixed in jenkinsci/job-dsl-plugin#1415. Released in 1.88.

          Basil Crow added a comment - Fixed in jenkinsci/job-dsl-plugin#1415 . Released in 1.88 .

            emueller Eva Müller
            pegasus77 Roland Gärtner
            Votes:
            5 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated:
              Resolved: