Ivy
  1. Ivy
  2. IVY-109

Enable HTTPS with authentication per URL resolver

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      It seems that the HttpClient is set up in the IvyConfigure ant task.
      However, that will mean that
      1) You can only configure one https host in you total build, so you cannot use different secure repositories
      2) There should be an option to have hosts trusted, meaning that they then don't require a certificate that is imported via the keystore java tool. Something like this:
      try
      {
      URL remote = createRemoteUrl( artifact );
      log.println( this + " - opening connection: " + artifact + " --> " + remote );
      URLConnection conn = remote.openConnection();
      if( conn instanceof HttpsURLConnection )
      {
      log.println( this + " - HTTPS connection opened." );
      if( m_trusted )
      {
      log.println( this + " - Using NullTrustManager." );
      HttpsURLConnection ssl = (HttpsURLConnection) conn;
      TrustManager nullTrustManager = new NullTrustManager();
      SSLContext ctx = SSLContext.getInstance( "SSLv3" );
      ctx.init( null, new TrustManager[]

      {nullTrustManager}

      , null );
      log.println( this + " - Setting SSLv3 socket factory." );
      SSLSocketFactory factory = ctx.getSocketFactory();
      ssl.setSSLSocketFactory( factory );
      log.println( this + " - SSL socket factory is set." );
      }
      }
      conn.connect();
      if( conn instanceof HttpURLConnection )
      {
      int code = ( (HttpURLConnection) conn ).getResponseCode();
      log.println( this + " - ResponseCode: " + code );
      if( code == HttpURLConnection.HTTP_UNAUTHORIZED )

      { throw new IOException( "Unauthorized request." ); }

      else if( code == HttpURLConnection.HTTP_NOT_FOUND )

      { return false; }

      else if( code != HttpURLConnection.HTTP_OK )

      { throw new IOException( "Unexpected Result: " + code ); }

      }

      With a NullTrustManager:
      /**

      • A null trust manager that will accept any certificate. I.e. this
      • class performs NO TRUST MANAGEMENT and simply serves as a mechanism
      • through which https connections can be established with the same notion
      • of trust as a http connection (i.e. none).
        */
        private static final class NullTrustManager
        implements X509TrustManager
        {
        /**
      • Empty certificate sequence.
        */
        private static final X509Certificate[] EMPTY_CERTS = new X509Certificate[0];

      /**

      • Null implementation.
      • @param certs the supplied certs (ignored)
      • @param authType the supplied type (ignored)
        */
        public void checkServerTrusted( final X509Certificate[] certs, final String authType )
        {
        }

      /**

      • Null implementation.
      • @param certs the supplied certs (ignored)
      • @param authType the supplied type (ignored)
        */
        public void checkClientTrusted( final X509Certificate[] certs, final String authType )
        {
        }

      /**

      • Null implementation.
      • @return an empty certificate array
        */
        public X509Certificate[] getAcceptedIssuers() { return EMPTY_CERTS; }

        }

      //this code is copied from Transit at https://scm.ops4j.org/repos/ops4j/projects/legacy/transit/core/handler/src/main/net/dpml/transit/host/ClassicResourceHost.java so it is ASLv2

      /peter

        Activity

        Hide
        Xavier Hanin added a comment -

        Christian,

        Yes, I remember your e-mail, and it seems I answered it and told you I integrated your patch on ivy trunk. The main problem is that I didn't keep track of that in jira. Sorry about that.

        For the official version, you're right, it's still 1.3.1. 1.4 is really coming soon however, so it won't be true for long. For the delay, it was supposed to be this week (for a first RC at least), but I've so much work that I haven't found the time to to do the release. I may prepare it this week-end and do the announcement on monday. But don't take that for sure. Anyway, the current latest version can be considered "very close" to what 1.4-RC1 will be.

        Show
        Xavier Hanin added a comment - Christian, Yes, I remember your e-mail, and it seems I answered it and told you I integrated your patch on ivy trunk. The main problem is that I didn't keep track of that in jira. Sorry about that. For the official version, you're right, it's still 1.3.1. 1.4 is really coming soon however, so it won't be true for long. For the delay, it was supposed to be this week (for a first RC at least), but I've so much work that I haven't found the time to to do the release. I may prepare it this week-end and do the announcement on monday. But don't take that for sure. Anyway, the current latest version can be considered "very close" to what 1.4-RC1 will be.
        Hide
        Jeff Turner added a comment -

        Xavier,

        my patch affects both this issue as well as IVY-200. I wrote you a rather longish email about the patch sometime in May.

        As IVY 1.4 has not been released officially I consider 1.3.1 to still be the "official" version; this is why I didn't check against 1.4, although I will give IVY 1.4 a spin on monday and see whether this and IVY-200 have been fixed. Any thoughts on when 1.4 will ship?

        Best regards,
        Christian

        Show
        Jeff Turner added a comment - Xavier, my patch affects both this issue as well as IVY-200 . I wrote you a rather longish email about the patch sometime in May. As IVY 1.4 has not been released officially I consider 1.3.1 to still be the "official" version; this is why I didn't check against 1.4, although I will give IVY 1.4 a spin on monday and see whether this and IVY-200 have been fixed. Any thoughts on when 1.4 will ship? Best regards, Christian
        Hide
        Xavier Hanin added a comment -

        Christian,

        I think I've already included your patch (at least I see the modification in the CHANGES.txt), but I see no associated issue, so it seems I did it in a rush and did not open a issue for it... bad thing. Anyway, it's part of official Ivy since last may. I thought I sent you an e-mail, but it seems that I failed even for that. Sorry about that!
        I've even made modifications since then to be able to define several host/realm/username/passwd uple in the configure task.

        You can use it like that:
        <ivy:configure file="path/to/my/ivyconf.xml">
        <credentials host="myhost.com" realm="My Realm" username="myuser" passwd="mypasswd" />
        <credentials host="yourhost.com" realm="Your Realm" username="myuser" passwd="myotherpasswd" />
        </ivy:configure>

        If you have only one uple you can put it as attributes of the configure task itself as currently documented.

        Andreas and Chistrian,
        I'm not absolutely sure it works, so if one of you could test that and tell me if it's an acceptable solution, then I'll mark this issue as resolved and update the CHANGES.txt and the documentation. Thanks!

        Show
        Xavier Hanin added a comment - Christian, I think I've already included your patch (at least I see the modification in the CHANGES.txt), but I see no associated issue, so it seems I did it in a rush and did not open a issue for it... bad thing. Anyway, it's part of official Ivy since last may. I thought I sent you an e-mail, but it seems that I failed even for that. Sorry about that! I've even made modifications since then to be able to define several host/realm/username/passwd uple in the configure task. You can use it like that: <ivy:configure file="path/to/my/ivyconf.xml"> <credentials host="myhost.com" realm="My Realm" username="myuser" passwd="mypasswd" /> <credentials host="yourhost.com" realm="Your Realm" username="myuser" passwd="myotherpasswd" /> </ivy:configure> If you have only one uple you can put it as attributes of the configure task itself as currently documented. Andreas and Chistrian, I'm not absolutely sure it works, so if one of you could test that and tell me if it's an acceptable solution, then I'll mark this issue as resolved and update the CHANGES.txt and the documentation. Thanks!
        Hide
        Jeff Turner added a comment -

        Andreas,

        I have a patch in hand which I have submitted to Xavier and which will hopefully make it into a future IVY release which solves the problem of using BASIC Authentication over HTTPS. It's actually rather simple.

        Despite the fact that no username/password will be transmitted in the clear over the wire when using a scheme such as 'https://username:passwd@...', the URL itself is still prone to simple glances "over the shoulder" so that is why it's generally a bad idea to actually use it like this.

        If you want my patch (can be applied straight vs. IVY 1.3.1 sources), please say so and I'll send it to you via email.

        Rgds,
        Christian

        Show
        Jeff Turner added a comment - Andreas, I have a patch in hand which I have submitted to Xavier and which will hopefully make it into a future IVY release which solves the problem of using BASIC Authentication over HTTPS. It's actually rather simple. Despite the fact that no username/password will be transmitted in the clear over the wire when using a scheme such as 'https://username:passwd@...', the URL itself is still prone to simple glances "over the shoulder" so that is why it's generally a bad idea to actually use it like this. If you want my patch (can be applied straight vs. IVY 1.3.1 sources), please say so and I'll send it to you via email. Rgds, Christian
        Hide
        Andreas Sahlbach added a comment -

        Hm, I need this too and the current implementation is a bit awkward.

        I just wanted to clarify: Of course there will be no username/password transmitted in cleartext when using a https URL. First a SSL connection will be established, then the url will be requested using the encrypted channel.

        Show
        Andreas Sahlbach added a comment - Hm, I need this too and the current implementation is a bit awkward. I just wanted to clarify: Of course there will be no username/password transmitted in cleartext when using a https URL. First a SSL connection will be established, then the url will be requested using the encrypted channel.
        Hide
        Jeff Turner added a comment -

        I cannot comment on the patch but I need this feature, too, namely the possibility to specify multiple repository locations with a distinct username/password combination per repository.

        I tried to achieve this by specifying the respective URLs according to the URI Syntax as per RFC 3986, namely Section 3.2: http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#authority but alas it seems that commons httpclient (or the specific configuration you use inside Ivy?!) does not like this:

        03.03.2006 17:02:48 org.apache.commons.httpclient.HttpMethodDirector isAuthenticationNeeded
        INFO: Authentication requested but doAuthentication is disabled
        CLIENT ERROR: Authorization Required url=https://username:passwd@intranet.XXX.com/repository/jars/myjar-1.0.jar
        HTTP response status: 401=Authorization Required url=https://username:passwd@intranet.XXX.com/repository/jars/myjar-1.0.jar

        Which – I think – is partly "OK" because transmitting the username/password pair "in the clear" is not really acceptable, especially as it puts the whole reasoning for HTTPS (don't transmit clear-text stuff over the net) aside

        Show
        Jeff Turner added a comment - I cannot comment on the patch but I need this feature, too, namely the possibility to specify multiple repository locations with a distinct username/password combination per repository. I tried to achieve this by specifying the respective URLs according to the URI Syntax as per RFC 3986, namely Section 3.2: http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#authority but alas it seems that commons httpclient (or the specific configuration you use inside Ivy?!) does not like this: 03.03.2006 17:02:48 org.apache.commons.httpclient.HttpMethodDirector isAuthenticationNeeded INFO: Authentication requested but doAuthentication is disabled CLIENT ERROR: Authorization Required url= https://username:passwd@intranet.XXX.com/repository/jars/myjar-1.0.jar HTTP response status: 401=Authorization Required url= https://username:passwd@intranet.XXX.com/repository/jars/myjar-1.0.jar Which – I think – is partly "OK" because transmitting the username/password pair "in the clear" is not really acceptable, especially as it puts the whole reasoning for HTTPS (don't transmit clear-text stuff over the net) aside
        Hide
        Peter Neubauer added a comment -

        implemented a first working version, fixing

        • URLHandlerRegistry now is a Singleton, thus being able to actually change the _default
        • https - protocol registerd in IvyConfigure and Main

        attached the diff, please verify if the format is ok.

        This should work with any repository, given that you have a trusted certificate on that server.

        /peter

        Show
        Peter Neubauer added a comment - implemented a first working version, fixing URLHandlerRegistry now is a Singleton, thus being able to actually change the _default https - protocol registerd in IvyConfigure and Main attached the diff, please verify if the format is ok. This should work with any repository, given that you have a trusted certificate on that server. /peter
        Hide
        Xavier Hanin added a comment -

        I'm sorry, but I'm far from being an expert on this field, and I must admit I don't understand what your diff changes...

        I understand that it makes the URLHandlerRegistry a singleton, and I admit it's a better thing. But then the only thing I see is that it registers an handler for https which is the same as the one for http. No per resolver configuration, and no TrustManager... So, as far as I understand, this will only let users have authentication for http and not only https. Is it really the aim of the fix ?

        Show
        Xavier Hanin added a comment - I'm sorry, but I'm far from being an expert on this field, and I must admit I don't understand what your diff changes... I understand that it makes the URLHandlerRegistry a singleton, and I admit it's a better thing. But then the only thing I see is that it registers an handler for https which is the same as the one for http. No per resolver configuration, and no TrustManager... So, as far as I understand, this will only let users have authentication for http and not only https. Is it really the aim of the fix ?

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Neubauer
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:

              Development