Soap Headers

SOAP headers convey authentication and localization information from the application client to the server. Soap headers are not used for the reverse direction, from server to client.

Security headers

The Content Engine Web Service (CEWS) complies with the OASIS WS-Security 2004 standard, which, although providing a general purpose mechanism for associating security tokens with messages, does not require the use of any particular type of security token. Separate WS-Security profile specifications are available to define how WS-Security is implemented for different credential types. CEWS supports two WS-Security profiles out of the box: the UsernameToken Profile and the Kerberos Token Profile.

In addition to these two profiles, CEWS can support additional WS-Security credential types, through the use of the Web Service Extensible Authentication (WS-EAF) framework. This framework allows a custom JAAS login module to be developed and plugged into the Content Engine, allowing any valid WS-Security header to be used for authentication. Authoring a WS-EAF login module requires advanced custom development, which is specific to the J2EE application server being used. For more information, see the Web Service Extensible Authentication Framework Developer's Guide.

If your client applications uses the UsernameToken Profile, which requires plaintext credentials (username and password), it is recommended that you configure the server to use SSL (SOAP over HTTPS) in order that this information be protected. See Content Engine Web Service Administration for more information. If you use the Kerberos Token Profile, an SSL connection is not necessary (unless you want to protect your data), as Kerberos does not send client credentials.

Authentication information is carried in a SOAP header, which is present in every SOAP request. The format of the security header conforms to the WS-Security UsernameToken Profile, which requires a UsernameToken element with a required Username and optional Password attribute (omitting the Password attribute is equivalent to supplying a blank password). The client's UsernameToken element must be passed in the SOAP header of each CEWS request according to the WS-Security standard. The server also allows, but does not use, the Created and Nonce elements.

The following example shows the XML schema for a security header:

<wsse:Security xmlns:wsse={see below}>
   <wsse:UsernameToken>
      <wsse:Username>{username}</wsse:Username>
      <wsse:Password>{password}</wsse:Password>
   </wsse:UsernameToken>
</wsse:Security>

The wsse prefix can use any of the following namespaces, reflecting different versions of the WS-Security specification:

Although security is not specified in the WSDL, Microsoft® Visual Studio® provides built-in support for WS-Security with Microsoft Web Services Enhancements (WSE) in its client applications. For more information, see Client-Specific-Information.

Localization headers

The Content Engine Web Service supports the same level of localization as is provided by the Content Engine APIs. To request a locale for rendering metadata strings and other textual information the client can include an optional localization SOAP header in any request. An effective locale derived from a client request is used to select localized strings for metadata elements and display text.

For more information, see Localization Element.