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

Group permissions not recognised by Authorize Project

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • Jenkins: 2.332.1
      OS: Linux - 4.14.252-195.483.amzn2.x86_64
      jwt-auth:0.2.0
      matrix-auth:2.6.11
      role-strategy:3.2.0
      authorize-project:1.4.0

      Background:
      We've got SSO set up (JWT auth) and users are members of a few groups (whose names are non-human-readable UUIDs because the back-end is Azure AD).
      When users log in, all is well and .../whoAmI/ reports group membership correctly, e.g.

      Name: Ariana.Hlavaty@i2group.com 
      IsAuthenticated?: true 
      Authorities:
       * "authenticated"
       * "220cd04c-aca6-405f-a95f-83d71d2ef62c"
       * "a4aeb39e-e89b-4ffd-ad08-6e5fe3148254"
      

      We define user's permissions based on their group membership, e.g. the group "220cd04c-aca6-405f-a95f-83d71d2ef62c" grants Overall/Administer permissions.
      i.e. users can log in and they get all the Jenkins WebUI options that the permissions resulting from their group membership(s) permit.

      We've got the Authorize Project plugin set to "Project default Build Authorization Strategy: Run as User who Triggered Build" and have no overrides permitted (or configured) in any other builds, so all builds run as "User who triggered build".
      ...and this seems to work OK too.

      The bug
      The problem comes when a user triggers a build that contains a job-dsl step.
      When this happens, users are told e.g.
      Ariana.Hlavaty@i2group.com’ lacks permission to run on ‘EC2 (ec2-cloud) - Job DSLs Agent (i-0235b81cc92f33210)

      ...even though they've got admin rights as far as all the rest of Jenkins is concerned.

      What's really odd...
      If we edit the authorisation configuration to explicitly name "Ariana.Hlavaty@i2group.com" as having admin permissions (e.g. by telling the role-strategy plugin that that user has the admin role, where the admin role grants overall admin, or using the matrix-auth to say that that user has overall admin) then the job can be run ... even though the user is a member of a group which grants that permission in other circumstances (e.g. Ariana is able to access the Manage Jenkins link because her user is in group "220cd04c-aca6-405f-a95f-83d71d2ef62c" which grants Overall/Administer permissions).

      TL;DR: Something, somewhere, is failing to take account of rights granted as a result of group membership, and it's causing job-DSL builds to fail.

          [JENKINS-68105] Group permissions not recognised by Authorize Project

          Markus Winter added a comment -

          Please provide more details.

          Did you assign the group to a global role, an item/project role and/or a node role?

          Markus Winter added a comment - Please provide more details. Did you assign the group to a global role, an item/project role and/or a node role?

          Hi mawinter69, I've only used the global role section. The item and node sections have only "Anonymous" on the assign tab and they are empty on the manage tab.

          Ariana Hlavaty added a comment - Hi mawinter69 , I've only used the global role section. The item and node sections have only "Anonymous" on the assign tab and they are empty on the manage tab.

          Markus Winter added a comment -

          Could you test with the latest version 510.v909834359ec2 if the problem still exists?

          Markus Winter added a comment - Could you test with the latest version 510.v909834359ec2 if the problem still exists?

          mawinter69 sorry for the delay. Version 530.ved5445d4875a_ was tested and the problem still exists.

          Ariana Hlavaty added a comment - mawinter69 sorry for the delay. Version 530.ved5445d4875a_ was tested and the problem still exists.

          Markus Winter added a comment -

          Can you post the relevant parts of the config.xml with the permission assignments for the non working case please.

          I tried to reproduce locally (without JWT plugin) by granting permissions to a user only via group and everything works fine.

          Markus Winter added a comment - Can you post the relevant parts of the config.xml with the permission assignments for the non working case please. I tried to reproduce locally (without JWT plugin) by granting permissions to a user only via group and everything works fine.

          pjdarton added a comment -

          mawinter69 It's not a problem with the role-based plugin at all.
          I work with Ariana and I can confirm that the issue is there even if we don't use the role-based plugin (e.g. use matrix auth instead).

          The issue appears to be to do with the interaction between the authorise-project plugin being set to "run as user who triggered build" and then the user triggering a build that includes a job-dsl plugin step - the step fails, complaining that the user doesn't have the rights that they need if those rights are only granted from group membership. If the rights are granted to that named user (e.g. they've got their own row in the matrix for their username assigning rights regardless of group membership, or they've got their own row in the role-plugin's who-has-what-role table) then it works ... but if you've said "everyone in group <X> has these rights" and put that user in that group then while they have those rights as far as the rest of Jenkins is concerned, they don't have those rights when the jobDSL plugin's step executes.

          A workaround seems to be to tell the authorise-project plugin to run all builds "as system" at which point the user's own rights are irrelevant ... but that's not the recommended setting that Ariana was following.

          pjdarton added a comment - mawinter69 It's not a problem with the role-based plugin at all. I work with Ariana and I can confirm that the issue is there even if we don't use the role-based plugin (e.g. use matrix auth instead). The issue appears to be to do with the interaction between the authorise-project plugin being set to "run as user who triggered build" and then the user triggering a build that includes a job-dsl plugin step - the step fails, complaining that the user doesn't have the rights that they need if those rights are only granted from group membership. If the rights are granted to that named user (e.g. they've got their own row in the matrix for their username assigning rights regardless of group membership, or they've got their own row in the role-plugin's who-has-what-role table) then it works ... but if you've said "everyone in group <X> has these rights" and put that user in that group then while they have those rights as far as the rest of Jenkins is concerned, they don't have those rights when the jobDSL plugin's step executes. A workaround seems to be to tell the authorise-project plugin to run all builds "as system" at which point the user's own rights are irrelevant ... but that's not the recommended setting that Ariana was following.

            oleg_nenashev Oleg Nenashev
            arihlavaty89 Ariana Hlavaty
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: