passwordCallback in CXF

I develop a webservice client for an existing webservice. I am using Apache CXF 2.2. The service requires security with Username and plain text password, which I configured like this:

<bean id="myPasswordCallback"
    class="com.kraemer_imd.mobilized.m2m_adapter.ClientPasswordCallback"/>

<jaxws:client id="m2mClientService"
              serviceClass="de.vodafone.easypu.ws.EasyPUOrderServicePortType"
              address="http:/开发者_StackOverflow社区/m2m.vodafone.de/speasy/services/EasyPUOrderService"
              bindingId="http://www.w3.org/2003/05/soap/bindings/HTTP/">

  <jaxws:outInterceptors>
    <bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
      <constructor-arg>
        <map>
            <entry key="action" value="UsernameToken Timestamp"/>
          <entry key="passwordType" value="PasswordText"/>
          <entry key="user" value="myusername"/>
          <entry key="passwordCallbackRef">
            <ref bean="myPasswordCallback"/>
          </entry>
        </map>
      </constructor-arg>
    </bean>
  </jaxws:outInterceptors>

</jaxws:client>

That works quite well. But I did not understand why I have to provide the password via a callback handler instead of just providing it via configuration. The documentation says it is for security reasons, but I don´t see why this should be more secure to have a callback handler that reads it from a property file (or worse has it hard coded in the callback).

So, could somebody explain this to me? Maybe the callback is intended for some magic stuff that I missed..

Thanks Michel

The password callback is provided by Apache CXF as a mechanism for the client application to retrieve the credentials for the targeted webservice, which at runtime is likely to be stored in the database, configuration fiels, LDAP or some other store. This callback hook provides the flexibility to the application to retrieve the credentials from application specific configuration.

If password is stored in clear text in the configuration then this approach may not give you any extra security.

However having password stored as clear text in some configuration may have some security issues as there can be folks that may need access to this configuration and will be able to hold of password although it may not have been intended to.

Better is to store the encrypted password in the configuration. In this case, you need some code that will decrypt this password before it's use. Password callback will come to rescue in this scenario.