-
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
-
-
- Open
-
[JENKINS-68105] Group permissions not recognised by Authorize Project
Ariana Hlavaty
created issue -
pjdarton
made changes -
| Component/s | Original: role-strategy-plugin [ 15758 ] |
pjdarton
made changes -
| Summary | Original: Role-based external Groups not correctly recognised in Authorize Project | New: Group permissions not recognised by Authorize Project |
pjdarton
made changes -
| Description |
Original:
When setting Role-Based security the external group/authority returned by JWT Auth plugin has the group "220cd04c-aca6-405f-a95f-83d71d2ef62c" and I've assigned this group to an admin role with Overall/Administer permissions.
The Authorize Project plugin is set to "Project default Build Authorization Strategy: Run as User who Triggered Build". Everything else in the system seems to work and I can manage Jenkins, but when trying to run a job I see the error: ‘Ariana.Hlavaty@i2group.com’ lacks permission to run on ‘EC2 (ec2-cloud) - Job DSLs Agent (i-0235b81cc92f33210)’ If I manually add "Ariana.Hlavaty@i2group.com" user instead of the securityRealm group to the admin role then the job can be run. The following is returned in the /whoAmI endpoint: Name: Ariana.Hlavaty@i2group.com IsAuthenticated?: true Authorities: * "authenticated" * "220cd04c-aca6-405f-a95f-83d71d2ef62c" * "a4aeb39e-e89b-4ffd-ad08-6e5fe3148254" |
New:
*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. {code:none} Name: Ariana.Hlavaty@i2group.com IsAuthenticated?: true Authorities: * "authenticated" * "220cd04c-aca6-405f-a95f-83d71d2ef62c" * "a4aeb39e-e89b-4ffd-ad08-6e5fe3148254" {code} 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. |
pjdarton
made changes -
| Component/s | New: job-dsl-plugin [ 16720 ] |
pjdarton
made changes -
| Link | New: This issue is related to JENKINS-61902 [ JENKINS-61902 ] |
pjdarton
made changes -
| Attachment | New: jenkins-user-authorization.yml [ 58827 ] |