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
