Hi, Thanks for the response.
I understand that the issue is with .Net, but unfortunately sometimes you have to support these clients. I saw the post you quoted when I was searching for solutions to this, seems that the author of that post got it working as a WSS4JInInterceptor constructor property (last entry), although they may have been incorrect. If that's the case it seems like a feature that is now broken. The WSHander class which is extended by CXF has an understanding of this .Net issue, which is why it supports the allowNamespaceQualifiedPasswordTypes property. Seems a shame if this is not made available via CXF also, if not, I can continue with my workaround, it's just not as elegant. Thanks anyway, Steve. Freeman Fang wrote: > > Hi, > > My comment inline > On 2010-4-14, at 下午5:54, slew77 wrote: > >> >> Hi, >> >> I have a CXF Web Service. This service is invoked by lots of 3rd >> party >> systems and some of these use .Net. There is a known issue with .Net >> services making the Type attribue on the Password element in >> UsernameToken >> qualified. Luckily the CXF framework provides the property >> allowNamespaceQualifiedPasswordTypes to allow these through, >> however, either > > No, I don't think any released cxf version support it only from > configuration. >> I'm not using this setting correcltly or it is not being set >> properly by the >> framework as I can't get it to work. >> >> <constructor-arg> >> <map> >> ... >> <entry key="allowNamespaceQualifiedPasswordTypes" >> value="true"/> >> </map> >> </constructor-arg> >> >> What I've found is that the property is being read from the xbean as >> if I >> give an invalid value, e.g. >> >> <constructor-arg> >> <map> >> ... >> <entry key="allowNamespaceQualifiedPasswordTypes" >> value="bob"/> >> </map> >> </constructor-arg> > > So far you do need change interceptor along with the configuration. > > Actually this is an issue from .net side according to the spec, in > wss headers, attributes are supposed to not be qualified, so should be > "Type" but not "wsse:type". > > Take a look at more discussion about this issue from [1] > [1]http://old.nabble.com/An-invalid-security-token-was-provided-%28Bad-UsernameToken-Values%29-ts27429163.html#a27429163 > > Freeman > >> >> I get an exception "illegal allowNamespaceQualifiedPasswordTypes >> parameter" >> as I'd expect. >> >> Looking in the code for WSS4JInInterceptor and its super class >> WSHander >> shows that the property is read in the call to (WSHandler) >> doReceiverAction >> in (WSS4JInInterceptor ) handleMessage. The property is set in the >> RequestData object's wssConfig. However, I think the property is >> needed in >> the WSSecurityEngine object's wssConfig. If I explicitly set the >> value in >> WSSecurityEngine in handleMessage it works as I want: >> >> getSecurityEngine >> ().getWssConfig().setAllowNamespaceQualifiedPasswordTypes(true); >> >> I don't really want to leave this workaround in as it involves >> replacing the >> WSS4JInInterceptor class in its entirety as I can't adjust the >> property >> otherwise. >> >> Any ideas what I'm doing wrong? >> >> Thanks for your help, >> Steve >> >> >> >> -- >> View this message in context: >> http://old.nabble.com/allowNamespaceQualifiedPasswordTypes-ignored-tp28240611p28240611.html >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> > > > -- > Freeman Fang > ------------------------ > Open Source SOA: http://fusesource.com > > > -- View this message in context: http://old.nabble.com/allowNamespaceQualifiedPasswordTypes-ignored-tp28240611p28242682.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
