Re: [trans-ws] RE: WSS

[Stephen.Flinter@connectcgs.com]

Ann,

thanks for your comments on this.  While I understand the concept that the
idea of WS-Security (or WSS) should be outside the scope of the WSDL that
we describe, I do think that it is important that we provide guidelines for
those implementing the Trans-WS spec as to what level of security they can
expect.

Specifically, that our spec states that implementations MUST implement some
well defined subset of the WSS spec.  If specific trading partners wish to
implement a more robust form of security (i.e. more components of the WS-*
stack) then they can do so.  However, I fear that if we leave it entirely
open as to what (if any) security mechanisms are to be put in place, then
different service providers will offer different types of security, and
hence the clients of these services may be incompatible - even if they
fully comply with the specs laid down by Trans-WS.

My own preference (as brought up in a mail I received from Eve Maler from
the SAML TC, which I forwarded to this mailing list) is that we would make
reference to parts of the relevant specs in the narrative of our spec.

Regards,

Steve

---------------------------------------------
Stephen Flinter
Connect Global Solutions
[t] +353 (0)1 882 9038
[f] +353 (0)1 882 9050
[m] +353 87 798 1228
[e] stephen.flinter@connectcgs.com
[w] www.connectcgs.com
--------------------------------------------


                                                                                                                                              
                      Anne Thomas Manes                                                                                                       
                      <anne@manes.net>         To:       Stephen.Flinter@connectcgs.com, trans-ws@lists.oasis-open.org                        
                                               cc:                                                                                            
                      18/09/2003 13:44         Subject:  Re: [trans-ws] RE: WSS                                                               
                                                                                                                                              
                                                                                                                                              




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