HTTP basic authentication through CXF interceptor not working

问题

I'm having some trouble setting the HTTP Authorization header for a web service request using Apache CXF. I have my client setup through spring:

<bean id="loggingInInterceptor" class="org.apache.cxf.interceptor.LoggingInInterceptor" />
<bean id="loggingOutInterceptor" class="org.apache.cxf.interceptor.LoggingOutInterceptor" />

<bean id="myHTTPAuthInterceptor" class="my.app.MyHTTPAuthInterceptor" autowire="constructor" />

<bean id="webServiceFactory" class="my.app.WebServiceFactory">
    <property name="wsdlLocation" value="classpath:/my/app/webservice.wsdl" />
    <property name="serviceURL">
        <jee:jndi-lookup jndi-name="webservice/url" />
    </property>
    <property name="inInterceptors">
        <list>
            <ref bean="loggingInInterceptor" />
        </list>
    </property>
    <property name="outInterceptors">
        <list>
            <ref bean="loggingOutInterceptor" />
            <ref bean="myHTTPAuthInterceptor" />
        </list>
    </property>
</bean>

<bean id="myWebService" factory-bean="webServiceFactory" factory-method="getInstance" />

Headers are set through MyHTTPAuthInterceptor like this:

public MyHTTPAuthInterceptor(ConfigDao configDao)
{
    super(Phase.POST_PROTOCOL);

    this.configDao = configDao;
}

@Override
public void handleMessage(Message message) throws Fault
{
    Map<String, List<?>> headers = (Map<String, List<?>>) message.get(Message.PROTOCOL_HEADERS);

    String authString = configDao.getUsername() + ":" + config.getPassword();
    headers.put("Authorization", Collections.singletonList("Basic " + new String(Base64.encodeBase64(authString.getBytes()))));
}

With username and both set to 'test', everything seems to be OK in the logs:

Headers: {SOAPAction=[""], Accept=[*/*], Authorization=[Basic dGVzdDp0ZXN0]}

However, the server returns a HTTP 401: Unauthorized.

Not knowing what's going wrong, I took a whole other approach by changing my web service client factory code. I added a basic authorization policy to the client's conduit like this:

HTTPConduit httpConduit = (HTTPConduit) client.getConduit();
AuthorizationPolicy authorizationPolicy = new AuthorizationPolicy();
authorizationPolicy.setUserName("test");
authorizationPolicy.setPassword("test");
authorizationPolicy.setAuthorizationType("Basic");
httpConduit.setAuthorization(authorizationPolicy);

Tested my setup again, same log (different order though):

Headers: {SOAPAction=[""], Authorization=[Basic dGVzdDp0ZXN0], Accept=[*/*]}

Now the server's response is 200 OK!

Problem solved you might think, but the second approach doesn't really work for me. My application is a multi-tenant environment, all with different username and password. With the second approach I cannot reuse my client.

How can I get my interceptor to work correctly? Am I plugging into the wrong phase? Does the order of the headers matter? If so, how do I change it?

回答1:

I have almost exactly the same setup as yours but I am putting my interceptor in the PRE_PROTOCOL phase. So far, I have not experienced any problem. You might try that.

I think POST_PROTOCOL is just too late because too much has already been written to the stream.

回答2:

If you are looking to externalize the client and authentication best approach is to setup httpConduit in spring context..

 **in your spring context file...**

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       ...

  <bean id="properties" class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
    <property name="locations">
        <util:list>
            <value>file:${config.dir}/application.properties</value>
        </util:list>
    </property>
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
 </bean>
  ...
  <jaxws:client id="serviceClient" serviceClass="com.your.ServiceClass" address="${webservice.soap.address}" >
    <jaxws:inInterceptors>
        <bean id="loggingInInterceptor" class="org.apache.cxf.interceptor.LoggingInInterceptor" >
            <property name="prettyLogging" value="true" />
        </bean>
    </jaxws:inInterceptors>
    <jaxws:outInterceptors>
        <bean id="loggingOutInterceptor" class="org.apache.cxf.interceptor.LoggingOutInterceptor" >
            <property name="prettyLogging" value="true" />
        </bean>
    </jaxws:outInterceptors>
  </jaxws:client>
  ...


applicaiton.properties
---------------------
webservices.http.auth.username=userName
webservices.http.auth.password=Password
webservice.soap.address=https://your.service.url/services/service

a) by mentioning the SOAP Address in the name attribute. which your can find in your WSDL

Ex: if in your WSDL..
    <wsdl-definitions ... targetNamespace="http://your.target.namespace.com/" ...>
    ...
    <wsdl:port binding="tns:YourServiceSoapBinding"
        name="YourServiceImplPort">
        <soap:address location="https://your.service.url/services/service" /> 

Then

...
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
xmlns:sec="http://cxf.apache.org/configuration/security"
...
<http-conf:conduit name="https://your.service.url/services/service">
    <http-conf:authorization>
        <sec:UserName>${webservices.http.auth.username}</sec:UserName>
        <sec:Password>${webservices.http.auth.password}</sec:Password>
        <sec:AuthorizationType>Basic</sec:AuthorizationType>
    </http-conf:authorization>
</http-conf:conduit>

Or b) name attribute should be {targetNamespace}portName.http_conduit

<http-conf:conduit name="{http://your.target.namespace.com/}YourServiceImplPort.http_conduit">
    <http-conf:authorization>
        <sec:UserName>${webservices.http.auth.username}</sec:UserName>
        <sec:Password>${webservices.http.auth.password}</sec:Password>
        <sec:AuthorizationType>Basic</sec:AuthorizationType>
    </http-conf:authorization>
</http-conf:conduit>

来源：https://stackoverflow.com/questions/11984319/http-basic-authentication-through-cxf-interceptor-not-working