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

Group permissions not recognised by Authorize Project

XMLWordPrintable

    • 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.

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

              Created:
              Updated: