RE: [trans-ws] RE: WSS

["Gerard Cattin des Bois" <gcatt@windows.microsoft.com>]

 Ann,
Regarding the following statement:
"You should leave decisions about security to the folks that implement the standard. They should determine what authentication mechanisms they require for their services."

I believe Stephen is correct. We do need to specify what level of implementation we expect between vendors and software suppliers during those transactions. Specifically, some items are more private than others, and we should recommend different levels of security for these different scenarios. Establishing a recommended security practice for each scenario makes our spec more relevant and increases software compatibility and interoperability. The clearer the expectation, the more software will work together.

Regarding your comment on the message-level support of WS-Security: Good point. If a particular implementation decides to use one of these add-ons to satisfy the recommended security level, that's good re-use of existing software. Security in this instance becomes a packaging issue. Using WS-Security Add-ons may also speed WS-Trans spec implementation. Both are great.
Cheers,
-Gérard 




-----Original Message-----
From: Stephen.Flinter@connectcgs.com [mailto:Stephen.Flinter@connectcgs.com] 
Sent: Thursday, September 18, 2003 8:46 AM
To: trans-ws@lists.oasis-open.org
Subject: Re: [trans-ws] RE: WSS






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






To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/trans-ws/members/leave_workgroup.php.