Implementing WS-Security

Configuring authentication with username tokens:

1. In the IBM App Connect Enterprise Toolkit, create a policy project by clicking File > New > Policy Project.
2. In the Application Development view, right-click the policy project, then click New > WS Policy Sets and Bindings. The WS Policy Sets and Bindings editor opens.
3. Click Add to create a policy set.
4. Select the new policy in the tree view, then click Add WS-Security to add the policy type to the policy set.
5. Expand the WS-Security policy type in the tree view, click Authentication Tokens, then click Add to add UserName authentication tokens to the policy (see Policy Sets and Policy Set Bindings editor: Authentication tokens panel).
6. Repeat the previous step to configure X.509 authentication tokens (see Policy Sets and Policy Set Bindings editor: Authentication and Protection Tokens panel).
7. Configure a security profile (see Message flow security and security profiles).
8. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Configuring authentication with X.509 tokens:

1. If you are using the integration node's truststore to hold the trusted certificate, you must configure it. See Viewing and setting keystore and truststore runtime properties at integration node level or Viewing and setting keystore and truststore runtime properties at integration server level, depending on where you want to set keystore and truststore runtime properties.
2. Create a policy set (as described in the previous section), then add UserName and X.509 authentication tokens to it.
3. Configure the certificate mode for either integration node truststore or an external security provider (see Policy Sets and Policy Set Bindings editor: Authentication and Protection Tokens panel).
4. If you are using an external security provider, configure a security profile (see Message flow security and security profiles).
5. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Configuring authentication with SAML assertions:

1. Create a policy set and add SAML pass-through 1.1 or SAML pass-through 2.0 tokens to it (see Policy Sets and Policy Set Bindings editor: Authentication tokens panel). SAML pass-though does not enforce subject confirmation, but the assertion is simply provided as a token to be processed in the external Security Token Server specified in the security profile that is associated with the node.
2. Configure a security profile. The security profile must be configured to use a WS-Trust v1.3 STS (see Message flow security and security profiles).
3. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Configuring authentication with Kerberos tickets:

1. Create a policy set and add your Kerberos token type as symmetric tokens (see Policy Sets and Policy Set Bindings editor: Message Level Protection panel).
2. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).
3. Configure the host's Kerberos keytab file. For more information about Kerberos configuration, see the documentation for your integration node's host system. For example, for Windows, see the "Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability", which you can access at http://technet.microsoft.com/en-us/library/.

Configuring authentication with LTPA binary tokens:

1. Create a policy set and add LTPA tokens to it (see Policy Sets and Policy Set Bindings editor: Authentication tokens panel). The LTPA binary token is passed through to the external Security Token Service (STS) specified in the security profile that is associated with the node.
2. Configure a security profile. The security profile must be configured to use a WS-Trust v1.3 STS (see Message flow security and security profiles).
3. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Confidentiality is provided by XML encryption, and requires either X.509 tokens or Kerberos tickets.

Configuring XML encryption with X.509 tokens:

1. If you are using the integration node's truststore to hold the trusted certificate, you must configure it. See Viewing and setting keystore and truststore runtime properties at integration node level or Viewing and setting keystore and truststore runtime properties at integration server level, depending on where you want to set keystore and truststore runtime properties.
2. Create a policy set, enable XML encryption, create encryption tokens, and select the encryption algorithms that you will use (see Policy Sets and Policy Set Bindings editor: Message Level Protection panel).
3. Define which parts of a message are to be encrypted (see Policy Sets and Policy Set Bindings editor: Message Part Protection panel).
4. Further configure message part encryption (see Policy Sets and Policy Set Bindings editor: Message Part Policies panel).
5. Further configure the keystore and truststore (see Policy Sets and Policy Set Bindings editor: Key Information panel).
6. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Configuring XML encryption with Kerberos tickets:

1. Configure your host for Kerberos, providing a krb.conf configuration file. This step is required on all operating systems, including Windows.
2. Provide the integration node with the Kerberos client credentials for accessing the Kerberos Key Distribution Center (KDC). These credentials (which are required for SOAPRequest nodes) can be provided in the Integration node properties tree, or by using the mqsisetdbparms command. The credentials are taken in order of priority:
   • The node has a security profile with the Propagation property set to True and the Properties tree UserName and password token is present. If no UserName and password token exists, an exception in thrown.

   • mqsisetdbparms kerberos::<realm>::<integrationServerName>

   • mqsisetdbparms kerberos::<realm>

   • mqsisetdbparms kerberos::kerberos

3. Create a policy set and add the required Kerberos token type as Symmetric Tokens (see Policy Sets and Policy Set Bindings editor: Message Level Protection panel).

Integrity is provided by XML signature, and requires either X.509 tokens or Kerberos tickets.

Configuring XML signature with X.509 tokens:

1. If you are using the integration node's truststore to hold the trusted certificate, you must configure it. See Viewing and setting keystore and truststore runtime properties at integration node level or Viewing and setting keystore and truststore runtime properties at integration server level, depending on where you want to set keystore and truststore runtime properties.
2. Create a policy set, enable XML signature, and create signature tokens (see Policy Sets and Policy Set Bindings editor: Message Level Protection panel).
3. Define which parts of a message are to be signed (see Policy Sets and Policy Set Bindings editor: Message Part Protection panel).
4. Further configure message part signature (see Policy Sets and Policy Set Bindings editor: Message Part Policies panel).
5. Further configure the keystore and truststore (see Policy Sets and Policy Set Bindings editor: Key Information panel).
6. Associate the policy set with a message flow or node (see Associating policy sets and bindings with message flows and nodes).

Configuring XML signature with Kerberos tickets:

1. Configure your host for Kerberos, providing a krb.conf configuration file. This step is required on all operating systems, including Windows.
2. Provide the integration node with the Kerberos client credentials for accessing the Kerberos Key Distribution Center (KDC). These credentials (which are required for SOAPRequest nodes) can be provided in the Integration node properties tree, or by using the mqsisetdbparms command. The credentials are taken in the following order of priority:
   • The node has a security profile with the Propagation property set to True and the Properties tree UserName and password token is present. If no UserName and password token exists, an exception in thrown.

   • mqsisetdbparms kerberos::<realm>::<integrationServerName>

   • mqsisetdbparms kerberos::<realm>

   • mqsisetdbparms kerberos::kerberos

3. Create a policy set and add the required Kerberos token type as Symmetric Tokens (see Policy Sets and Policy Set Bindings editor: Message Level Protection panel).