[JENKINS-59105] Accessing Jenkins using API token does not work in group memberships

[jenkins-infra-bot]

I am using Role Based Strategy to manage user permission.

I have an account under group A. I give this group Admin permission. When I call rest API with user API token Jenkins rejects the request with 403 Forbidden Error. If I add this user directly to the global roles and grant appropriate permission, it works. 

It seems API authorization doesn't work with Group. Any idea on this?

---

Originally reported by hmr5kor, imported from: Accessing Jenkins using API token does not work in group memberships

• status: Open
• priority: Major
• component(s): folder-auth-plugin, role-strategy-plugin
• resolution: Unresolved
• votes: 4
• watchers: 14
• imported: 20251211-223321

Raw content of original issue

I am using Role Based Strategy to manage user permission.

I have an account under group A. I give this group Admin permission. When I call rest API with user API token Jenkins rejects the request with 403 Forbidden Error. If I add this user directly to the global roles and grant appropriate permission, it works. 

It seems API authorization doesn't work with Group. Any idea on this?

environment

Jenkins version : 2.174<br/>
Role-based Authorization Strategy version : 2.10<br/>
---<br/>
Jenkins: 2.332.3<br/>
Folder-based Authorization Strategy: 1.4  <br/>
Folders: 6.722.v8165b_a_cf25e9

[jenkins-infra-bot]

oleg_nenashev:

• Original comment link
• Raw content of original comment:

  Are you sure you have set up the CSRF Token correctly? Please also provide the REST API request you are invoking
  

Are you sure you have set up the CSRF Token correctly? Please also provide the REST API request you are invoking

[jenkins-infra-bot]

hmr5kor:

• Original comment link
• Raw content of original comment:

  Yes as far I can tell the set up seems valid.
  
  Its is the crumb request which is failing : "https://jenkinsurl/crumbIssuer/api/json"
  
  Error : someuser is missing the Overall/Read permission
  

Yes as far I can tell the set up seems valid.

Its is the crumb request which is failing : "https://jenkinsurl/crumbIssuer/api/json"

Error : someuser is missing the Overall/Read permission

[jenkins-infra-bot]

alexhraber:

• Original comment link
• Raw content of original comment:

  This is something I've noticed as well. Github webhooks are failing with 403, which were previously succeeding without any issues after upgrading LTS from `2.204.5` to `2.222.1`.
  

This is something I've noticed as well. Github webhooks are failing with 403, which were previously succeeding without any issues after upgrading LTS from `2.204.5` to `2.222.1`.

[jenkins-infra-bot]

zburton_ancestry:

• Original comment link
• Raw content of original comment:

  I have replicated this bug. This command fails with the error "Access Denied user is missing the Agent/Create permission"
  
   curl --location --user 'username:APIKEY' --header "Content-Type:application/x-www-form-urlencoded" --request POST "https://jenkins.example.com/computer/doCreateItem?name=I-00A223022A4B270A6.example.com&type=hudson.slaves.DumbSlave"
  

I have replicated this bug. This command fails with the error "Access Denied user is missing the Agent/Create permission"

curl --location --user 'username:APIKEY' --header "Content-Type:application/x-www-form-urlencoded" --request POST "https://jenkins.example.com/computer/doCreateItem?name=I-00A223022A4B270A6.example.com&type=hudson.slaves.DumbSlave"

[jenkins-infra-bot]

alexhraber:

• Original comment link
• Raw content of original comment:

  More details:
  
   
  
  I added this to JENKINS_OPS in my jenkins.sh (I'm running in k8s via docker):
  
  jenkins_opts_array=('-Dhudson.security.csrf.CrumbFilter.UNPROCESSED_PATHINFO=true')
  
  ^ per: https://jenkins.io/doc/upgrade-guide/2.204/#upgrading-to-jenkins-lts-2-204-6
  
  I then generated a new token for my user, and set up my Github repo webhook as follows:
   url: https://dev-jenkins.url.gov/job/testjob/build
   secret: <user-token> (with admin/owner perms)
   application/json
  
  Then click apply and then click the test button from github. 403.
  
  I have also enabled and disabled the Enable proxy compatibility CSRF checkbox in Global Security.
  
  Note my testing is done in a sandbox, but the issue is impacting my production jenkins as well. I'd prefer not to roll back if possible.
  
  There are also these items in the 2.204.6 upgrade doc:
  
   
  
  - Remove Enable Security checkbox in the Global Security configuration. (issue 40228) 
  - Remove the ability to disable CSRF protection. Instances upgrading from older versions of Jenkins will have CSRF protection enabled and the default issuer set if they currently have it disabled. (pull 4509)
  
  
   
  These are not options in the UI in 2.222.1
  

More details:

 

I added this to JENKINS_OPS in my jenkins.sh (I'm running in k8s via docker):

jenkins_opts_array=('-Dhudson.security.csrf.CrumbFilter.UNPROCESSED_PATHINFO=true')

^ per: https://jenkins.io/doc/upgrade-guide/2.204/#upgrading-to-jenkins-lts-2-204-6

I then generated a new token for my user, and set up my Github repo webhook as follows:
url: https://dev-jenkins.url.gov/job/testjob/build
secret: (with admin/owner perms)
application/json

Then click apply and then click the test button from github. 403.

I have also enabled and disabled the Enable proxy compatibility CSRF checkbox in Global Security.

Note my testing is done in a sandbox, but the issue is impacting my production jenkins as well. I'd prefer not to roll back if possible.

There are also these items in the 2.204.6 upgrade doc:

 

- Remove Enable Security checkbox in the Global Security configuration. (issue 40228) 
- Remove the ability to disable CSRF protection. Instances upgrading from older versions of Jenkins will have CSRF protection enabled and the default issuer set if they currently have it disabled. (pull 4509)

 

These are not options in the UI in 2.222.1

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  alexhraber Try https://jenkins.io/doc/upgrade-guide/2.222/#always-enabled-csrf-protection
  

alexhraber Try https://jenkins.io/doc/upgrade-guide/2.222/#always-enabled-csrf-protection

[jenkins-infra-bot]

bollohz:

• Original comment link
• Raw content of original comment:

  Any news on this? It happens also in Jenkins version 2.249.1.
  

Any news on this? It happens also in Jenkins version 2.249.1.

[jenkins-infra-bot]

leonidlee:

• Original comment link
• Raw content of original comment:

  Any updates?
  
  2.263.4 is also affected.
  

Any updates?

2.263.4 is also affected.

[jenkins-infra-bot]

dshiryaev_plesk:

• Original comment link
• Raw content of original comment:

  Still reproducing on:
  
  	
  Jenkins: 2.332.3
  	
  Folder-based Authorization Strategy: 1.4  
  	
  Folders: 6.722.v8165b_a_cf25e9 
  
  
  

Still reproducing on:

• Jenkins: 2.332.3
• Folder-based Authorization Strategy: 1.4  
• Folders: 6.722.v8165b_a_cf25e9 

[jenkins-infra-bot]

danield:

• Original comment link
• Raw content of original comment:

  We are affected as well:
  
  	
  Jenkins 2.332.3
  	
  Role-based Authorization Strategy Version 562.v44e9a_e828d0e
  
  
  

We are affected as well:

• Jenkins 2.332.3
• Role-based Authorization Strategy Version 562.v44e9a_e828d0e

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  What security realms are you using?
  

What security realms are you using?

[jenkins-infra-bot]

danield:

• Original comment link
• Raw content of original comment:

  I am using Keycloak Authentication Plugin 2.3.0
  

I am using Keycloak Authentication Plugin 2.3.0

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  I'm unable to reproduce this problem locally using the latest version of role-based strategy.
  
  Possible causes for problems:
  
  	
  role strategy is case sensitive currently, so if the user or group name used doesn't match what is configured access will fail
  	
  The security realm is not properly filling the groups
  
  
  
  Check with .../whoAmI which groups the user belongs to
  
  Can the user login to Jenkins in the UI with only being granted access via a group membership?
  

I'm unable to reproduce this problem locally using the latest version of role-based strategy.

Possible causes for problems:

• role strategy is case sensitive currently, so if the user or group name used doesn't match what is configured access will fail
• The security realm is not properly filling the groups

Check with .../whoAmI which groups the user belongs to

Can the user login to Jenkins in the UI with only being granted access via a group membership?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  
  	
  The security realm is not properly filling the groups
  
  
  This is likely it. Some security realms are unable to provide group memberships when using login methods that do not involve the security realm directly (such as API tokens which are stored as user metadata in Jenkins, so no contact to the SR is needed).
  

• The security realm is not properly filling the groups

This is likely it. Some security realms are unable to provide group memberships when using login methods that do not involve the security realm directly (such as API tokens which are stored as user metadata in Jenkins, so no contact to the SR is needed).