-
Bug
-
Resolution: Unresolved
-
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.
- is related to
-
JENKINS-61902 "authenticated" group doesn't work with Authorize Project plugin
- Open