[JENKINS-61785] REST API requires Job/Build permission

[jenkins-infra-bot]

After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see
 

2020-04-02 14:42:46.468+0000 [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXXXXXXXXXX/jenkins/job/YYYYYY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission

which is exactly what we get through the REST API

inetic has Admin permissions granted to a role, set throuch role-strategy-plugin and is able to execute any jobs through the UI.

We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION to either true or false, but again, it makes no difference.

May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin?

Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny.

EDIT: forgot to add, $JENKINS/whoAmI for user yields:

Name:	INETIC
IsAuthenticated?:	true
Authorities:	* "authenticated"

---

Originally reported by juanpablo, imported from: REST API requires Job/Build permission

• assignee: oleg_nenashev
• status: Open
• priority: Major
• component(s): role-strategy-plugin
• resolution: Unresolved
• votes: 2
• watchers: 6
• imported: 20251211-223321

Raw content of original issue

After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see
 

2020-04-02 14:42:46.468+0000 [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXXXXXXXXXX/jenkins/job/YYYYYY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission


which is exactly what we get through the REST API
inetic has Admin permissions granted to a role, set throuch role-strategy-plugin and is able to execute any jobs through the UI.
We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION to either true or false, but again, it makes no difference.
May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin?
Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny.
EDIT: forgot to add, $JENKINS/whoAmI for user yields:

Name:	INETIC
IsAuthenticated?:	true
Authorities:	* "authenticated"

environment

Jenkins LTS 2.222.1<br/>
role-strategy-plugin 2.16

[jenkins-infra-bot]

alexhraber:

• Original comment link
• Raw content of original comment:

  I have the same issue, 403's from github webhooks to jenkins api, which were previously succeeding (on 2.204.5). Failing on 2.222.1.
  
  I posted on JENKINS-59105 too just in case it's caused by that.
  

I have the same issue, 403's from github webhooks to jenkins api, which were previously succeeding (on 2.204.5). Failing on 2.222.1.

I posted on JENKINS-59105">JENKINS-59105 too just in case it's caused by that.

[jenkins-infra-bot]

juanpablo:

• Original comment link
• Raw content of original comment:

  Hi,
  
  we were able to locate what's happening, seems that efectively there's a bug introduced in latests LTS / role-strategy-plugin versions:
  
  	
  The user id we were using on our API calls was "INETIC" (uppercased, as it is how it is set up on the active directory); this could be seen while debugging curl's request headers: "* Server auth using Basic with user 'INETIC'".
  	
  Response headers told something a bit different, though: "< X-You-Are-Authenticated-As: inetic" (note user id is lowercased here).
  	
  The "Manage Roles" screen assigns roles to INETIC no matter how you introduce the ID. Most probably, the user id is being fetched from the AD, which makes sense.
  	
  From within the API call, being authenticated as inetic, there are no roles assigned to it, as they are assigned to INETIC. Seems that this lowercasing wasn't happening before.
  	
  We've changed the API user (with its associated token) to another with a lowercased user id and our problems are gone.
  
  
  
  This wasn't happening on our previous Jenkins instance (2.204.2 LTS with role-strategy-plugin 2.14, IIRC). The issue seems to happen with newer Jenkins LTS instances + role-strategy plugin 2.15 and 2.16, don't know specifically where the bug / regression is lying..
  

Hi,

we were able to locate what's happening, seems that efectively there's a bug introduced in latests LTS / role-strategy-plugin versions:

• The user id we were using on our API calls was "INETIC" (uppercased, as it is how it is set up on the active directory); this could be seen while debugging curl's request headers: "* Server auth using Basic with user 'INETIC'".
• Response headers told something a bit different, though: "< X-You-Are-Authenticated-As: inetic" (note user id is lowercased here).
• The "Manage Roles" screen assigns roles to INETIC no matter how you introduce the ID. Most probably, the user id is being fetched from the AD, which makes sense.
• From within the API call, being authenticated as inetic, there are no roles assigned to it, as they are assigned to INETIC. Seems that this lowercasing wasn't happening before.
• We've changed the API user (with its associated token) to another with a lowercased user id and our problems are gone.

This wasn't happening on our previous Jenkins instance (2.204.2 LTS with role-strategy-plugin 2.14, IIRC). The issue seems to happen with newer Jenkins LTS instances + role-strategy plugin 2.15 and 2.16, don't know specifically where the bug / regression is lying..

[jenkins-infra-bot]

alexhraber:

• Original comment link
• Raw content of original comment:

  Thanks juanpablo for the info.
  
  I also updated JENKINS-59105 with how I'm reproducing and what I've done to try to fix locally:
  https://issues.jenkins-ci.org/browse/JENKINS-59105?focusedCommentId=388706&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-388706
  
  
  I suppose I could just create a new ticket, but it sounds like the issue is a split between these 2 tickets.
  

Thanks juanpablo for the info.

I also updated JENKINS-59105">JENKINS-59105 with how I'm reproducing and what I've done to try to fix locally:
https://issues.jenkins-ci.org/browse/JENKINS-59105?focusedCommentId=388706&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-388706

I suppose I could just create a new ticket, but it sounds like the issue is a split between these 2 tickets.

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  The issue with case sensitivity should be fixed with release  689.v731678c3e0eb_. Role strategy will now respect if the security realm is case insensitive, so it doesn't matter if you configure "INETIC" or "inetic".
  

The issue with case sensitivity should be fixed with release  689.v731678c3e0eb_. Role strategy will now respect if the security realm is case insensitive, so it doesn't matter if you configure "INETIC" or "inetic".