Securing Web Services (WS-Security)

WS-Security in Integration Server

Integration Server provides message-based security for SOAP messages using WS-Security. In contrast to transport-based authentication frameworks such as HTTPS, which secure the endpoints of a connection against threats, WS-Security secures the message transmission environment between endpoints. Using both transport-based and message-based security provides more complete end-to-end protection for data passing across public networks.

Integration Server provides two methods for using WS-Security.

  • Using WS-SecurityPolicy.

    Starting with Integration Server version 8.2, you can attach standard WS-SecurityPolicy policies to a web service descriptor. To use this method, the web service must not be running in pre-8.2 compatibility mode (i.e., the web service descriptor Pre-8.2 compatibility mode property must be set to false). For more information, see Securing Web Services Using WS-SecurityPolicy.

  • Using the Integration Server WS-Security facility.

    Integration Server versions prior to 8.2 provided WS-Security support using the WS-Security facility. You can still use the WS-Security facility provided that the web service is configured to run in pre-8.2 compatibility mode (i.e., the web service descriptor Pre-8.2 compatibility mode property is set to true). For more information, see Securing Web Services Using the WS-Security Facility.

    Note: The WS-Security facility is deprecated as of Integration Server 10.4 because the web services implementation with which the WS-Security facility is used is deprecated. Specifically, the web services implementation introduced in Integration Server version 7.1 is deprecated.

Transport-Based vs. Message-Based Security

WS-Security support in Integration Server is a message-based implementation that is designed to provide end-to-end network coverage.

In a transport-based implementation such as HTTPS, credentials and authentication information secure the endpoints of a connection. However, if the information transmitted between the endpoints is not contained within a closed network, or the message traffic is routed through intermediate public nodes, messages can be exposed to threats such as eavesdropping, unauthorized access, message replay, and parameter manipulation.

In a message-based implementation, such as one built according to the WS-Security standard, the security information required to pass information between web services is contained within each message header. This design caters to the securing of the message transmission environment between endpoints. You can use authentication safeguards such as signing and encryption at the individual message level to provide greater data protection than just using similar authorization features in a transport-based security architecture.

Note that the two security architectures are not mutually exclusive. You can design a solution for your web services that uses a transport-based security architecture such as SSL to secure the connection endpoints, along with a message-based, WS-Security implementation.

Note: Integration Server support of WS-Security when using the WS-Security facility does not enable or enforce any of the transport-level security measures provided by SSL and HTTP authentication.

WS-Security and the SOAP Message Header

The security information for a SOAP message is contained in an optional header component that follows the SOAP envelope. Its XML semantics and syntax are based on WS-Security design standards and recommendations for authentication components such as signing, encryption, use of authentication tokens, and security timestamps.

The security options of an outbound/inbound message pair often share a dependency. For example, if an outbound message is signed by a web service, the web service receiving the signed message must define the security parameters of an inbound message so that it can address (for example, verify) signed messages.

WS-Security and the Message Direction

When considering message-based security for a web service, you must take into account the message direction, that is either inbound or outbound. This distinction is important, because the security options you can implement depend on the message direction.

The security options of an outbound/inbound message pair often share a dependency. For example, if an outbound message is signed by a web service, the web service receiving the signed message must define the security parameters of an inbound message so that it can address (for example, verify) signed messages.

About Securing Web Service Providers and Consumers

WS-Security is structured around a request-response message exchange model between a web service consumer and a web service provider. As shown in the following figure, the message exchange is initiated by a web service consumer requesting a service from a web service provider, who processes the request and sends a response to the consumer.

Step Description
1 The web service consumer constructs an outbound request and sends it to a web service provider.
2 The provider receives the inbound request.
3 The provider constructs an outbound response and sends it back to the consumer.
4 The consumer receives the inbound response from the provider.

When

Web Service Type Outbound Message Inbound Message
Consumer Sends request
  • Include UsernameToken
  • Use digital signature
  • Timestamp message
Receives response
  • Decrypt messages
Provider Sends response
  • Encrypt messages
Receives request
  • Authenticate the UsernameToken
  • Verify signature
  • Enforce message expiration

How You Can Secure SOAP Messages with WS-Security

The following table lists the principal categories of security options that Integration Server supports via WS-Security.

Security Option Description
Signature A signature is a means of authenticating a message so that the recipient is certain of the sender’s identity and the integrity of the message content. Signing a message involves encrypting a message digest with the sender’s private key. To verify a signed message, the recipient uses the public key corresponding to the sender’s private key.
Encryption Encryption is a means of ensuring only the intended message recipient can read the message. The sender encrypts the message using the recipient’s public key. The recipient can then decrypt the message using its private key.
Security timestamps Use a timestamp to specify the message expiration time, as well as the precision of the time measurement. This provides protection against replay attacks because inbound messages arriving after the expiration time can be invalidated.
Authentication tokens You can use the following standard WS-Security authentication tokens for authenticating a web service client:
  • Username tokens. The web services consumer identifies the requestor by specifying a user name and a password (text) to authenticate the identity to a web services producer.
  • X509 Certificate Authentication. A binary token type that represents either a single certificate or certificate path in X.509 certificate format.
  • SAML tokens. An XML standard that facilitates secure interchange of authentication and authorization information. SAML security tokens contain assertions about user and are attached to messages using WS-Security by placing assertion elements inside the header.
Note: You can only use SAML tokens when using WS-SecurityPolicy. The Integration Server WS-Security facility does not support SAML tokens.