ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] New Issue: security profiles
- From: "Raepple, Martin" <martin.raepple@sap.com>
- To: <ws-rx@lists.oasis-open.org>
- Date: Sun, 14 May 2006 15:20:25 +0200
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
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)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]