-
New Feature
-
Resolution: Duplicate
-
Minor
-
Jenkins 1.646
Role-based Authorization Strategy 2.2.0
Steps to reproduce:
- Create a user in Jenkins own user database with upper-case letters.
- Assign a role to this user, but use lower-case letters.
- Note that going back into Assign Roles shows the icon indicating that this user is valid.
- Note that this user does not have the appropriate role.
- Remove the previous role and assign the role to the user using upper-case letters.
- Note that the user now has the appropriate role.
Since a user can login to their account in a case insensitive way, the role assignments should also be handled in a case insensitive way. Right now, it is very hard to figure out why roles are not working when the case is not matched between the role screen and the user database.
- duplicates
-
JENKINS-19409 Support case-insensitive mode for user IDs
-
- Resolved
-
- is duplicated by
-
JENKINS-40442 Role assignments are case sensitive to login credentials
-
- Resolved
-
-
-
- Closed
-
[JENKINS-34545] Assigning roles is case sensitive, and it shouldn't be
Benjamin Buehlmann
added a comment - Same problem here with Active Directory integration. Any workarounds?
Benjamin Buehlmann
added a comment - Same problem here with Active Directory integration. Any workarounds? Unassigning the issue for now. We have added two Role Strategy plugin project ideas to GSoC 2019: https://jenkins.io/projects/gsoc/2019/project-ideas/. If somebody is interested in co-mentoring the ideas (including these tickets), please let us know
D Pasto
added a comment - I verified the workaround of assigning the user multiple times to each role: JoeUser, joeuser, Joeuser, JOEUSER
It doesn't display right since the LDAP lookup doesn't like the duplication, and it wouldn't scale well, but it does work - I can login with the most common capitalization patterns and get the right permissions
D Pasto
added a comment - I verified the workaround of assigning the user multiple times to each role: JoeUser, joeuser, Joeuser, JOEUSER
It doesn't display right since the LDAP lookup doesn't like the duplication, and it wouldn't scale well, but it does work - I can login with the most common capitalization patterns and get the right permissions 
Peter
added a comment - How is this issue not resolved yet????
This defect was posted in 2016. It's now May of 2021 and I am still having this issue.
This needs to be addressed ASAP.
Peter
added a comment - How is this issue not resolved yet????
This defect was posted in 2016. It's now May of 2021 and I am still having this issue.
This needs to be addressed ASAP.
Tobias
added a comment - They were talking about a huge perfomance impact while trying to fix that.
I would expect following not have a huge impact:
- Every SID is transformed to lower-case while writing it into config.xml
- While permissions read, the curent User is transformed to lower case
Perhaps its not as nice as case insensitive match but should still work.
Tobias
added a comment - They were talking about a huge perfomance impact while trying to fix that.
I would expect following not have a huge impact:
Every SID is transformed to lower-case while writing it into config.xml
While permissions read, the curent User is transformed to lower case
Perhaps its not as nice as case insensitive match but should still work.
I have the same issue. My Jenkins instance uses Security Realm of Active Directory, and Authorization of Role-Based Strategy. If the user does not use the same user ID case I use in Role Strategy, then they get the "missing the Overall/Read permission" error.
As Active Directory does not care about case, my WORKAROUND is to enter 2 global and project entries for the user. One uppercase, DW12345, and one lowercase, dw12345. I could tell the user to use only lowercase, but then I would just get hassled by users who don't remember, or want an excuse to debate why we are moving to Jenkins. Love the plugin, as it works perfectly to control job visibility and read/write permissions. But the case sensitivity is an unnecessary pain.