servicemix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From slew77 <sle...@googlemail.com>
Subject Re: allowNamespaceQualifiedPasswordTypes ignored
Date Wed, 14 Apr 2010 13:50:45 GMT

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.


Mime
View raw message