[SWS-581] expose ability to set Wss4j option ALLOW_NAMESPACE_QUALIFIED_PASSWORD_TYPES via Wss4jSecurityInterceptor Created: 28/Oct/09  Updated: 04/May/12  Resolved: 14/Dec/09

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 1.5.8
Fix Version/s: 1.5.9

Type: Improvement Priority: Major
Reporter: Nicholas Blair Assignee: Tareq Abedrabbo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Wss4j 1.5.8 includes a new WSHandlerConstant named ALLOW_NAMESPACE_QUALIFIED_PASSWORD_TYPES.
By default, the value for this option is false.

When migrating my web services application from spring-ws 1.5.7 to 1.5.8 (which includes wss4j 1.5.8), the WS-Security header sent by Microsoft clients do not validate.
Specifically, when execution reaches line 173 of org.apache.ws.security.message.token.UsernameToken, the field allowNamespaceQualifiedPasswordTypes is false, and as a result the "WSSecurityException(WSSecurityException.INVALID_SECURITY_TOKEN,"badTokenType01",new Object[]

{el}

" is thrown.

wss4j 1.5.7 for reference looks pretty different within the same UsernameToken constructor; it simply sets passwordType to whatever "elementPassword.getAttribute(WSConstants.PASSWORD_TYPE_ATTR)" returns.

It appears ALLOW_NAMESPACE_QUALIFIED_PASSWORD_TYPES was developed in response to the format of the Microsoft clients.

I'm wondering if we can expose a way in Wss4jSecurityInterceptor to set toggle this option.



 Comments   
Comment by Nicholas Blair [ 28/Oct/09 ]

What would be the preferred way to expose this? Define a specific setter on Wss4jSecurityInterceptor, something like setAllowNamespaceQualifiedPasswordTypes(boolean)? Or a more generic setHandlerOption(String, String) that delegates to the inner Handler? Or expose the handler itself (getWss4jHandler())?

Comment by Tareq Abedrabbo [ 25/Nov/09 ]

I added a setAllowQualifiedPasswordTypes setter to achieve that. Could you please test a recent snapshot to see if it works for you?

Comment by Nicholas Blair [ 30/Nov/09 ]

Just tested with 1.5.9-SNAPSHOT, looks good to me.

Comment by Tareq Abedrabbo [ 30/Nov/09 ]

Thanks. I'm thinking that having this property on by default would greatly enhance interoperability with .Net and shouldn't have a downside on ws-security compiling web services. I think I'll remove setAllowQualifiedPasswordTypes and set the corresponding wss4j property by default. This will also simplify the interceptor, which has already an important number of setters exposed, unless you have another idea?

Comment by Nicholas Blair [ 30/Nov/09 ]

I'm not sure exactly the full impact of that parameter, so even if the default behavior is switched to true I think the setter should remain in order to let deployers override if need be.

Comment by Tareq Abedrabbo [ 14/Dec/09 ]

I allowed for qualified password types by default since this option has on negative impact on complying ws-security headers.
I'm a bit concerned about the number of properties that the Wss4jSecurityIntecreptor already has so I removed the corresponding setter for the time being but I'm willing to put it back if it turns out to be really beneficial.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Wed Dec 13 10:52:26 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.