1 Reply Latest reply on May 6, 2010 10:55 PM by David Thomas

    JAX-WS with JBoss Negotiation

    Florian Noname Newbie



      We have a problem with the JBoss negotiate module and a Java client accessing Jboss over HTTP using SPNEGO. In fact we want to call a web service, but we can reproduce the problem with a simple URL connection. The problem is that second HTTP response from JBoss is a 200 without any content. So the HTTP traffic is like:

      1    0.000000    HTTP    GET /Service?wsdl HTTP/1.1

      2    0.004617    HTTP    HTTP/1.1 401 Unauthorized  (text/html)

      WWW-Authenticate: Negotiate

      20    0.506055    HTTP    GET /Service?wsdl HTTP/1.1

      Authorization: Negotiate YIIEqAYJKoZIhvcSAQI....

      22    0.509754    HTTP    HTTP/1.1 200 OK

      HTTP/1.1 200 OK
      Server: Apache-Coyote/1.1
      Pragma: No-cache
      Cache-Control: no-cache
      Expires: Thu, 01 Jan 1970 01:00:00 CET
      Set-Cookie: JSESSIONID=E2EE81A95B3622CE666F29ACCBA02354; Path=/i2gpm
      Transfer-Encoding: chunked
      Date: Thu, 22 Apr 2010 15:02:17 GMT




      So, the Session id is there, but no content at all. If I request the same URL with firefox the traffic is like:

      47    23.795866    HTTP    GET /Service?wsdl HTTP/1.1

      48    23.801357    HTTP    HTTP/1.1 401 Unauthorized  (text/html)

      WWW-Authenticate: Negotiate

      53    23.845475    HTTP    GET /Service?wsdl HTTP/1.1

      Authorization: Negotiate YIIK8wYGKwYBBQUCoIIK5zCCCuOgMDAuB..

      55    23.865853    HTTP    HTTP/1.1 401 Unauthorized  (text/html)

      Set-Cookie: JSESSIONID=98E17BF573A0468D416584C9F16F5AEF; Path=/

      WWW-Authenticate: Negotiate oRQwEqADCgEBoQsGCSqGSIb3EgECAg==

      60    23.877610    HTTP    GET /Service?wsdl HTTP/1.1

      Cookie: JSESSIONID=98E17BF573A0468D416584C9F16F5AEF

      Authorization: Negotiate oYIKujCCCragAwoBAaKCCq0Eggqp...

      621    154.649824    HTTP    Continuation or non-HTTP traffic


      As you can see, there is one more roundtrip involved in the SPNEGO authentication and the final step is a HTTP continuation with the actual data


      The Java client does:


           BufferedInputStream content = (BufferedInputStream)new URL("http://rzmsv147:18080/Service?wsdl").getContent();
              InputStreamReader reader = new InputStreamReader(content);
              BufferedReader bufReader = new BufferedReader(reader);
              String str = null;
              while((str = bufReader.readLine()) != null) {


      And has the following configuration related to Kerberos:








      com.sun.security.jgss.krb5.initiate {
          com.sun.security.auth.module.Krb5LoginModule required debug=true useTicketCache=true doNotPrompt=false;





          default_realm = INTRA.COMP.AT
          default_tgs_enctypes = aes256-cts aes256-cts-hmac-sha1-96 aes128-cts aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc des-cbc-md4
          default_tkt_enctypes = aes256-cts aes256-cts-hmac-sha1-96 aes128-cts aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc des-cbc-md4
          udp_preference_limit = 1
          INTRA.COMP.AT = {
              kdc = kdc.comp.at:kdc1.comp.at
          .intra = INTRA.COMP.AT



      Any ideas why the SPNEGO authentication works with firefox, but not with the Java client? This is on Windows 7 with Java 1.6 on the client and JBoss Negotiation 2.0.3.SP1 on the server.


      Thanks in advance, Florian

        • 1. Re: JAX-WS with JBoss Negotiation
          David Thomas Newbie

          Two things I would try:


          Modify your krb5.conf file to have these two lines:

          default_tgs_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des-cbc-md4
          default_tkt_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des-cbc-md4

          That drops the higher encryption types to support rc4-hmac, which is still pretty strong at 128 bit encryption anyways.


          Second thing

          With Windows 7 and Windows 2008, Microsoft changed the default encryption protocols that are supported.

          If the first step above doesn't work, then I would modify the GPO on your 2008 and Win 7 boxes to support the two DES encryption types (unlike XP and 2003 they are now disabled by default) in addition to the default values.


          The GPO setting is located in:

          Security Settings | Local Policies | Security Options | Network Security: Configure encryption types allowed for Kerberos


          See how that goes.  If you can, please update this thread if it works.