Re: WSS-148 WCF interop issue: Namespace not honored incase of attributes.

[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
> >>>
> >>
> >
>
>