ws-wss4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Stanchev" <gstanc...@serena.com>
Subject RE: WSS-148 WCF interop issue: Namespace not honored incase of attributes.
Date Mon, 08 Jun 2009 16:32:28 GMT
Hi Colm,
 
In my personal opinion WSS4J has to be shipped standard-compliant by default
out of the box and have any non-standard behavior explicitly turned on -
either programatically or via configuration by the users to avoid
uncompatibility problems that Werner described. Unfortunately I am not
familiar enough with the codebase to suggest an approach for enabling this
though I do agree with you that some programatic way might be the best
approach instead of having a configuration variable.
 
George

  _____  

From: Colm O hEigeartaigh [mailto:coheigea@progress.com] 
Sent: Monday, June 08, 2009 8:01 AM
To: George Stanchev; Marc Tremblay; wss4j-dev@ws.apache.org
Subject: RE: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.



Hi George,

 

Yeah I agree that we need to support these non-standard Username Tokens.
Maybe one way of doing this is to allow a namespace'd Type by default, but
to reject it if WSSConfig.isWsiBSPCompliant() is true? It seems like
overkill to me to add another configuration variable to support a fairly
minor difference. Any opinions?

 

Colm.

 

  _____  

From: George Stanchev [mailto:gstanchev@serena.com] 
Sent: 29 May 2009 20:48
To: 'Marc Tremblay'; wss4j-dev@ws.apache.org
Subject: RE: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.

 

>From the specs:

 

line 239: /wsse:UsernameToken/wsse:Password/@Type

 

The Type attribute is clearly not namespaced. If it were WSS namespaced,
then the line above should have been
/wsse:UsernameToken/wsse:Password/@wsse:Type, but its not. For reference
look at line 328 in the spec and you will see clearly wsu:Id attribute
namespaced properly. 

 

Microsoft is clearly breaking the standard of requiring Type to be
namespaced.

 

That being said, the reality is what it is. I wonder if WSS4J devs would
accept some kind of MS-compatibility mode that is turned off by default but
can be turned on for WCF interoping deployments (may be via configration)...

 

George

 

  _____  

From: Marc Tremblay [mailto:marc.tremblay@8020solutions.com] 
Sent: Friday, May 29, 2009 12:27 PM
To: wss4j-dev@ws.apache.org
Subject: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.

Hello,

I have recently encountered the issue described at
https://issues.apache.org/jira/browse/WSS-148 and am wondering if it doesn't
make sense to allow for the Type attribute to be namespace qualified.

I've examined Page 8 of the Web Services Security, UsernameToken Profile 1.1
spec and while the example XML doesn't namespace qualify the Type attribute,
I don't see anywhere in the spec where it states that the Type attribute
must not be namespace qualified.  If fact there is no mention of namespace
qualifying attributes in the spec that I can see.

As such, I'd like to suggest that WSS-148 be reopened and wss4j modified to
accept both unqualified and namespace qualified Type attributes on the
Password element.

I'd be happy to create the necessary patch.

Thanks,

Marc


Mime
View raw message