title: Digest Authentication With Apache CXF
body: <p>I'm trying to make a web service call with Java and Apache's cxf library, and of course, if possible, this should happen with digest authentication, basic as fallback if the server doesn't support digest.</p>
  
  <p>I have the following code, creating a service port from the WSDL, creating a HTTPConduit, which is able to handle the authentication negotiation, and setting the desired authorization type "Digest".</p>
  
  <pre><code>MyService myService = new MyService("wsdl-url");
  MyServicePort myServicePort = myService.getMyServicePort();
  
  Client client = ClientProxy.getClient(myServicePort);
  HTTPConduit http = (HTTPConduit) client.getConduit();
  
  AuthorizationPolicy authPolicy = new AuthorizationPolicy();
  authPolicy.setAuthorizationType("Digest");
  authPolicy.setUserName("user");
  authPolicy.setPassword("myPassword");
  http.setAuthorization(authPolicy);
  
  myServicePort.doSomething();
  </code></pre>
  
  <p>Now this works perfectly fine if the server responds with accepting digest authentication only, thus with the header:</p>
  
  <pre><code>WWW-Authenticate: Digest realm="...", nonce="...", algorithm=MD5, qop="auth"\r\n
  </code></pre>
  
  <p>But there is another server (the servers are actually cameras)  which responds by offering both authentication methods, basic and digest:</p>
  
  <pre><code>WWW-Authenticate: Digest realm="...", nonce="...", stale=FALSE, qop="auth"\r\n
  WWW-Authenticate: Basic realm="..."\r\n
  </code></pre>
  
  <p>And there it will fail, because the retransmission is not sent. I guess cxf just picks one of the two methods, which by chance is basic, but does not find an authorization policy with the basic method, and therefore it fails.</p>
  
  <p>Here is some of the stacktrace:</p>
  
  <pre><code>Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '401: Unauthorized' when communicating with http://192.168.x.x/vapix/services
  at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1600) ~[cxf-rt-transports-http-3.1.8.jar:3.1.8]
  at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1607) ~[cxf-rt-transports-http-3.1.8.jar:3.1.8]
  at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1551) ~[cxf-rt-transports-http-3.1.8.jar:3.1.8]
  </code></pre>
  
  <p>Does anybody know if this is a bug by cxf? Or is there a workaround for that? My only idea would be to write my own HttpAuthSupplier, but this might be a bit delicate.</p>
  
  <p>Thanks,
  Silvan</p>