Security Implementation and Web Services

Sterling B2B Integrator builds upon existing security technologies, such as XML digital signatures and X.509 certificates, to deliver an industry-standard way of securing Web services message exchanges. This assures message integrity and prevents security breaches such as replay attacks.

Web services includes the following security features:
  • Transport-level security – A secure SSL connection between sender and receiver
  • Message-level security – End-to-end security of the SOAP message, regardless of transport-level security or transmission through intermediaries, based on compliance with the WS-Security 1.0 specification (including WS-I Basic Profile 1.1 and Basic Security Profile 1.0).
    • Encryption and decryption features: Encryption of the complete contents of the SOAP message body part, public key encryption, and flexible ordering of signature and encryption.
      Note: Web Services does not support shared secret key encryption.
    • Signature creation and verification to authenticate the message sender
    • Processing of security tokens (Username Token and X.509 Certificate Tokens)
    • Security timestamps

For more information about the parameters, see Create a New Web Service.

Security Token Flow

The following diagram illustrates the flow of a security token in Sterling B2B Integrator:

Security Token Flow

UserName Token

You can create a plain text (UserName) security token to and identify yourself when sending and receiving documents using Web services. If you are using a UserName token in your Web service, you need to add it in Sterling B2B Integrator before you configure the Web service. Additionally, you have the option of creating a digested security token. A digested security token is more secure, as it is encrypted using a nonce (a randomly generated number) and timestamp (date and time).

You can also use a UserName token with other applications that support security tokens within Sterling B2B Integrator. However, security tokens imported or created using the Web services security token feature are not listed on the Sterling B2B Integrator certificates page.

X.509 Certificate Token

When you configure a Web service in your application, you have the option of specifying the request and response security settings. This option allows you to add or create a certificate token for verification or security purposes. As part of the Web services response security settings, you can add a security header and a certificate token, which will automatically be stored as an X.509 signing certificate.

You can also select the way in which the X.509 certificate will be embedded in the security header:
  • BinaryToken—Sends the signing X.509 certificate as a BinarySecurityToken.
  • IssuerSerial—Sends the issuer name and serial number of a certificate to the receiver. This is the default.
  • X509KeyIdentifier—Sends the X.509 certificate used to encrypt the symmetric key.

Implementation Decisions

When making decisions about the security of your Web services, you should consider the following:
  • Requiring signed requests is optional, but strongly recommended. To use signed requests, your consumer will have to obtain a CA certificate and send you the public key. Web services verifies signatures on messages, but not on attachments.
  • Signing outgoing responses is optional, but strongly recommended. To use signed responses, you must generate a system certificate in Sterling B2B Integrator and send your consumer the public key. Web services signs messages, but not attachments.
  • Use a certificate in Sterling B2B Integrator for only one function at a time. In other words, do not use the same certificate for multiple consumers or for different functions, such as Web service message authentication and EDI.