Re: [trans-ws] RE: WSS

[Anne Thomas Manes <anne@manes.net>]

Let me add a few more thoughts to the discussion. (I've been lurking from 
the beginning.)

First, WSS SOAP Security -- the product of the WSS TC -- is now a Committee 
Specification. You should see a message from Karl Best in the next few days 
announcing its public review. Most people call WSS SOAP Security 
"WS-Security", which is the reason why Steve was a little fuzzy on the 
distinction between the two. You can retrieve the spec from here:
http://www.oasis-open.org/committees/download.php/3281/WSS-SOAPMessageSecurity-17-082703-merged.pdf

WS-Security is the primary SOAP security standard. It defines the SOAP 
header blocks used to convey security information such as digital 
signatures, encryption key information, and security tokens. As Steve said, 
a WS-Security header can carry many different types of security tokens, 
such as userid/password, SAML tokens, X.509 certs, and XrML licenses. The 
bindings for each of these types of tokens are described in complementary 
specifications. These binding specifications are still in draft form, 
though. For example:
user/pwd: 
http://www.oasis-open.org/committees/download.php/3154/WSS-Username-04-081103-merged.pdf
X.509: 
http://www.oasis-open.org/committees/download.php/3214/WSS-X509%20draft%2010.pdf

Second, I don't think that this team needs to define a security scheme for 
the trans-ws standard. The whole point of developing WS-Security and the 
other WS-* specifications is to take security out of application and 
standards development and to put it into the hands of security administrators.

As part of your standard, you should define the logical operations that you 
want to expose and the schemas for the messages that you will exchange to 
accomplish those operations. In other words, you should be defining only 
<types>, <message>, and <portType> elements in your WSDL files. (SOAP 
headers -- used to pass security credentials -- are specified in the 
<binding> elements. You should not be defining <binding> elements, because 
bindings are specific to an implementation.) You should leave decisions 
about security to the folks that implement the standard. They should 
determine what authentication mechanisms they require for their services.

My recommendation is that you not define any security mechanism, but if you 
think it is a requirement for your specification, you might consider doing 
what the UDDI team did as a catch-all for authentication. They defined an 
optional authentication operation -- get_authToken. It is an 
application-level authentication process rather than message-level 
authentication process. See:
http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm#_Toc25137739

Third, most SOAP implementations support a variety of transport-level 
authentication mechanisms, such as HTTP Basic and HTTP Digest 
authentication, and SSL-based authentication using X.509 certs. An 
increasing number of SOAP implementations also support message-level 
authentication mechanisms using WS-Security. BEA, IBM, Microsoft, Systinet, 
and The Mind Electric currently support WS-Security. A number of add-on 
products, known as XML firewalls or Web services management frameworks, 
also support WS-Security. Examples are from AmberPoint, Confluent, Digital 
Evolution, Forum Systems, Layer 7, Reactivity, WestBridge, and Vordel.

Verisign announced that they would supply an open source implementation of 
WS-Security back in December, but I have not seen the code to date. Sam 
Ruby is initiating a project at Apache to develop one, but it's still in 
the formative stage.

Best regards,
Anne Thomas Manes