Section 12.10. Interoperability

12.10. Interoperability

Enterprises are adopting Web services to ease application integration across heterogeneous environments within and across domain boundaries. Enterprise security architects must be confident that resources will not be exposed to unauthorized use. Technologies must be integrated with existing security infrastructure.

Web Services Security provides extensible and flexible mechanisms that suit these purposes well. However, these same benefits also make interoperability difficult. The extensibility of WS-Security introduces many options and choices. If different enterprises select different options, they might not be able to interoperate. Some guidelines are needed to limit the possibilities that infrastructures must implement and test in order to interoperate. The Web Services Interoperability (WS-I) organization defines a security profile to meet this requirement.

12.10.1. Basic Security Profile

The WS-I Basic Security Profile (BSP) provides clarifications and amplifications for a set of standards used to secure the transmission of Web services messages. The scope of the first version of the profile will include the following:

• HTTP Security

  • [HTTPS] HTTP over TLS http://www.ietf.org/rfc/rfc2818.txt.

• SOAP Message Security:

  • WSS: SOAP Message Security v1.0The formats (schema) for security tokens, signature elements, encryption elements, their placement in SOAP headers, and references to other elements of the message.

  • WSS: UsernameToken Profile v1.0

  • WSS: X.509 Certificate Token Profile v1.0

  • WSS: SOAP With Attachments Profile (currently in draft)This augments the basic model, with support for encrypting and signing non-XML data in SOAP attachments.

Please note that work is progressing in parallel on profiles that extend the BSP to address

• WSS: REL Token Profile (currently in draft)

• WSS: SAML Token Profile (currently in draft)

Additionally, each of these standards builds on existing standards such as XML Encryption, XML Signature, HTTP, and TLS, bringing them into scope for the profile. These standards are only in scope when used by the higher-level standards.

The framework defined in these standards is extensible and can accommodate a wide range of security models, security tokens, signature formats, and encryption technologies. The flexibility and extensibility of the framework is a challenge for interoperability, however. The BSP focuses on improving interoperability by strengthening requirements when possible (making "shoulds" into "musts"), reducing some of the flexibility (picking one right way when several alternatives are available) and extensibility. This limits the set of common functionality that vendors must implement and test for interoperability.

The guiding principles enumerated in the BSP declare that the profile should do no harm, make statements that are testable when possible, and focus on interoperability. The profile should not try to address any issues in the profiled standards that do not affect interoperability, and enhancing interoperability should not create new security threats.

The profile includes requirement statements about two kinds of artifacts, SECURE_ENVELOPE and SECURE_MESSAGE. A SECURE_ENVELOPE is a SOAP envelope that has been subjected to integrity or confidentiality protection. A SECURE_MESSAGE expands the scope of the SECURE_ENVELOPE to include protocol elements transmitted with the SECURE_ENVELOPE that have been subjected to integrity and/or confidentiality protection.

In order to conform to the BSP, any artifact that contains a construct addressed in the profile must conform to any statements that constrain its use. Conformant receivers are not required to accept all possible conformant messages. Conformance applies to deployed instances of services. Because major portions of the profile might not apply in certain circumstances, individual URIs might be used to indicate conformance to the following parts of the profile: the core profile, username token, X.509 token, and SOAP attachments. Additional URIs will be used as additional token profiles are profiled by the BSP working group (such as SAML, REL, and Kerberos).