Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-23634

make HTTP client preferred auth schemes configurable in response to HTTP proxy server challenges

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.22.1
    • Fix Version/s: None
    • Component/s: Transport
    • Labels:
    • Notability:
      4

      Description

      NXRM 3 uses an ordered set of HTTP client ( outbound requests ) preferred auth schemes in response to HTTP proxy Server 407 Proxy-Authenticate challenges.

      When the configured HTTP proxy authentication username contains a domain part:

      • NTLM, DIGEST, BASIC
        When the configured HTTP proxy authentication username does not contain a domain part and is NOT Bearer token:
      • DIGEST, BASIC

      https://github.com/sonatype/nexus-internal/blob/91244e0fc322fdd395a7814bc5150a2f0779ed73/components/nexus-httpclient/src/main/java/org/sonatype/nexus/httpclient/config/ConfigurationCustomizer.java#L251

      IQ Server recently made their preferred outbound preferred client auth schemes configurable and changed from:

      ntlm,negotiate,digest,basic

      to ( HTTP client default )

      Negotiate,Kerberos,NTLM,CredSSP,Digest,Basic

      though this primarily affects HTTP Proxy servers returning 407 status codes.

      Problem

      Some environments with HTTP proxy servers handling outbound requests do not allow customizing the the Proxy-Authenticate headers on a 407 response. A server may reply with all the schemes it supports ( example: Negotiate, NTLM, Basic ), though it will be up to the client to iterate all the available schemes it supports to decide which one to use. Since the preferred auth scheme order is hardcoded in NXRM, the wrong preferred scheme may be attempted before a preferred scheme. In a worse case scenario, one of the chosen schemes (ie. NTLM ) may be chosen to use but ultimately fail due to some underlying protocol issue.

      Expected

      Allow the HTTP client preferred auth schemes to be configurable for HTTP proxy authentication replies instead of hardcoded to a fix set of values.

      No need to change the preferred scheme order for responses to non-http-proxy challenges.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            plynch Peter Lynch
            Last Updated By:
            Hardeep Nagra Hardeep Nagra
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Date of First Response:

                tigCommentSecurity.panel-title