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
