I post this issue here with a workaround in case people stumble upon it like I did.

ldap plugin

The bug happens when using the LDAP plugin with Active Directory (AD). With AD it is necessary to setup the advanced configuration to "case insensitive" for usernames and groups. That's what I did.

When the user logs in for the first time, its configuration is stored on disk:

• an entry is made in the `users/users.xml` file
• a subdirectory under `users` is created which name is a pattern formed by its name and digits
• and there, a `config.xml` file is stored

The name stored in those files is lowercase.

role-strategy plugin

In the role-strategy plugin's "assign roles" view I configure two things:

• a mapping between roles and LDAP (AD) groups, where the groupnames are given in uppercase
• a mapping between roles and LDAP (AD) users, where the usernames are also given in uppercase

api tokens

I login as one of the users mapped to a role in the role-strategy "assign roles" table. And I generate a token for that user.

bad behaviour

When I make an API call with one of the users that have an entry in the "assign roles" table of the role-strategy plugin, the first call is OK, then, every subsequent calls give me a 403 Forbidden result. Creating another token for the same user results in any call using that new token being also a 403 Forbidden error. 

The issue comes from the role-strategy behaviour with case sensitivity. The plugin seems to make some inconsistent checks when it's an API call (bug) vs. when the user is logged in Jenkins interface (no bug). Thus the bug seems linked to the basic authentification and the way the tokens and users are stored.

Calling the API with a lowercase or uppercase username in the basic authentification does not change the 403 Forbidden error occuring.

workaround

Putting the username in lowercase in the "assign roles" table of the role-strategy plugin fixes the behaviour.

In doubt, I put the usernames both in lowercase and uppercase in the table from now on.

fix

A. A bug fix would involve making the role-strategy plugin check the user rights during an API call with a case-sensitivity behaviour consistent with other use-cases.

B. At least, in the meanwhile, documenting the behaviour in the "assign roles" view of the role-strategy plugin would be a great way to alleviate the issue.

note

I've edited this issue to better explain what the bug is and how to reproduce it.