You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by slew77 <sl...@googlemail.com> on 2010/04/14 11:54:08 UTC
allowNamespaceQualifiedPasswordTypes ignored
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
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>
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.
Re: allowNamespaceQualifiedPasswordTypes ignored
Posted by slew77 <sl...@googlemail.com>.
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.
Re: allowNamespaceQualifiedPasswordTypes ignored
Posted by Freeman Fang <fr...@gmail.com>.
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
Re: allowNamespaceQualifiedPasswordTypes ignored
Posted by slew77 <sl...@googlemail.com>.
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.
Re: allowNamespaceQualifiedPasswordTypes ignored
Posted by Freeman Fang <fr...@gmail.com>.
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