[ws-trans] TC security proposal and notes from last tc meeting

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

During the last TC meeting, we reviewed the WS-Security specs and identified which scenarios we wish to support. We further identified an initial proposal for security within our spec. None of which was voted on yet, but this thread is to recap first and lead to a vote when done.

WS-Security: The goal of this spec is to provide an end-to-end message-level security that achieves three goals: 
(1) to provide message integrity so that the parties involved can guarantee that the message was not modified while in transit thru various routers. Tickets or certificates are passed using the XML Signature spec. 
(2) to provide confidentiality over the message so that the message information cannot be sniffed or read while passing thru or in transit. Confidentiality is implemented using XML Encryption spec. Specifically, WS-Security uses three tags: EncryptedData, EncryptedKey and ReferenceList. 
(3) to provide a way to authenticate each party via security tokens such as username/password, kerberos tickets or x.509 certificate. Username/password require pre-knowledge of each other. 

Following this review, we agreed that by default, we expect to use username/passsword combination over SSL. Still, different systems can behave differently, so we also looked at the WS-SecurityPolicy spec, as described below:

WS-SecurityPolicy: This WS-Security spec provides the basic framework to perform secured tasks. Yet, while two systems can conform to this spec, they can still fail to authenticate each other if one system only supports, say, username/password while the other expects digital signatures. To facilitate exposing what a system can and cannot do, another policy spec was designed: the WS-SecurityPolicy that uses the WS-Policy spec. WS-SeurityPolicy allows a system to specify security policies which defines what message integrity it supports, and/or which encryption algorithm it accepts regarding confidentiality. In essence, the WS-SecurityPolicy tells what a system's implementation of WS-Security expects operate successfully.

Following this review, we agreed to implement the security policy to expose what a system is capable of doing and thereby support various interactions (different vendors for a software provider, or different software providers for a vendor).

WS-Trust: We looked at WS-Trust which defines how to talk to a certificate authority which is a third-party that provides certificates or tickets to validate the other party. Given the nature of the interaction between software providers and localization vendors, this is not a common scenario to support. Consequently, WS-Trust is not recommended to meet WS-Trans security requirements. 

WS-SecureConversation: We also looked at WS-SecureConversation to establish secure context for two applications to a series of operation. This spec provides a session-based security, that is for the duration of the context. This solution services the case where the two systems need to exchange many SOAP messages. This spec therefore specifies how to create and share security context that uses time-limited encryption key. 

Following this review, we debated whether this was a useful and pertinent spec to recommend. Peter argued that most large software providers are moving to shorter delivery cycles with smaller amounts of data to localize at a time. I argued that we still have large quantities of data to localize at a time, sometimes in the terabytes at a time, at least the first time. No real conclusion was drawn, except to say that we may want to revisit this spec in a later revision of the WS-Trans specs. By then, we should have more hands-on experience and be more able to determine whether the secure conversation make sense, and if they do, whether it makes sense to recommend this spec then.

WS-Federation: We did not discuss WS-Federation. However, it is based on WS-Trust, WS-SecureConversation. Not recommending WS-Trust or WS-SecureConversion yet means that we do not recommend WS-Federation. Confirm.

WS-Privacy: We did not discuss this spec. WS-Privacy is an advanced security spec that allows a system to combine WS-Policy, WS-Security, and WS-Trust to state or indicate conformance to company privacy policies. First off, this spec is not a good place to start a web service. It is likely desirable when the system is in place, and the genericity of exchange between the parties becomes more prevalent and numerous. At this time, however, it is not a pressing issues, so I recommend against it. Also, if and when we decide this spec has significant relevance and should be implemented, then we need to also require WS-Trust, which we do not at the moment. Confirm. 

WS-Authorization: This spec was not discussed either. It relies on the WS-Privacy spec and its purpose is to describe how a web service access policies are specified and managed. Unless we agree to require WS-Privacy, I recommend we do not require this spec. This spec may become relevant in the future if and when automating web services become bread and butter to create and manage new and existing business interactions. Confirm.

After discussing which part of the WS-Security series of spec to recommend, we briefly discussed which methods of WS-Trans require security. Basically, we agreed on two things: at first glance, the discovery method is the only method that does not require security. All the other methods do. Second, we will review all methods at another TC meeting for careful assessment of whether they really need security or not.

We also agreed to keep the security requirement in the narrative of the WS-Trans spec. We also agreed that we should provide some samples of web services that include security elements to explicitly show how they are used in the SOAP header along with the rest of the WS-Trans data.

We used Stephen's document below as a starting point for the discussion.

Please feel free to comment and correct my recollection.
-Gérard
><((((º>`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º>¸.


-----Original Message-----
From: Stephen.Flinter@connectcgs.com [mailto:Stephen.Flinter@connectcgs.com] 
Sent: Monday, September 22, 2003 10:09 AM
To: trans-ws@lists.oasis-open.org
Subject: [trans-ws] Security scenarios





Following Gerard's suggestion last week, regarding identifying the security
scenario(s) documented in the IBM/Microsoft paper "Security in a Web Services World" that we wish to adopt, I would advocate the following:

1. That we specify that implementations of the Trans-WS spec MUST implement direct trust using Username/Password and transport-level security.  This is scenario 1 in the paper, and is probably the most straightforward scenario to adopt.
2. Implementations of Trans-WS MAY implement other security scenarios as agreed between the service provider and the users of the service.
3. That we reference the OASIS WSS TC specs as the preferred security standard, as opposed to the IBM/Microsoft WS-Security.  Specifically, that we reference the Web Services Security: SOAP Message Security and Web Services Security: UsernameToken Profile documents, which are issued by the WSS TC, and are currently in committee spec status.
4. For future versions of the Trans-WS spec, we can increase the level of security required, by making additional security scenarios a MUST or SHOULD implement.  We can also reference additional security documents such as SAML, or whatever.

Note, all of the above would only require a narrative in the spec document.
We would not have to make any change to our WSDL file.  All the WSS stuff sits in the SOAP header, and is transparent to the application using it.
Note also, that this means that we wouldn't need a "login" type operation in the WSDL.  By definition, every SOAP message would have to include the necessary token to allow for authentication/authorisation.

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
--------------------------------------------


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.