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

Matrix based security should apply to case insensitive user name.

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: matrix-auth-plugin
    • Labels:
      None
    • Environment:
      Red Hat Linux 2.6.32-220.13.1.el6.x86_64
      Jenkins 1.571
      Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
      Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
    • Similar Issues:

      Description

      There have been several issues resolved recently with regards to case sensitivity of user name within Jenkins authentication. However, I am not certain that the current state is behaving as one would expect.

      Our users sometimes report that when logging in to Jenkins they are recognised, but no jobs are visible. We have found that the user has not matched the case as specified within the Security Matrix row.

      For example, we set up a user within the security matrix as A123 and give them their permissions. When they log in (autheticated via LDAP) as A123 there is no issue. If they log on with a123 they are still authenticated (because the LDAP authentication correctly ignores the case), but Jenkins security then fails to match due to the case difference.

      We know we can try a work around by adding two identical records to the matrix: a123 and A123. But with many users, that becomes a bit of a nightmare.

      For now we have put in a banner to say - "See no jobs? Log in with an upper case user id". But I am guessing this is something that could be improved to bury the case sensitive issues for good?

      Maybe I'm missing a checkbox or something?!?

        Attachments

          Issue Links

            Activity

            Hide
            elliottk Katherine Elliott added a comment -

            Is there any activity or planned activity on this? After upgrading to Jenkins 1.596 and getting the latest version of the matrix auth strategy plugin, we had to make, what I would consider unnecessary,changes to our Jenkins configuration to support camel-case usernames. Jenkins supports case-insensitive login names so this plugin should, too.

            Show
            elliottk Katherine Elliott added a comment - Is there any activity or planned activity on this? After upgrading to Jenkins 1.596 and getting the latest version of the matrix auth strategy plugin, we had to make, what I would consider unnecessary,changes to our Jenkins configuration to support camel-case usernames. Jenkins supports case-insensitive login names so this plugin should, too.
            Hide
            oliyavanjb jothibasu Kamaraj added a comment -

            Any Progress on this issue.

            Show
            oliyavanjb jothibasu Kamaraj added a comment - Any Progress on this issue.
            Hide
            jothibasu jothibasu k added a comment -

            Please check on this...

            Show
            jothibasu jothibasu k added a comment - Please check on this...
            Hide
            danielbeck Daniel Beck added a comment -

            There is a fairly easy workaround for this issue: Have your users log in using the user name case used in the permissions config. Use e.g. Simple Theme Plugin to add a note to the login page.

            For any higher priority, please explain the reasoning. "I really want it fixed" is not a good reason

            Show
            danielbeck Daniel Beck added a comment - There is a fairly easy workaround for this issue: Have your users log in using the user name case used in the permissions config. Use e.g. Simple Theme Plugin to add a note to the login page. For any higher priority, please explain the reasoning. "I really want it fixed" is not a good reason
            Hide
            jyoungathene James Young added a comment -

            For us, this is a minor issue that is going to rear its head a number of times. Currently, we have a mix of upper/lower case AD group names. If we set a job to the wrong case, the user can't access it. Whats worse, a user may have access on multiple groups of jobs so if we set the right case on one and not on the other, its sometimes a mystery why it isn't working until we remember this gotcha.

            It's not a show stopper by any means but it surely is annoying. Luckily, we dont have this issue with the case sensitivity of the user name but we do have this issue with the setting the groups.

            One area where this can REALLY be a problem is if you are overriding a parent matrix security setting. Its very easy to accidentally lock yourself out of the job if you put in your administrative ad group in the wrong case. Yes, I know you can go and modify the job config to fix the issue but I shouldn't have to get on my server every time I spell my group with 'd' instead of 'D'.

            Show
            jyoungathene James Young added a comment - For us, this is a minor issue that is going to rear its head a number of times. Currently, we have a mix of upper/lower case AD group names. If we set a job to the wrong case, the user can't access it. Whats worse, a user may have access on multiple groups of jobs so if we set the right case on one and not on the other, its sometimes a mystery why it isn't working until we remember this gotcha. It's not a show stopper by any means but it surely is annoying. Luckily, we dont have this issue with the case sensitivity of the user name but we do have this issue with the setting the groups. One area where this can REALLY be a problem is if you are overriding a parent matrix security setting. Its very easy to accidentally lock yourself out of the job if you put in your administrative ad group in the wrong case. Yes, I know you can go and modify the job config to fix the issue but I shouldn't have to get on my server every time I spell my group with 'd' instead of 'D'.
            Hide
            cleclerc Cyrille Le Clerc added a comment - - edited

            There seem to be a bug in the org.acegisecurity:acegi-security:1.0.7 (2008) lib used by the jenkins-ldap-plugin.

            It reuses the username provided by the login screen instead of loading it from the ldap record (see below).

            The recent versions of spring-security-ldap don't reuse the username, they reload the username from the LDAP record (see BindAuthenticator#bindWithDn().

            See org.acegisecurity.ldap.search.FilterBasedLdapUserSearch#searchForUser

            public LdapUserDetails searchForUser(String username) {
                if (logger.isDebugEnabled()) {
                    logger.debug("Searching for user '" + username + "', with user search "
                        + this.toString());
                }
            
                LdapTemplate template = new LdapTemplate(initialDirContextFactory);
            
                template.setSearchControls(searchControls);
            
                try {
                    LdapUserDetailsImpl.Essence user = (LdapUserDetailsImpl.Essence) template.searchForSingleEntry(searchBase,
                            searchFilter, new String[] {username}, userDetailsMapper);
                    user.setUsername(username);
            
                    return user.createUserDetails();
                } catch (IncorrectResultSizeDataAccessException notFound) {
                    if (notFound.getActualSize() == 0) {
                        throw new UsernameNotFoundException("User " + username + " not found in directory.");
                    }
                    // Search should never return multiple results if properly configured, so just rethrow
                    throw notFound;
                }
            }
            
            Show
            cleclerc Cyrille Le Clerc added a comment - - edited There seem to be a bug in the org.acegisecurity:acegi-security:1.0.7 (2008) lib used by the jenkins-ldap-plugin. It reuses the username provided by the login screen instead of loading it from the ldap record (see below). The recent versions of spring-security-ldap don't reuse the username, they reload the username from the LDAP record (see BindAuthenticator#bindWithDn() . See org.acegisecurity.ldap.search.FilterBasedLdapUserSearch#searchForUser public LdapUserDetails searchForUser( String username) { if (logger.isDebugEnabled()) { logger.debug( "Searching for user '" + username + "' , with user search " + this .toString()); } LdapTemplate template = new LdapTemplate(initialDirContextFactory); template.setSearchControls(searchControls); try { LdapUserDetailsImpl.Essence user = (LdapUserDetailsImpl.Essence) template.searchForSingleEntry(searchBase, searchFilter, new String [] {username}, userDetailsMapper); user.setUsername(username); return user.createUserDetails(); } catch (IncorrectResultSizeDataAccessException notFound) { if (notFound.getActualSize() == 0) { throw new UsernameNotFoundException( "User " + username + " not found in directory." ); } // Search should never return multiple results if properly configured, so just rethrow throw notFound; } }
            Hide
            recampbell Ryan Campbell added a comment -

            AFAICT, this duplicates JENKINS-23805 which was released as matrix-auth-1.7. Please correct me if I'm wrong.

            Show
            recampbell Ryan Campbell added a comment - AFAICT, this duplicates JENKINS-23805 which was released as matrix-auth-1.7. Please correct me if I'm wrong.

              People

              • Assignee:
                Unassigned
                Reporter:
                grantwilcox Grant Wilcox
              • Votes:
                9 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: