That change should definitely be OK. With the old version of wss4j, I think
that is just or'ing a 0 on, basically a no-op. Thus, it should definitely be
OK.
Dan
On Wed October 14 2009 3:41:08 pm Gabriel Guardincerri wrote:
> 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.handleUsernameTo
> >>ken (UsernameTokenProcessor.java:86) at
> >> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(User
> >>nam eTokenProcessor.java:56) 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)
> >>
> >> 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
