Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55111

Case sensitivity issue between LDAP plugin and role-strategy plugin when using Active Directory and using API tokens

XMLWordPrintable

      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.

          [JENKINS-55111] Case sensitivity issue between LDAP plugin and role-strategy plugin when using Active Directory and using API tokens

          Noël Bardelot created issue -
          Noël Bardelot made changes -
          Description Original: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or call the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve make the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...           		New: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve make the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...
          Noël Bardelot made changes -
          Description Original: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve make the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...           		New: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve making the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...
          Noël Bardelot made changes -
          Description Original: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve making the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...           		New: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve making the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view of the role-strategy plugin would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...
          Noël Bardelot made changes -
          Description Original: I post this issue here with a workaround in case people stumble upon it like I did.

          *ldap plugin*

          When using the LDAP plugin with Active Directory 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 or calls the API 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

          While the username retrived from Active Directory is uppercase, the name stored in those files is lowercase.

          *role-strategy plugin*

          It seems that the role-strategy plugin compares the name of the user in the authorization table (in the "assign roles" view) to the name in the `users/users.xml` file. Thus, if the username is lowercase, you must provide the plugin with a lowercase version of the username in the table.

          The plugin does not try to see if the "case insensitive" option of the LDAP plugin is used.

          *bug fix*

          A. A bug fix would involve making the role-strategy plugin check if the current realm used is of type LDAP, and to adopt the same case-sensitivity policy as the plugin if needed.

          B. Documenting the behaviour in the "assign roles" view of the role-strategy plugin would be a great way to alleviate the issue.

          *workaround*

          Put values in lowercase in the table containing the roles. Or, put both lowercase and uppercase values in doubt...           		New: 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._
          Summary Original: Case sensitivity issue between LDAP plugin and role-strategy plugin when using Active Directory New: Case sensitivity issue between LDAP plugin and role-strategy plugin when using Active Directory and using API tokens
          Noël Bardelot made changes -
          Description Original: 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._           		New: 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._

          Oleg Nenashev added a comment -

          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

          Oleg Nenashev added a comment - 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
          Oleg Nenashev made changes -
          Assignee Original: Oleg Nenashev [ oleg_nenashev ]
          Markus Winter made changes -
          Link New: This issue duplicates JENKINS-19409 [ JENKINS-19409 ]
          Markus Winter made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]

            Unassigned Unassigned
            bardelotnzl Noël Bardelot
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: