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

Provide a "Test" button that allows verification of the LDAP settings before application to prevent lockout

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • ldap-plugin
    • None

    Description

      Problem

      As a Jenkins admin, there is no way to validate my LDAP configuration without saving it. This means that the only way to check the configuration is to apply the configuration and potentially lock myself and everyone else out of Jenkins.

      In the event of a lock-out the only solution is to login to the Jenkins server and edit the JENKINS_HOME/config.xml file by hand to disable security and continue.

      With the new setup wizard in Jenkins 2.x this means that the Jenkins instance will be insecure while trying to fix the LDAP settings (the setup wizard will be using the "own" security realm when I am initially configuring LDAP, once we save the LDAP settings we have lost the "own" realm, so disabling security to fix the LDAP settings will leave the instance vulnerable)

      Solution

      Provide a means to validate the entire LDAP security realm configuration with trial username/password combinations without saving or applying the security settings.

      This will not prevent me from saving broken configurations, but it will provide me the opportunity to validate without saving.

      Acceptance Criteria

      • There will be a button in the LDAP configuration that will allow validating the current LDAP configuration with a trial username/password combination. The button will be outside the "Advanced" section so that it is always visible. In order to reduce UI clutter, clicking the button will display a popup/modal dialog that prompts for the username and password as well as providing some guidance on how to test effectively.
      • When the modal form has been submitted, the validation results will be displayed on the main configuration screen as the admin may need to copy some of the details when correcting their configuration.
      • The following validations will be performed
        • Validate that the username / password combination can authenticate. Failure to authenticate will be reported as an error unless the password is empty (in which case it should be a warning).
        • Validate that the username can be found.
          • If the username cannot be found, hints will be provided:
            • Possibly incorrect filter
            • Possibly incorrect search base
            • Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
            • Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
            • Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
          • If the username cannot be found but the username / password authenticated, this will be reported as an error.
          • If the username cannot be found and the username / password failed to authenticate, this will be reported as a warning (the admin may be testing an account that should not be reported to Jenkins)
        • When a user has been either authenticated or found through lookup, the groups that the user is a member of will be reported.
        • When a user has been either authenticated or found through lookup, the user details will be reported:
          • DN
          • Display Name
          • Email Address
        • When a user has been both authenticated and found through lookup, the account details for both paths will be compared and any discrepancies reported:
          • Groups resolved differently
          • Display Name resolved differently
          • Email address resolved differently
        • Display name lookup will be validated. Where the display name is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
        • Email address resolver will be validated. Where the email address is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
        • Validate group lookup. When the user has either been authenticated or found through lookup and the user is a member of at least one LDAP group, the reverse lookup of each group that the user is a member of will be validated. Failure to reverse lookup any groups will be reported as an error and hints provided:
          • Possibly incorrect filter
          • Possibly incorrect search base
          • Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
          • Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
          • Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
      • The LDAP wiki page documentation should be refreshed to reflect the validate button and provide guidance on how to use it effectively.
      • @JenkinsRule and unit tests will verify the individual validations
      • The Acceptance Test Harness based tests will be augmented to validate a happy path validation and a sad path validation. The effectiveness of individual validations is out-of-scope for the Acceptance Test Harness as they are more efficiently verified through @JenkinsRule and unit tests  

      On completion of this feature rtyler will be notified to include reference to this feature in the Jenkins Handbook.

      Attachments

        Issue Links

          Activity

            stephenconnolly Stephen Connolly created issue -

            I suspect that JENKINS-24347 is just some confusion around how form validation works, but in any case form validation cannot consider the full entire security realm configuration as this involves nested hetero-list elements.

            I do not think that JENKINS-24347 is strictly a duplicate of this issue but they are somewhat related in concept and we may be able to close that as WONTFIX with this new feature

            stephenconnolly Stephen Connolly added a comment - I suspect that JENKINS-24347 is just some confusion around how form validation works, but in any case form validation cannot consider the full entire security realm configuration as this involves nested hetero-list elements. I do not think that JENKINS-24347 is strictly a duplicate of this issue but they are somewhat related in concept and we may be able to close that as WONTFIX with this new feature
            stephenconnolly Stephen Connolly made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-24347 [ JENKINS-24347 ]
            stephenconnolly Stephen Connolly made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            stephenconnolly Stephen Connolly made changes -
            Remote Link This issue links to "PR#18 (Web Link)" [ 15908 ]
            stephenconnolly Stephen Connolly made changes -
            Remote Link This issue links to "ATH tests (Web Link)" [ 15909 ]
            stephenconnolly Stephen Connolly made changes -
            Description h1. Problem

            As a Jenkins admin, there is no way to validate my LDAP configuration without saving it. This means that the only way to check the configuration is to apply the configuration and potentially lock myself and everyone else out of Jenkins.

            In the event of a lock-out the only solution is to login to the Jenkins server and edit the {{JENKINS_HOME/config.xml}} file by hand to disable security and continue.

            With the new setup wizard in Jenkins 2.x this means that the Jenkins instance will be insecure while trying to fix the LDAP settings (the setup wizard will be using the "own" security realm when I am initially configuring LDAP, once we save the LDAP settings we have lost the "own" realm, so disabling security to fix the LDAP settings will leave the instance vulnerable)
            h1. Solution

            Provide a means to validate the *entire* LDAP security realm configuration with trial username/password combinations without saving or applying the security settings.

            This will not prevent me from saving broken configurations, but it will provide me the opportunity to validate without saving.
            h2. Acceptance Criteria
             * There will be a button in the LDAP configuration that will allow validating the current LDAP configuration with a trial username/password combination. The button will be outside the "Advanced" section so that it is always visible. In order to reduce UI clutter, clicking the button will display a popup/modal dialog that prompts for the username and password as well as providing some guidance on how to test effectively.
             * When the modal form has been submitted, the validation results will be displayed on the main configuration screen as the admin may need to copy some of the details when correcting their configuration.
             * The following validations will be performed
             ** Validate that the username / password combination can authenticate. Failure to authenticate will be reported as an error.
             ** Validate that the username can be found.
             *** If the username cannot be found, hints will be provided:
             **** Possibly incorrect filter
             **** Possibly incorrect search base
             **** Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
             **** Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
             **** Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
             *** If the username cannot be found but the username / password authenticated, this will be reported as an error.
             *** If the username cannot be found and the username / password failed to authenticate, this will be reported as a warning (the admin may be testing an account that should not be reported to Jenkins)
             ** When a user has been either authenticated or found through lookup, the groups that the user is a member of will be reported.
             ** When a user has been either authenticated or found through lookup, the user details will be reported:

             *** DN
             *** Display Name
             *** Email Address
             ** When a user has been both authenticated and found through lookup, the account details for both paths will be compared and any discrepancies reported:
             *** Groups resolved differently
             *** Display Name resolved differently
             *** Email address resolved differently
             ** Display name lookup will be validated. Where the display name is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
             ** Email address resolver will be validated. Where the email address is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
             ** Validate group lookup. When the user has either been authenticated or found through lookup and the user is a member of at least one LDAP group, the reverse lookup of each group that the user is a member of will be validated. Failure to reverse lookup any groups will be reported as an error and hints provided:
             *** Possibly incorrect filter
             *** Possibly incorrect search base
             *** Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
             *** Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
             *** Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
             * The LDAP wiki page documentation should be refreshed to reflect the validate button and provide guidance on how to use it effectively.
             * {{@JenkinsRule}} and unit tests will verify the individual validations
             * The Acceptance Test Harness based tests will be augmented to validate a happy path validation and a sad path validation. The effectiveness of individual validations is out-of-scope for the Acceptance Test Harness as they are more efficiently verified through {{@JenkinsRule}} and unit tests  

            On completion of this feature [~rtyler] will be notified to include reference to this feature in the Jenkins Handbook.
            h1. Problem

            As a Jenkins admin, there is no way to validate my LDAP configuration without saving it. This means that the only way to check the configuration is to apply the configuration and potentially lock myself and everyone else out of Jenkins.

            In the event of a lock-out the only solution is to login to the Jenkins server and edit the {{JENKINS_HOME/config.xml}} file by hand to disable security and continue.

            With the new setup wizard in Jenkins 2.x this means that the Jenkins instance will be insecure while trying to fix the LDAP settings (the setup wizard will be using the "own" security realm when I am initially configuring LDAP, once we save the LDAP settings we have lost the "own" realm, so disabling security to fix the LDAP settings will leave the instance vulnerable)
            h1. Solution

            Provide a means to validate the *entire* LDAP security realm configuration with trial username/password combinations without saving or applying the security settings.

            This will not prevent me from saving broken configurations, but it will provide me the opportunity to validate without saving.
            h2. Acceptance Criteria
             * There will be a button in the LDAP configuration that will allow validating the current LDAP configuration with a trial username/password combination. The button will be outside the "Advanced" section so that it is always visible. In order to reduce UI clutter, clicking the button will display a popup/modal dialog that prompts for the username and password as well as providing some guidance on how to test effectively.
             * When the modal form has been submitted, the validation results will be displayed on the main configuration screen as the admin may need to copy some of the details when correcting their configuration.
             * The following validations will be performed
             ** Validate that the username / password combination can authenticate. Failure to authenticate will be reported as an error unless the password is empty (in which case it should be a warning).
             ** Validate that the username can be found.
             *** If the username cannot be found, hints will be provided:
             **** Possibly incorrect filter
             **** Possibly incorrect search base
             **** Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
             **** Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
             **** Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
             *** If the username cannot be found but the username / password authenticated, this will be reported as an error.
             *** If the username cannot be found and the username / password failed to authenticate, this will be reported as a warning (the admin may be testing an account that should not be reported to Jenkins)
             ** When a user has been either authenticated or found through lookup, the groups that the user is a member of will be reported.
             ** When a user has been either authenticated or found through lookup, the user details will be reported:

             *
             **
             *** DN
             *** Display Name
             *** Email Address
             ** When a user has been both authenticated and found through lookup, the account details for both paths will be compared and any discrepancies reported:
             *** Groups resolved differently
             *** Display Name resolved differently
             *** Email address resolved differently
             ** Display name lookup will be validated. Where the display name is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
             ** Email address resolver will be validated. Where the email address is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
             ** Validate group lookup. When the user has either been authenticated or found through lookup and the user is a member of at least one LDAP group, the reverse lookup of each group that the user is a member of will be validated. Failure to reverse lookup any groups will be reported as an error and hints provided:
             *** Possibly incorrect filter
             *** Possibly incorrect search base
             *** Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
             *** Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
             *** Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
             * The LDAP wiki page documentation should be refreshed to reflect the validate button and provide guidance on how to use it effectively.
             * {{@JenkinsRule}} and unit tests will verify the individual validations
             * The Acceptance Test Harness based tests will be augmented to validate a happy path validation and a sad path validation. The effectiveness of individual validations is out-of-scope for the Acceptance Test Harness as they are more efficiently verified through {{@JenkinsRule}} and unit tests  

            On completion of this feature [~rtyler] will be notified to include reference to this feature in the Jenkins Handbook.

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/java/hudson/security/LDAPSecurityRealm.java
            src/main/resources/jenkins/security/plugins/ldap/Messages.properties
            http://jenkins-ci.org/commit/ldap-plugin/5088ad46ad5e769728c71bae430f150a0f0d74e1
            Log:
            JENKINS-43388 Sync the implementation with the documented acceptance criteria

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/hudson/security/LDAPSecurityRealm.java src/main/resources/jenkins/security/plugins/ldap/Messages.properties http://jenkins-ci.org/commit/ldap-plugin/5088ad46ad5e769728c71bae430f150a0f0d74e1 Log: JENKINS-43388 Sync the implementation with the documented acceptance criteria

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/resources/hudson/security/LDAPSecurityRealm/config.properties
            http://jenkins-ci.org/commit/ldap-plugin/cc8d2d2b7357b313544b76cff3288654c87440d8
            Log:
            JENKINS-43388 Fix whitespace in message bundle

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/resources/hudson/security/LDAPSecurityRealm/config.properties http://jenkins-ci.org/commit/ldap-plugin/cc8d2d2b7357b313544b76cff3288654c87440d8 Log: JENKINS-43388 Fix whitespace in message bundle

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/resources/jenkins/security/plugins/ldap/validation/validate.jelly
            src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.js
            http://jenkins-ci.org/commit/ldap-plugin/ff919c69d4dfb28962b4eb2f4ce00b5c525f23db
            Log:
            JENKINS-43388 Move stashed sub-form to window object to prevent undefined dialog box error

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/resources/jenkins/security/plugins/ldap/validation/validate.jelly src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.js http://jenkins-ci.org/commit/ldap-plugin/ff919c69d4dfb28962b4eb2f4ce00b5c525f23db Log: JENKINS-43388 Move stashed sub-form to window object to prevent undefined dialog box error

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/java/hudson/security/LDAPSecurityRealm.java
            src/main/resources/jenkins/security/plugins/ldap/Messages.properties
            http://jenkins-ci.org/commit/ldap-plugin/a258feee8ef904ac557b9c29ef1bd4e71e27d713
            Log:
            JENKINS-43388 Improve validation messages

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/hudson/security/LDAPSecurityRealm.java src/main/resources/jenkins/security/plugins/ldap/Messages.properties http://jenkins-ci.org/commit/ldap-plugin/a258feee8ef904ac557b9c29ef1bd4e71e27d713 Log: JENKINS-43388 Improve validation messages

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/resources/hudson/security/LDAPSecurityRealm/config.properties
            src/main/resources/jenkins/security/plugins/ldap/Messages.properties
            http://jenkins-ci.org/commit/ldap-plugin/0633afcd053254b38ee0d172c4e81c76d486640c
            Log:
            JENKINS-43388 @cyrille-leclerc requested tweaks to message strings

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/resources/hudson/security/LDAPSecurityRealm/config.properties src/main/resources/jenkins/security/plugins/ldap/Messages.properties http://jenkins-ci.org/commit/ldap-plugin/0633afcd053254b38ee0d172c4e81c76d486640c Log: JENKINS-43388 @cyrille-leclerc requested tweaks to message strings

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            pom.xml
            src/images/validation-ok.svg
            src/main/java/hudson/security/LDAPSecurityRealm.java
            src/main/java/jenkins/security/plugins/ldap/FromUserRecordLDAPGroupMembershipStrategy.java
            src/main/resources/hudson/security/LDAPBindSecurityRealm.groovy
            src/main/resources/hudson/security/LDAPSecurityRealm/config.jelly
            src/main/resources/hudson/security/LDAPSecurityRealm/config.properties
            src/main/resources/hudson/security/LDAPSecurityRealm/help-disableRolePrefixing.html
            src/main/resources/jenkins/security/plugins/ldap/Messages.properties
            src/main/resources/jenkins/security/plugins/ldap/validation/taglib
            src/main/resources/jenkins/security/plugins/ldap/validation/validate.jelly
            src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.css
            src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.js
            src/main/resources/jenkins/security/plugins/ldap/validation/validate/validation-ok.png
            src/test/java/hudson/security/LDAPEmbeddedTest.java
            src/test/resources/hudson/security/sevenSeas.ldif
            http://jenkins-ci.org/commit/ldap-plugin/2f9744a42046f81063e4408ca8f13a516704df75
            Log:
            Merge pull request #18 from stephenc/better-validation

            JENKINS-43388 Provide a "Test" button that allows verification of the LDAP settings before application to prevent lockout

            Compare: https://github.com/jenkinsci/ldap-plugin/compare/f27ecc923e91...2f9744a42046

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: pom.xml src/images/validation-ok.svg src/main/java/hudson/security/LDAPSecurityRealm.java src/main/java/jenkins/security/plugins/ldap/FromUserRecordLDAPGroupMembershipStrategy.java src/main/resources/hudson/security/LDAPBindSecurityRealm.groovy src/main/resources/hudson/security/LDAPSecurityRealm/config.jelly src/main/resources/hudson/security/LDAPSecurityRealm/config.properties src/main/resources/hudson/security/LDAPSecurityRealm/help-disableRolePrefixing.html src/main/resources/jenkins/security/plugins/ldap/Messages.properties src/main/resources/jenkins/security/plugins/ldap/validation/taglib src/main/resources/jenkins/security/plugins/ldap/validation/validate.jelly src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.css src/main/resources/jenkins/security/plugins/ldap/validation/validate/validate.js src/main/resources/jenkins/security/plugins/ldap/validation/validate/validation-ok.png src/test/java/hudson/security/LDAPEmbeddedTest.java src/test/resources/hudson/security/sevenSeas.ldif http://jenkins-ci.org/commit/ldap-plugin/2f9744a42046f81063e4408ca8f13a516704df75 Log: Merge pull request #18 from stephenc/better-validation JENKINS-43388 Provide a "Test" button that allows verification of the LDAP settings before application to prevent lockout Compare: https://github.com/jenkinsci/ldap-plugin/compare/f27ecc923e91...2f9744a42046

            Released in ldap-plugin version 1.15

            stephenconnolly Stephen Connolly added a comment - Released in ldap-plugin version 1.15
            stephenconnolly Stephen Connolly made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            stephenconnolly Stephen Connolly made changes -
            Attachment live.jpg [ 37510 ]

            rtyler PING

            stephenconnolly Stephen Connolly added a comment - rtyler  PING
            stephenconnolly Stephen Connolly made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

            People

              stephenconnolly Stephen Connolly
              stephenconnolly Stephen Connolly
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: