• Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: Major Major
    • core
    • Jenkins 1.641, Java 1.8.0_66, OS Red Hat Enterprise Linux Server release 5.8 (Tikanga)

      We have a similar issue as described in JENKINS-3350 Connect to update center via HTTP proxy that requires NTLM authentication

      But our proxy does not require NTLM authentication, it just likes it best. I found this out via reading the log entries generated by the apache httpclient during an attempt to download a plugin. There you can read

      Dec 15, 2015 12:43:02 PM FINE org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
      Supported authentication schemes in the order of preference: [ntlm, digest, basic]
      Dec 15, 2015 12:43:02 PM INFO org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
      ntlm authentication scheme selected
      Dec 15, 2015 12:43:02 PM FINE org.apache.commons.httpclient.auth.AuthChallengeProcessor processChallenge
      Using authentication scheme: ntlm
      Dec 15, 2015 12:43:02 PM FINE org.apache.commons.httpclient.auth.AuthChallengeProcessor processChallenge
      Authorization challenge processed
      ...
      Dec 15, 2015 12:43:02 PM SEVERE org.apache.commons.httpclient.HttpMethodDirector authenticate
      Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials
      org.apache.commons.httpclient.auth.InvalidCredentialsException: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials
      	at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:332)
      	at org.apache.commons.httpclient.HttpMethodDirector.authenticateProxy(HttpMethodDirector.java:320)
      

      To highlight it

      • Supported authentication schemes in the order of preference: ntlm, digest, basic
      • ntlm authentication scheme selected - automatically by apache http client

      So in our case we could get around all this hassle if there was an option on the proxy page to define the authentication scheme the http client shall use. If I find the time I will have a look if I can propose a pull request.

      I have attached a small draft how it could look like

      Why the priority major?
      For me it is rather cumbersome to manually download all plugins in order to upload them into jenkins via the internal plugin upload page. Moreover the nice feature of the self-updating jenkins is broken for us.

          [JENKINS-32293] Configure proxy authentication scheme

          There is no need to configure it over the Jenkins UI. This can be configure via a system property. Have a read in the documentation:

          Controlling which authentication scheme is used
          When a server needs a client to authenticate, it may propose a number of schemes to the client (for example digest and ntlm) and the client may choose from among them. Normally, applications do not care which scheme is used to and the implementation automatically chooses the strongest (most secure) protocol transparently.

          If the user needs to ensure that a particular scheme is used, then the following system property can be set to modify the default behavior.

                  -Dhttp.auth.preference="scheme"
          

          -D is specified if the property is being set on the command line. "http.auth.preference" is the property name, and scheme is the name of the scheme to use. If the server does not include this scheme in its list of proposed schemes, then the default choice is made.

          I did not find it either in the beginning

          Christian Effertz added a comment - There is no need to configure it over the Jenkins UI. This can be configure via a system property. Have a read in the documentation : Controlling which authentication scheme is used When a server needs a client to authenticate, it may propose a number of schemes to the client (for example digest and ntlm) and the client may choose from among them. Normally, applications do not care which scheme is used to and the implementation automatically chooses the strongest (most secure) protocol transparently. If the user needs to ensure that a particular scheme is used, then the following system property can be set to modify the default behavior. -Dhttp.auth.preference= "scheme" -D is specified if the property is being set on the command line. "http.auth.preference" is the property name, and scheme is the name of the scheme to use. If the server does not include this scheme in its list of proposed schemes, then the default choice is made. I did not find it either in the beginning

            Unassigned Unassigned
            chefffe Christian Effertz
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: