Kirill's notes

Control generated WSDL in WCF - Part 1. Namespaces.

kirill-gavrylyuk — Sun, 18 Jun 2006 17:08:00 GMT

How to control WSDL namespaces in WCF is a common question, so I will tackle this first. I will assume WSDL basics to be known.

WSDLs exported by WCF

WCF services by default export a tree of WSDLs, i.e. several WSDLs, imported one from another using wsdl:import construct.

This is because different WSDL elements exported by WCF service have different lifecycles: wsdl:service, wsdl:binding, wsdl:portType and schemas. For example schemas are prescribed by vertical industry standard; contract is written once for all providers; binding is prescribed by a vertical industry standard; service is implemented by individual provider.

Each of these WSDL elements has a namespace uri associated with it. In WSDL such namespace uri is assigned by the @targetNamespace attribute on <wsdl:definitions> root that contains one of these elements. Hence there are four types of namespaces in WSDLs generated by WCF.

There is always one WSDL generated for one target namespace URI. I.e. if the namespaces uris match for wsdl:portType and wsdl:binding , these elements are bundled into the same WSDL. XML Schemas are always exported as separate documents.

Compatibility note:

wsdl:import – the construct that allows to build the WSDL tree and put wsdl:service, wsdl:binding and wsdl:portType into different namespaces - was not very well supported by early toolkits. For example if your service is required to be consumed by early versions of InfoPath or Visual Studio ATL sproxy.exe tool, you will need to set the target namespaces for wsdl:service, wsdl:binding and wsdl:portType to the same URI.

Control WSDL Namespaces

Here is how you control target namespaces for wsdl:service, wsdl:binding , wsdl:portType and schemas. WSDL has also wsdl:message – those are bundled together with the wsdl:portType

Service namespace

This is the target namespace of the root WSDL where <wsdl:service…/> element resides containing endpoints (<wsdl:port>)

Code

Set via ServiceBehavior attribute on the service class (not the contract!)

[ServiceBehavior(Name="MyService", Namespace="http://myservice.com/",

ConfigurationName="MyServiceConfiguration")]

public class MyService : IMyServiceContract

default for ConfigurationName (used in config) and Name (exported name into WSDL) is the name of the class. Default for the namespace is the “http://tempuri.org”

WSDL

<wsdl:definitions name="MyService" targetNamespace="http://myservice.com/" …>

...

<wsdl:service name="MyService">

...

Note, we had an unfortunate bug in RC0 that caused stack overflow when you used this setting. This is fixed in later bits.

Binding namespace

This is the target namespace for the WSDL that contains wsdl:binding elements. wsdl:binding is where WCF exports bindings together with certain serialization aspects.

Config

<endpoint name="MyServiceEndpoint"

bindingNamespace="http://myservice.com/binding"

contract="Namespaces.MyServiceContract" ...>

Code

Binding b = new CustomBinding();

b.Namespace = "http://myservice.com/binding";

se = sh.AddServiceEndpoint(typeof(MyServiceContract), b, "http://myservice.com:8080");

WSDL

<wsdl:definitions targetNamespace="http://myservice.com/binding" …>

...

<wsdl:binding name="MyServiceEndpoint">

...

Contract namespace

This is the target namespace for the WSDL that contains wsdl:portType . ServiceContract is exported there.

Code

[ServiceContract(Name = "MyServiceContract", Namespace = "http://gadgets.org/contract")]

public interface MyServiceContract {}

WSDL

<wsdl:definitions targetNamespace="http://gadgets.org/contract">

...

<wsdl:portType name="MyServiceContract">

...

Schema namespace

DataContract types , XmlSeriazer types and wrapper elements defined by MessageContract are being exported into schemas. Schemas namespace are set on individual DataContract , XmlSerializer or MessageContract attributes.

Code

[DataContract(Name="Order", Namespace="http://gadgets.org/types")]

public class Order

{

[DataMember]

public string Id;

}

[MessageContract(IsWrapped = true, WrapperNamespace="http://gadgets.org/messages")]

public class MyServiceUpdateRequest

{

[MessageBodyMember(Namespace = "http://startrek.net/messages")]

public Order Order;

}

WSDL

wsdl:types is always put into the same WSDL as wsdl:portType. It always contains a single xsd:schema referencing all the schemas used by that portType.

<wsdl:definitions targetNamespace="http://gadgets.org/contract">

<wsdl:types>

<xsd:schema targetNamespace="http://gadgets.org/contract/Imports">

<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd0" namespace="http://gadgets.org/messages"/>

<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd1"

namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>

<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd2" namespace="http://gadgets.org/types"/>

</xsd:schema>

</wsdl:types>

<wsdl:message name="MyServiceUpdateRequest">

<wsdl:part name="parameters" element="q1:MyServiceUpdateRequest" xmlns:q1="http://gadgets.org/messages"/>

</wsdl:message>

XSD

<xs:schema elementFormDefault="qualified" targetNamespace="http://gadgets.org/messages" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://gadgets.org/messages">

<xs:import schemaLocation="http://localhost:8080/?xsd=xsd2" namespace="http://gadgets.org/types"/>

<xs:element name="MyServiceUpdateRequest">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="0" name="Order" nillable="true" type="q1:Order" xmlns:q1="http://gadgets.org/types"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

<xs:schema elementFormDefault="qualified" targetNamespace="http://gadgets.org/types" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://gadgets.org/types">

<xs:complexType name="Order">

<xs:sequence/>

</xs:complexType>

<xs:element name="Order" nillable="true" type="tns:Order"/>

</xs:schema>

Note there is the third schema whenever you use DataContract / XmlFormatter as a formatter for your service contract. This defines several helper elements and types for certain CLR types schema representation.

Control generated WSDL WCF

kirill-gavrylyuk — Sun, 18 Jun 2006 17:04:00 GMT

There were many questions recently on how to control various aspects of WSDL (metadata) generated by WCF services.

There are three phases one can use:

1) Design time: settings on data contract, message contract, service contract, service behavior, binding,

2) Runtime: implement IWsdlImportExtension and work with ServiceDescriptionCollection inside BeforeImport call.

3) Runtime: substitute your own MetadataImporter and party on.

The following two posts I will dedicate to #1.

TechEd 2006: WCF Interop sessions with Oracle and Sun

kirill-gavrylyuk — Tue, 13 Jun 2006 05:29:00 GMT

Wednesday June 14th 8:30 / 9:30 myself and Nilesh Junnarkar from Oracle will show Interoperability between WCF and Oracle Fusion MiddleWare on Secure Reliable and Binary web services.

CON319 - (WinFX) Windows Communication Foundation: Building Interoperable Services

Room 153ABC. Wed June 14th, 8:30am - 9:45am.

We show interop between Java and .Net quite often, but usually use pure .Net "hello world" app talking to Java "hello world" service. In reality folks want to see Office talking to SAP/Oracle/DB2/SQL backends.

This year we're up to the challenge and will include Excel app invoking Java web services hosted on Oracle Fusion app server securely and reliably via WCF Service Moniker.

Scenario will include Infocard authentication and basic WS-Federation exchange.

Right next to it, at chalk talk:

CONTLC37 - Enterprise Web Services Interoperability between .NET and Java Using WCF and Sun's GlassFish

Connected Systems Theater, Blue Arena in TLC, Wed June 14th, 14:00 - 15:15

myself and Gerald Beuchelt will show set of demos with Sun GlassFish/WSIT code - repeat from JavaOne 2006, but not only. The jewel in certain sense will be Gerald's FIFI - Fast Infoset channel for WCF. If you're into how to make webservices fast yet interoperable, should be interesting discussion.

Kavita has full list of chalk talk sessions here

WCF and InfoCards at JavaOne 2006

kirill-gavrylyuk — Tue, 16 May 2006 06:05:00 GMT

This is the second year Microsoft actively participates at JavaOne. Monday was a long day of endless installation hassle and frustration:), but tomorrow will be fun. Expect significant progress on interoperability in core WS-* protocols and identity space between WCF and Java to be demostrated.

1) In the Jonathan Schwartz / Jeff Jackson’s keynote 9:20-10:10am myself and Sun Tango team will demo InfoCard & WCF interoperating with Sun Java Web Services and Security Token Service (Identity provider) built using Tango project; as well as Java and WCF services and Identity Providers interoperating on Secure RM exchange with Federated Trust. Single Sign-On and Federated Trust interop between MS and Sun at JavaOne is another encouraging sign of convergence in the area of Identity.

2) In the following session TS-5540, 11am, Esplanade,307-310 we will drill into the keynote demo and cover interoperability between WCF / InfoCard and Sun GlassFish stack on a fairly involved business integration scenario featuring: MTOM, WS-Security 1.1/SecureConversation/WS-Trust, Secure RM, Secure MTOM.

3) In the evening, BOF-2477, 9:30-10:20pm, Hall E-135, Mike Jones and I will participate together with Sun folks in the BOF dedicated to Web Services Security and Identity.

more - later

Looking for Interop PM

kirill-gavrylyuk — Fri, 06 Jan 2006 18:46:00 GMT

In WCF (Indigo) we are taking interop seriously. Given the scale of Indigo, the WS-* architecture and future plans, there is work to do. I am looking for an energetic strong technical program manager passionated about distributed systems, web services and interoperability to help me on this endeavour. If you are it, you're welcome to drop me a note at kirillg_public@hotmail.com (or my ms alias), while we're waiting for the job description to propagate to members.microsoft.com/careers .

Job ad is pasted here:

The Windows Communication Foundation (WCF, aka “Indigo”) is Microsoft’s next generation distributed application platform. Join the Indigo team and make cross platform interoperability a reality for WCF. Enterprise solutions are never based on one platform. As illustrated by the "Building Software That Is Interoperable By Design" mail from Bill Gates and with almost every distributed platform feature decision we are betting success of our enterprise business on interoperability.

You will engage with product teams from our industry partners driving interoperability between our respective platforms. You will be involved in analyzing and addressing customer requirements in the product, working on tools that help diagnose interoperability issues as well as improve interoperability experience for enterprise developers. This effort will affect the WCF programming model, and will focus on ensuring that developers are productive building interoperable Enterprise-grade distributed applications. This is a highly challenging technical position with a great deal of interaction with architecture, development, and test teams as well as a significant percentage of coding required implementing the tools.

This position requires strong design skills, excellent communication skills (you will interact frequently with internal/external customers) and the ability to make the right feature tradeoffs. A passion for SOAP interoperability across vendor stacks and a solid software development or/and computer science background are required. Familiarity with Microsoft .NET technologies (such as C#, .NET Framework and the CLR) and/or competitive offerings (Java, J2EE, WebLogic or WebSphere) is a strong plus.

PDC 2005 reflections

kirill-gavrylyuk — Thu, 06 Oct 2005 04:40:00 GMT

While preparing for PDC then decompressing after it, I completely forgot about blogging. It was a great event. A number of intriguing conversations about Web Services, Security, interop.

We did a talk with Simon where I played Dr. WCF and he was the patient. Interesting demos involving interop on Security, Secure MTOM, Secure RM with WebLogic and Apache Axis:

In the first demo we were showing off new HL7 wizard (software factory) in Whidbey that allows you to pick exact use-case and generate HL7 WSDLs for it. Really cool stuff, especially if you know the complexity of HL7 WSDLs and schemas - don't try to put them together by hand..

The second demo we accessed a service running on WebLogic for patient's record locator info (EMR pointer).The EMR was pointing to a service running Apache Axis 2.0 + WSS4J that we queried for an XRay using Secure MTOM.

The third demo was taking Simon's heartbeat measurements using real Nellcor device and sending them using Indigo over Secure RM to a service running Apache Axis 1.3, Sandesha and WSS4J.

Dims has the Apache Axis part of 2nd and 3rd demos here.

We will post the WCF (Indigo) part closer to B2 release. The most fun of course was preparation of those demos...:) Dims is just plain awesome to work with.

Our slides are available here, including the infamous BIG WS-* TENT.

Indigo / Windows Communication Foundation (WCF) Interop Plug-fest - 7-10 Nov 2005

kirill-gavrylyuk — Thu, 06 Oct 2005 00:01:00 GMT

We are planning a 4-day Windows Communications Foundation (WCF, a.k.a Indigo) Interop Plug-fest on Monday November 7, 2005 to Thursday November 10, 2005 at Microsoft Redmond campus.

The WCF (Indigo) Interop Plug-fest is an ad-hoc, open forum for implementers of various Web Services protocols to meet with engineers from the WCF(Indigo) team and test interoperability with the upcoming release.

Please send mail to kirillg@microsoft.com and jthelin@microsoft.com introducing your implementation if you’re interested in attending.

Scenarios drafts as well as pointers to test endpoints are available online - http://mssoapinterop.org/ilab/wcfinteroplab.htm . We recommend you to join the WS-Builders@yahoogroups.com discussion group and use it for questions around scenarios documents and WCF(Indigo) interoperability.

Here is an invite with further logistics info: http://mssoapinterop.org/ilab/WCFInteropPlugFest_invite.doc

Attending ExpoLinux 2005

kirill-gavrylyuk — Wed, 10 Aug 2005 01:26:00 GMT

I decided to attend ExpoLinux 2005 ( http://www.expolinux.org/ ) to show some examples of leveraging web services interop using .Net and Java . Naturally all the demos will be Indigo-based on .Net side. Never been on Linux-focused conference before. I'm excited.

I hear frequent questions nowdays on what does MS do on Linux conferences? I think the answer is simple - customers need practical solutions to integrate apps running the two platforms. It does not do any good to ignore the problem and force customers to make a binary choice. So we're there to help. No difference then interoperability work with WebSphere or Apache Axis.

Lax vs Strict on read

kirill-gavrylyuk — Sat, 21 May 2005 03:27:00 GMT

Your interop experience with Indigo (especially the upcoming drop or if you have been on one of the interop workshops) may lead you to say “man this thing is strict:”. Indigo rejects many invalid messages that other toolkits would accept.

The key reason for being strict on read is to keep the protocols architecture simple and viable long term. Look at the browsers world - so much invalid html can be happily accepted, that it is simply impossible to describe the established profile. And therefore it is very hard to build a new implementation/fix existing implementations that would not break someone's page. We should make web services future cleaner.

If you really need Indigo to consume some invalid message, Vipul shared a great post here that will help.

WS-Management interop workshop May 16th - 20th

kirill-gavrylyuk — Sat, 21 May 2005 03:13:00 GMT

This week (May 16th - 20th) we held WS-Management interop workshop in Redmond. Indigo participated among others. Three things I liked about this workshop:

1) Atmosphere - it's all about getting things to work, very much like in old soapbuilders days, pure interop fest. Sure there are some agreements to sign to ensure that feedback provided does not limit broad availability (as one of my favorite folks at MS put “welcome to 21st century”), but everything else is very informal.

2) Presence of both software and hardware among the 13 participating implementations. This trully shows the spec is mature and is set to succeed.Interoperability rate accomplished was impressive.

3) Imagine being able to discover everything about management interfaces without having to search the web about what particular methods this resource exposes and what types it works with. Indigo will provide great development framework for the WS-Management interfaces. Add Web Reference experience, generated Indigo proxy and VS intellisense - everything you need to explore management interfaces.

Another comment about WS-I BP and WS-*

kirill-gavrylyuk — Thu, 12 May 2005 05:08:00 GMT

Tim poses a great question about Basic Profile, SOAP1.2/WS-* protocols and Indigo. Tim mentions SOAP 1.2 as the main differentiator between BP1.1 and Indigo WsProfileBinding. SOAP1.2 is a good choice for WS-* simply because it's a cleaner spec. Take for example the SOAP Header fault singularity in SOAP1.1 and what a nightmare it brings into WS-* world:)

Another issue with using BP for WS-* and app protocols going forward is BP1.1 R2710 and the definition of the “wire signature“.

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another.

The Profile defines the "wire signature" of an operation in a wsdl:binding to be the fully qualified name of the child element of the soap:Body of the SOAP input message it describes. For the case of an empty soap:Body this name is an empty string.

The goal I believe was to allow to differentiate incoming soap messages based on the message content itself. An unfortunate side effect is that Profile singles out Body, but does not treat headers targeted at the ultimate destination as part of the wire signature. While SOAP 1.1 spec explicitly states:

A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of "1".

Same I believe can be said (while not explicitly stated) for SOAP1.2 processing of the Body. This BP1.1/1.0 inconsistency with the underlying SOAP spec makes BP1.1 hardly useable for WS-* scenarios.

As Tim mentions in the comment to his blog, Indigo does provide BP1.1 compliant binding, called BasicProfileBinding.

Indigo March CTP interop troubleshooting notes

kirill-gavrylyuk — Thu, 12 May 2005 04:33:00 GMT

This is belated, but I felt was important to get out. Simon Fell made couple firm but fair comments on Indigo March CTP interop (thanks for feedback:) ).

Here are some troubleshooting notes on the CTP interop and update on what to expect in upcoming next Indigo public drop, mostly repeating my offline discussion with Simon.

1) As noted by many, you need to always use
svcutil.exe /uxs <url>
switch when you import wsdl not generated by Indigo. When complex types are used, you need to use
svcutil.exe /tm /uxs <url>
to generate typed messages. This will be still true in next Indigo public drop.

2) Element order while serializing request.
svcutil.exe has a bug where it will not preserve the order of the children of the direct child of the Body when /tm switch is used. Instead it will serialize fields alphabetically. For example, schema is:

<complexType name="login">
<sequence>
    <element name="user" type="xs:string"/>
    <element name="password" type="xs:string"/>
</sequence>
</complexType>
We generate
[System.ServiceModel.MessageContractAttribute()]
public class login_RequestMessage
{
    [System.ServiceModel.MessageBodyAttribute(Namespace = "...")]
    public string username;

    [System.ServiceModel.MessageBodyAttribute(Namespace = "...")]
    public string password;
}
and serialize invalid instance:
<foo>
   <password>..</password>
   <user>...</password>
</foo>

The reason is:
with /tm switch we map the direct child of the body to a class that supports MessageContract. MessageBody attribute for MessageContract class fields has additional parameter “Position” that svcutil.exe "forgets" to emit.

Workaround: add inside the proxy Position parameter to MessageBody attribute:

[System.ServiceModel.MessageContractAttribute()]
public class login_RequestMessage
{
[System.ServiceModel.MessageBodyAttribute(Namespace = "urn:enterprise.soap.sforce.com", Position = 0)]
public string username;

[System.ServiceModel.MessageBodyAttribute(Namespace = "urn:enterprise.soap.sforce.com", Position = 1)]
public string password;
}

The message would become correct. Unfortunately this bug will be present in the next Indigo public drop as well.

3) generated SOAPAction header does not match WSDL.
This has been fixed in upcoming CTP.

4) Exception during deserialization of the fault content.

In March CTP bits we had problems with parsing <detail> element as well as handling whitespaces inside elements. This has been fixed in next Indigo public drop. We translate Fault into “UnknownFault” exception with access to fault info.

5) the generated proxy for operations that are maxOccurs="unbound" don't generate an array in the generated xxx_RequestMessage object
Bug in March CTP bits, fixed in the next Indigo public drop

6) endpoint URL is in WSDL but doesn't end up in the generated proxy anywhere
this is by design – we generate address into config. The idea is that everything from wsdl:binding and wsdl:port goes into config (except for settings that impact serialization and action URIs), since it can change from deployment to deployment.

7) How do I change proxy to use https?

In addition to changing the url, you need to use httpsTransport inside <customBinding> or use BasicSecurityProfileBinding (changed it in B1 to be just an attribute on the BasicProfileBinding). In the next Indigo public drop svcutil.exe correctly generates one or another in the config based on the url.

How do I change key wrap and encryption algorithms in WSE2.0?

kirill-gavrylyuk — Thu, 14 Apr 2005 08:02:00 GMT

Related to my previous blog on WS-Security interop with WebSphere.

Recommended combination of the crypto algorithms is AES256 for symmetric encryption and RSA-OAEP for key-wrap. In Indigo for example, this is the default Algorithm suite used. WSE2.0 used RSA1.5 + AES128 by default, which will most likely change in WSE3.0.

However, there isn't a great deal of commonality yet in what defaults different WS-Security toolkits use. Here is how to configure WSE to use other encryption and key-wrap algorithms.

For example, to make WSE to use TripleDes for encryption and/or RSA-OAEP for key transfer, add the following in config:

<microsoft.web.services2>
...
<security>
   ....
     <binarySecurityTokenManager
          valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
        <sessionKeyAlgorithm name="TripleDES"/> 
        <keyAlgorithm name="RSAOAEP"/>          
     </binarySecurityTokenManager>
</security>
...
<microsoft.web.services2>

or in code:

ISecurityTokenManager stm = SecurityTokenManager.GetSecurityTokenManagerByTokenType(WSTrust.TokenTypes.X509v3);
stm.DefaultSessionKeyAlgorithm = "TripleDES";
stm.DefaultKeyAlgorithm = "RSAOAEP";

WS-Security, WSE2.0 SP3 and WebSphere 6.0

kirill-gavrylyuk — Thu, 14 Apr 2005 06:47:00 GMT

I'm sure WS fans applaud when IBM released WebSphere 6.0 last December with support for WS-Security. Finally IBM and Microsoft support the same version of a WS-* protocol other then SOAP and WSDL in their mainline supported products.

So how can we make them work?

Consider the following three basic WS-Security scenarios supported by both products

1. UsernameToken sent over HTTPS. UsernameToken is used for client authentication, HTTPS is used for message protection. Beneficial for the internet deployments, supersedes HTTP Basic Auth over HTTPS, as incorporates token in the message, allows to flow the token end to end, allows for multiple tokens.

In order to configure WSE 2.0 SP3 to consume UsernameToken from WebSphere, one needs to send Password in Text and disable WSE replayDetection feature as discussed here . The reverse (sending UsernameToken from WSE2.0 client to WebSphere 6.0 service) does not require any config changes.

2. X509 Signing. Requestor signs a request using private key associated with Requestor's X509v3 certificate. Responder verifies the message signature using the public key associated with Requestor's certificate.

To make WebSphere 6.0 and WSE2.0 interoperate on this scenario, one needs to set on WebSphere 6.0 side (on the Security config tab) the BinarySecurityToken token type to be “http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3” - the value from the OASIS WSS1.0 standard. The default setting in WebSphere 6.0 is “…#X509” which was introduced in the non-normative errata from TC and would not interoperate with WSE2.0 SP3.

3. X509 Mutual Authentication, Sign then Encrypt. Client and Service each have a cert, representing their identities. Client authentication is provided using Client's certificate. Server's authentication is provided using Server's cert. Request is signed using private key corresponding to the Client's certificate then encrypted using ephemeral key K1 wrapped for Server's certificate. Response is signed using private key of Server;s certificate then encrypted using ephemeral key K2 wrapped for Client's cert. This is a great scenario for server to server (B2B) communication. Or if the client app relies on PKI infrastructure (e.g. smartcards).

There is unfortunately no way to make WSE2.0 SP3 and WebSphere 6.0 interoperate on Scenario #3 due to breaking differences between the OASIS WSS X509 Token Profile 1.0 standard that WSE2.0 SP3 implements and OASIS WSS X509 Token Profile 1.0 non-normative errata that WebSphere 6.0 followed. Specifically the issue is in the different URIs used for KeyIdentifier/@ValueType in an external reference to the wrapping X509 token inside EncryptedKey. OASIS TC is aware of the problem with errata and is working to resolve the issue and remove breaking changes from errata. IBM is aware of the issue and plans to have a fix in the next service pack to support OASIS WSS 1.0

WSE2.0 SP3 and Interop on UsernameToken

kirill-gavrylyuk — Tue, 12 Apr 2005 10:47:00 GMT

One of the most common problems folks run into when using WSE2.0 together with other WS-Security toolkits is interop on UsernameToken.

Consider a simple scenario:

UsernameToken sent over HTTPS. UsernameToken is used for client authentication, HTTPS is used for message protection. Beneficial for the internet deployments, supersedes HTTP Basic Auth over HTTPS, as incorporates token in the message, allows to flow the token end to end, allows for multiple tokens.

WSE2.0 supports all three forms of sending password inside UsernameToken: None, Hashed, Text. I recommend to always use Text and protect the password using other means (transport or message-level encryption) to maximize interop.

In order to configure WSE 2.0 SP3 to consume UsernameToken from products like WebSphere or WebLogic, one needs to disable WSE replayDetection feature, i.e. add the following to your config:

<microsoft.web.services2>
...
       <security>
           ...
         <securityTokenManager                      xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"              qname="wsse:UsernameToken">
            <replayDetection enabled="false"/>
         </securityTokenManager>
          ...
       </security>
     ...
</microsoft.web.services2>