You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by George Stanchev <gs...@serena.com> on 2009/05/29 21:47:56 UTC
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
Re: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.
Posted by Marc Tremblay <ma...@8020solutions.com>.
Actually, it was George who pointed out to me that the qualified and
unqualified forms are different as far as XML is concerned.
I think ideally, WSS4J would need to be configurable by the service provider
as to what should happen when the wsse:Type attribute is present. If you
don't need/want to accommodate VS 2008/WCF clients then the current
behaviour is correct. However, from a practical point of view, it would be
nice to be able to configure WSS4J to accept wsse:Type when Type is absent.
Naturally, this would imply that there couldn't be application specific
semantics to a wsse:Type attribute.
Perhaps it would make sense to implement this as a distinct
UsernameTokenProcessor so as to not contaminate the current one with
deviations from the spec?
I wouldn't expect the default behaviour to accept wsse:Type, but a simple
FAQ entry could refer to this other UsernameTokenProcessor and point people
to the appropriate place to bug MS to fix WCF.
M.
On Sat, May 30, 2009 at 3:01 AM, Werner Dittmann <
Werner.Dittmann@t-online.de> wrote:
> Just some info about "MS compatibility modes": some time ago (in
> WSS4J 1.0) we had built in a specific MS proprietary mode for
> password handling. This mode caused several problems later about
> interoperability with other, non-MS implementations.
>
> Implementing a MS-specific handling could also lead to interop
> problems with other implementations that are compliant to the spec.
>
> As Marc said "wsse:Type" and "Type" and different entities. The
> spec allows to specify _additional_ implementation specific
> attributes. If an implementation now adds such an attribute and uses
> "wsse:Type" for its purposes - what should WSS4J then do? Is it
> a "MS misbehaviour" and interpret it as the standard password type
> or leave interpretation and handling to the specific implementation?
>
> That's why XML has name spaces and why implementation must use
> name spaces in the correct way.
>
> Best Regards,
> Werner
>
>
> Marc Tremblay schrieb:
> > Interesting. Not what I'd expect, but I'm sure there's a reason for it.
> >
> > It's really too bad then that for having been involved in drafting the
> > UsernameToken Profile 1.1 spec that MS would mess up their implementation
> in
> > WCF.
> >
> > So what would make the most sense as an approach to accommodate the
> > qualified Type attribute? An allowQualifiedPasswordType field, or
> something
> > more general perhaps?
> >
> > M.
> >
> > On Fri, May 29, 2009 at 4:54 PM, George Stanchev <gstanchev@serena.com
> >wrote:
> >
> >> It is not redundant. Read the XML specs. Password is an element. While
> >> non-qualified subelements of a qualified element do inherit the
> qualified's
> >> parent namespace, this is not true for attributes. Attributes that are
> not
> >> explictly namespace-qualified do not inherit automatically the namespace
> of
> >> the element they are declared in. No namspace means excacly this - no
> >> namespace, not implictly inherit the namespace of its element [1].
> According
> >> to the specs, attributes "wsse:Type" and "Type" are two different
> entities.
> >>
> >> George
> >>
> >>
> >> [1] http://www.w3.org/TR/xml-names/#uniqAttrs
> >>
> >> ------------------------------
> >> *From:* Marc Tremblay [mailto:marc.tremblay@8020solutions.com]
> >> *Sent:* Friday, May 29, 2009 2:24 PM
> >> *To:* George Stanchev
> >> *Cc:* wss4j-dev@ws.apache.org
> >> *Subject:* Re: WSS-148 WCF interop issue: Namespace not honored incase
> of
> >> attributes.
> >>
> >> I agree that's how the spec is written, but qualifying Type with the
> same
> >> namespace as Password, while redundant, doesn't change the semantics as
> far
> >> as XML is concerned. As the spec doesn't specifically forbid namespace
> >> qualifying Type, I would expect non-qualified and redundantly qualified
> >> forms to be treated as equivalent.
> >>
> >> Or am I failing to understand how XML works?
> >>
> >> M.
> >>
> >> On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gstanchev@serena.com
> >wrote:
> >>
> >>> 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
> >>>
> >>
> >
>
>
Re: WSS-148 WCF interop issue: Namespace not honored incase of attributes.
Posted by Werner Dittmann <We...@t-online.de>.
Just some info about "MS compatibility modes": some time ago (in
WSS4J 1.0) we had built in a specific MS proprietary mode for
password handling. This mode caused several problems later about
interoperability with other, non-MS implementations.
Implementing a MS-specific handling could also lead to interop
problems with other implementations that are compliant to the spec.
As Marc said "wsse:Type" and "Type" and different entities. The
spec allows to specify _additional_ implementation specific
attributes. If an implementation now adds such an attribute and uses
"wsse:Type" for its purposes - what should WSS4J then do? Is it
a "MS misbehaviour" and interpret it as the standard password type
or leave interpretation and handling to the specific implementation?
That's why XML has name spaces and why implementation must use
name spaces in the correct way.
Best Regards,
Werner
Marc Tremblay schrieb:
> Interesting. Not what I'd expect, but I'm sure there's a reason for it.
>
> It's really too bad then that for having been involved in drafting the
> UsernameToken Profile 1.1 spec that MS would mess up their implementation in
> WCF.
>
> So what would make the most sense as an approach to accommodate the
> qualified Type attribute? An allowQualifiedPasswordType field, or something
> more general perhaps?
>
> M.
>
> On Fri, May 29, 2009 at 4:54 PM, George Stanchev <gs...@serena.com>wrote:
>
>> It is not redundant. Read the XML specs. Password is an element. While
>> non-qualified subelements of a qualified element do inherit the qualified's
>> parent namespace, this is not true for attributes. Attributes that are not
>> explictly namespace-qualified do not inherit automatically the namespace of
>> the element they are declared in. No namspace means excacly this - no
>> namespace, not implictly inherit the namespace of its element [1]. According
>> to the specs, attributes "wsse:Type" and "Type" are two different entities.
>>
>> George
>>
>>
>> [1] http://www.w3.org/TR/xml-names/#uniqAttrs
>>
>> ------------------------------
>> *From:* Marc Tremblay [mailto:marc.tremblay@8020solutions.com]
>> *Sent:* Friday, May 29, 2009 2:24 PM
>> *To:* George Stanchev
>> *Cc:* wss4j-dev@ws.apache.org
>> *Subject:* Re: WSS-148 WCF interop issue: Namespace not honored incase of
>> attributes.
>>
>> I agree that's how the spec is written, but qualifying Type with the same
>> namespace as Password, while redundant, doesn't change the semantics as far
>> as XML is concerned. As the spec doesn't specifically forbid namespace
>> qualifying Type, I would expect non-qualified and redundantly qualified
>> forms to be treated as equivalent.
>>
>> Or am I failing to understand how XML works?
>>
>> M.
>>
>> On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gs...@serena.com>wrote:
>>
>>> 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
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.
Posted by Marc Tremblay <ma...@8020solutions.com>.
Interesting. Not what I'd expect, but I'm sure there's a reason for it.
It's really too bad then that for having been involved in drafting the
UsernameToken Profile 1.1 spec that MS would mess up their implementation in
WCF.
So what would make the most sense as an approach to accommodate the
qualified Type attribute? An allowQualifiedPasswordType field, or something
more general perhaps?
M.
On Fri, May 29, 2009 at 4:54 PM, George Stanchev <gs...@serena.com>wrote:
> It is not redundant. Read the XML specs. Password is an element. While
> non-qualified subelements of a qualified element do inherit the qualified's
> parent namespace, this is not true for attributes. Attributes that are not
> explictly namespace-qualified do not inherit automatically the namespace of
> the element they are declared in. No namspace means excacly this - no
> namespace, not implictly inherit the namespace of its element [1]. According
> to the specs, attributes "wsse:Type" and "Type" are two different entities.
>
> George
>
>
> [1] http://www.w3.org/TR/xml-names/#uniqAttrs
>
> ------------------------------
> *From:* Marc Tremblay [mailto:marc.tremblay@8020solutions.com]
> *Sent:* Friday, May 29, 2009 2:24 PM
> *To:* George Stanchev
> *Cc:* wss4j-dev@ws.apache.org
> *Subject:* Re: WSS-148 WCF interop issue: Namespace not honored incase of
> attributes.
>
> I agree that's how the spec is written, but qualifying Type with the same
> namespace as Password, while redundant, doesn't change the semantics as far
> as XML is concerned. As the spec doesn't specifically forbid namespace
> qualifying Type, I would expect non-qualified and redundantly qualified
> forms to be treated as equivalent.
>
> Or am I failing to understand how XML works?
>
> M.
>
> On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gs...@serena.com>wrote:
>
>> 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
>>
>
>
RE: WSS-148 WCF interop issue: Namespace not honored incase of attributes.
Posted by George Stanchev <gs...@serena.com>.
It is not redundant. Read the XML specs. Password is an element. While
non-qualified subelements of a qualified element do inherit the qualified's
parent namespace, this is not true for attributes. Attributes that are not
explictly namespace-qualified do not inherit automatically the namespace of
the element they are declared in. No namspace means excacly this - no
namespace, not implictly inherit the namespace of its element [1]. According
to the specs, attributes "wsse:Type" and "Type" are two different entities.
George
[1] http://www.w3.org/TR/xml-names/#uniqAttrs
_____
From: Marc Tremblay [mailto:marc.tremblay@8020solutions.com]
Sent: Friday, May 29, 2009 2:24 PM
To: George Stanchev
Cc: wss4j-dev@ws.apache.org
Subject: Re: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.
I agree that's how the spec is written, but qualifying Type with the same
namespace as Password, while redundant, doesn't change the semantics as far
as XML is concerned. As the spec doesn't specifically forbid namespace
qualifying Type, I would expect non-qualified and redundantly qualified
forms to be treated as equivalent.
Or am I failing to understand how XML works?
M.
On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gs...@serena.com>
wrote:
>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
Re: WSS-148 WCF interop issue: Namespace not honored incase of
attributes.
Posted by Marc Tremblay <ma...@8020solutions.com>.
I agree that's how the spec is written, but qualifying Type with the same
namespace as Password, while redundant, doesn't change the semantics as far
as XML is concerned. As the spec doesn't specifically forbid namespace
qualifying Type, I would expect non-qualified and redundantly qualified
forms to be treated as equivalent.
Or am I failing to understand how XML works?
M.
On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gs...@serena.com>wrote:
> 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
>
RE: WSS-148 WCF interop issue: Namespace not honored incase of attributes.
Posted by George Stanchev <gs...@serena.com>.
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
RE: WSS-148 WCF interop issue: Namespace not honored incase of attributes.
Posted by Colm O hEigeartaigh <co...@progress.com>.
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