RE: [ws-rx] New Issue: security profiles

["Raepple, Martin" <martin.raepple@sap.com>]

Gil,

 

I want to share some initial thoughts when I read through the new security proposals. From my understanding, the motivation for the profile approach is its simplicity when it comes to the determination of supported profiles at runtime (as described in [2]) and endpoint metadata description (as described in [3]) by simply referring to the profile URI that uniquely identifies the supported security composition profile.

 

Based on the security profile descriptions defined in [1] and the mechanisms provided in [2] and [3], I doubt that they can guarantee interoperability between the RMS and RMD, because the profile URI on its own won't provide sufficient information to automate the security configuration of the messages. Even though this approach might work for the transport security profiles (due to the automated metadata exchange in the SSL/TLS handshake protocol), for example the security bootstrap described in step 1 of the WS-SecureConversation (WS-SC) Profile [1] requires more information for the RMS than currently provided by the policy assertion or the <SecurityComposition> element.

 

As an example, the RMD might not be able to issue Security Context Tokens for WS-SC and thus depends on a third party token issuer which needs to be advertised to the RMS. Or, the RMS might not support the use of derived keys in WS-SC which needs to be stated somewhere. One can extend this list with a number of other configuration settings which are not yet defined either in the profile description or configurable via the policy assertions.

 

I could think of two ways to approach this issue:

 

a) The profiles (in particular the message security / WS-SC profile) provide more details in terms of algorithm suites, token properties, token issuing etc. However, it would be impossible to generalize all potential configurations. Therefore, the intention of this approach can only be a recommendation in terms of 'best practices' and not a guarantee for interoperability

 

b) Instead of defining RM-specific security policy assertions, the security profiles are translated to the corresponding assertions in WS SecurityPolicy (SP) 1.2 (e.g. with a recommendation provided by the specification in terms of SP assertions, e.g. the SecureConversationToken assertion for the WS-SC Profile and TransportBinding assertion for the SSL/TLS profiles). Compared to a), this approach at least will cover (hopefully!) all possible configurations for the profiles and thus better supports automated configuration and interoperability. Indeed, this means that the use of the profile URI in the profile agreement at runtime would be obsolete.

 

Cheers,

Martin

 

[1] security profiles, http://lists.oasis-open.org/archives/ws-rx/200605/msg00097.html

[2] security profile agreement, http://lists.oasis-open.org/archives/ws-rx/200605/msg00098.html

[3] security composition policy, http://lists.oasis-open.org/archives/ws-rx/200605/msg00099.html

 

 

Martin Raepple
Platform Ecosystem Industry Standards
SAP AG
mailto: martin.raepple@sap.com
 

---

From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Dienstag, 9. Mai 2006 23:42
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] New Issue: security profiles

The WS-RX TC Charter requires that WS-RM support the “efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms”. The charter also states that “While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.” This proposal attempts to satisfy these two requirements by defining a set of non-normative profiles for composing WS-RM with commonly used web services security mechanisms. The purpose is to aid in the implementation and deployment of interoperable services and applications that utilize secure, reliable SOAP messaging systems.

 

Proposal: Add the attached text as a new chapter to the WS-RM specification following Chapter 5 (Security Threats and Requirements)