Hi Dan,
Thanks for the help.
Yeah, the problem was while decoding the action. Not sure if that has
changed but there is the problem.
We had
<bean id="wss4jInInterceptor"
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
<entry key="passwordCallbackClass"
value="com.XXXX" />
<entry key="action" value="UsernameToken Timestamp
NoSecurity" />
</map>
</constructor-arg>
</bean>
The last action "NoSecurity" actually makes the action decode method to
always return 0 (or no action), it doesn't matter what actions were decoded
before.
I've deleted that and now it works. But since I haven't wrote that, I'm not
sure of what I'm doing, and if that change is actually changing something
important. I mean, we need to keep backward compatibility. So is that
change, changing something that could affect other clients?
Thanks,
Gabriel
dkulp wrote:
>
>
> Digging through the code, I really don't see any difference between 2.0.7
> and
> 2.2.3 that would cause this. It does check a few other places first, but
> if
> they are null, it goes into the same original code. Since "No
> password
> callback supplied" means it's null, it should have gone into that code.
> I
> really have no idea.
>
> Is there any way you can either:
> 1) create a small test case that shows it?
>
> or
>
> 2) Debug into the WSS4JInInterceptor and see what is happening?
> Specifically,
> the getCallback method. In theory, the only way it could return null is
> if
> the line:
> if ((doAction & (WSConstants.ENCR | WSConstants.UT)) != 0) {
> catches it. However, that is that exact same line in 2.0.7 so unless the
> decoding of the actions into the doAction variable has changed, that
> should be
> fine.
>
> You could also try a couple other options:
>
> Use:
> <entry key="passwordCallbackRef">
> <bean class="com.XXX.XXX.XXXX"/>
> </entry>
>
>
> You could ALSO try setting it via "ws-security.callback-handler" as a
> jaxws:property on the jaxws:endpoint instead of the WSS4JInInceptor.
> That's
> one of the places it should look first now.
>
>
> Dan
>
>
>
>
>
> On Mon October 12 2009 1:13:47 pm Gabriel Guardincerri wrote:
>> Hi Dan,
>>
>> Nice catch, we had a different version. I've just tried with the right
>> one
>> but I still get that error. Now with related line numbers.
>>
>> Caused by: org.apache.ws.security.WSSecurityException: General security
>> error (WSSecurityEngine: No password callback supplied)
>> at
>> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken
>> (UsernameTokenProcessor.java:86) at
>> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(Usernam
>> eTokenProcessor.java:56) at
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEng
>> ine.java:326) at
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEng
>> ine.java:243) at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInIn
>> terceptor.java:198)
>>
>> Thanks,
>>
>> Gabriel
>>
>> dkulp wrote:
>> > Can you double check the version of wss4j you are picking up?
>> >
>> > There isn't any related code at lines:
>> >> (UsernameTokenProcessor.java:84)
>> >> (UsernameTokenProcessor.java:54)
>> >
>> > in the version that goes with 2.2.3. Thus, I'm thinking that some
>> > version is
>> > mismatched someplace.
>> >
>> > Dan
>> >
>> > On Fri October 9 2009 6:59:02 pm Gabriel Guardincerri wrote:
>> >> Hi,
>> >>
>> >> We've gotten this error after migrating to CXF 2.2.3 (server side):
>> >>
>> >> Caused by: org.apache.ws.security.WSSecurityException: General
>> security
>> >> error (WSSecurityEngine: No password callback supplied)
>> >> at
>> >>
>> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameTo
>> >>ken (UsernameTokenProcessor.java:84) at
>> >>
>> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(User
>> >>nam eTokenProcessor.java:54) at
>> >>
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity
>> >>Eng ine.java:326) at
>> >>
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity
>> >>Eng ine.java:243) at
>> >>
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
>> >>nIn terceptor.java:198)
>> >>
>> >> On the server side we have:
>> >>
>> >> <bean id="wss4jInInterceptor"
>> >> class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
>> >> <constructor-arg>
>> >> <map>
>> >> <entry key="passwordCallbackClass"
>> >> value="com.XXX.XXX.XXXX" />
>> >> <entry key="action" value="UsernameToken Timestamp
>> >> NoSecurity" />
>> >> </map>
>> >> </constructor-arg>
>> >> </bean>
>> >>
>> >> On the client side we are using Axis and we use this to configure it:
>> >>
>> >> Stub axisPort = (Stub) locator.getUserServicePort();
>> >> axisPort._setProperty(WSHandlerConstants.ACTION,
>> >> WSHandlerConstants.USERNAME_TOKEN);
>> >> axisPort._setProperty(UsernameToken.PASSWORD_TYPE,
>> >> WSConstants.PW_TEXT);
>> >> axisPort._setProperty(WSHandlerConstants.USER, user);
>> >> axisPort._setProperty(WSHandlerConstants.PW_CALLBACK_REF, new
>> >> PasswordCallback(password));
>> >>
>> >> Any idea of what could have changed? That worked with CXF 2.0.7
>> >>
>> >> Thank you,
>> >>
>> >> Gabriel
>>
>
> --
> Daniel Kulp
> [email protected]
> http://www.dankulp.com/blog
>
>
--
View this message in context:
http://www.nabble.com/Error%3A-General-security-error-%28WSSecurityEngine%3A-No-password-callback-supplied%29-tp25829118p25897694.html
Sent from the cxf-user mailing list archive at Nabble.com.
