Hi, That would make sense, if he also had to modify the WSS4JInInterceptor, like I've had to. Seems like a feature that would be useful to be in CXF, better than everyone creating their own WSS4JInInterceptor when they need to support .Net clients - although it's useful that we have that option! I'll see about contributing a patch - not sure how that works yet.
Thanks. Freeman Fang wrote: > > Hi, > > My comment inline > On 2010-4-14, at 下午9:34, slew77 wrote: > >> >> 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 > > From the last entry, if I understand correctly, he mentioned "this > way, after i modified WSS4JInInterceptor", he do need modified the > WSS4JInInterceptor along with the configuration for WSS4JInInterceptor > constructor. > > So I don't think it's now broken, it never be there IMHO. > > Also from that post, Dan point out he do some changes to allow > configuring in a specific WSConfig object relatively easily, but > that's not available in a release yet. > > Freeman > >> 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. >> > > > -- > Freeman Fang > ------------------------ > Open Source SOA: http://fusesource.com > > > -- View this message in context: http://old.nabble.com/allowNamespaceQualifiedPasswordTypes-ignored-tp28240611p28242884.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
