Novell Doc: Novell Access Manager 3.0 SP4 Administration Guide - Configuring Secure Communication on the Identity Server

6.5 Configuring Secure Communication on the Identity Server

The Identity Server uses the following key pairs for secure communication. In a production environment, you should exchange the key pairs that are created at installation time with certificates from a trusted Certificate Authority.

Connector: The test-connector key pair is used when you establish SSL communication between the Identity Server and the browsers and between the Identity Server and the Access Gateway back-channel communications. It needs to be replaced with a certificate that has a subject name that matches the DNS name of the Identity Server. This task is part of basic setup. See Enabling SSL Communication in the Novell Access Manager 3.0 SP4 Setup Guide.
Signing: The test-signing key pair is used by the various protocols to sign authentication requests, to sign communication with providers on the SOAP back-channel, and to sign Web Service Provider profiles. For more information on the services that use the signing certificate, see Section 6.5.1, Viewing the Services That Use the Signing Key Pair.

This certificate can be stored in an external HSM keystore. For information on how to use netHSM to replace and manage this signing certificate, see Section 6.4, Using netHSM for the Signing Key Pair.
Data Encryption: The test-encryption key pair is used to encrypt specific fields or data in the assertions. For more information on the services that use the encryption certificate, see Section 6.5.2, Viewing Services That Use the Encryption Key Pair.

If you are going to use introductions in your federation configuration, you need to set up the following key pairs:

Identity provider: The test-provider key pair is used when you configure your Identity Server to use introductions with other identity providers and have set up a common domain name for this purpose. It needs to be replaced with a certificate that has a subject name that matches the DNS name of the common domain. For configuration information, see Section 9.4.1, Configuring the General Identity Provider Options.
Identity consumer: The test-consumer key pair is used when you configure your Identity Server to use introductions with other service providers and have set up a common domain name for this purpose. It needs to be replaced with a certificate that has a subject name that matches the DNS name of the common domain. For configuration information, see Section 9.4.2, Configuring the General Identity Consumer Options.

To enable secure communication between the user store and the Identity Server, you can also import the trusted root certificate of the user store. For configuration information, see Section 8.1.2, Configuring the User Store.

This section describes the following tasks:

6.5.1 Viewing the Services That Use the Signing Key Pair

The following services can be configured to use signing:

Protocols

The protocols can be configured to sign authentication requests and responses.

To view your current configuration:

In the Administration Console, click Access Manager > Identity Servers > Edit.
In the Identity Provider section, view the setting for the Require Signed Authentication Requests option. If it is selected, all authentication requests from identity providers are signed.
In the Identity Consumer section, view the settings for the Require Signed Assertions and Sign Authentication Requests options. If these options are selected, assertions and authentication requests are signed.

SOAP Back Channel

The SOAP back channel is the channel that the protocols use to communicate directly with a provider. The SOAP back channel is used for artifact resolutions and attribute queries for the Identity Web Services Framework.

To view your current configuration for the SOAP back channel:

In the Administration Console, click Access Manager > Identity Servers > Edit.
Select the protocol (Liberty, SAML 1.1, or SAML 2.0), then click the name of an identity provider or service provider.
Click Access.
View the Security section. If the Message Signing option is selected, signing is enabled for the SOAP back channel.

Profiles

Any of the Web Service Provider profiles can be enabled for signing by configuring them to use X.509 for their message-level security mechanism.

To view your current configuration:

In the Administration Console, click Access Manager > Identity Servers > Edit > Liberty > Web Service Provider.
Click the name of a profile, then click Descriptions.
Click the Description Name.
If either Peer entity = None, Message=X509 or Peer entity = MutualTLS, Message=X509 has been selected as the security mechanism, signing has been enabled for the profile.

6.5.2 Viewing Services That Use the Encryption Key Pair

All of the Liberty Web Service Provider Profiles allow you to configure them so that the resource IDs are encrypted. By default, no profile encrypts the IDs.

To view your current configuration:

In the Administration Console, click Access Manager > Identity Servers > Edit > Liberty > Web Service Provider.
Click the name of a profile.
If the Have Discovery Encrypt This Service’s Resource IDs option is selected, the encryption key pair is used to encrypt the resource IDs.

6.5.3 Managing the Keys, Certificates, and Trust Stores

You can view the private keys, CA certificates, and certificate containers associated with the Identity Server configuration. Primarily, you use the Security page to add and replace CA certificates as necessary and to perform certificate management tasks, such as adding trusted root certificates to a trust store.

In the Administration Console, click Access Manager > Identity Servers > Edit > Security.
To view or manage keys and certificates:
1. Click any of the following links:
  
  Encryption: Displays the NIDP-encryption certificate keystore. The encryption certificate is used to encrypt specific fields or data in the assertions. Click Replace to replace the encryption certificate.
  
  Signing: Displays the NIDP-signing certificate keystore. The signing certificate is used to sign the assertion or specific parts of the assertion. Click Replace to replace the signing certificate.
  
  SSL: (Required) Displays the NIDP-connector keystore. Click this link to access the keystore and replace the connector certificate.
  
  Provider: Displays the NIDP-provider keystore. Click this link to access the keystore and replace the provider certificate used by the Identity Server when it is acting as an identity provider.
  
  Consumer: Displays the NIDP-consumer keystore. Click this link to access the keystore and replace the consumer certificate used by the Identity Server when it is acting as an identity consumer (service provider).
2. To replace a certificate, click Replace, browse to locate the certificate, then click OK.
To manage trust stores associated with the Identity Server, click either of the following links on the Security page:

NIDP Trust Store: The trusted root certificate container for CA certificates associated with the Identity Server. Click this link to access the trust store, where you can change the password or add trusted roots to the container. Liberty and SAML 2.0 protocol messages that are exchanged between identity and service providers often need to be digitally signed. A provider uses the signing certificate included with the metadata of a trusted provider to validate signed messages from the trusted provider. To use SSL for protocol messages to be exchanged between providers, each provider must trust the SSL Certificate Authority (CA) of the other provider. Well-known CAs should already be trustable, but for those that are not, you must import the CA for the other provider. Failure to do so causes numerous system errors.

OCSP Trust Store: The trust store for OCSP certificates. Online Certificate Status Protocol is a method used for checking the revocation status of a certificate. To use this feature, you must set up an OCSP server. The Identity Server sends an OCSP request to the OCSP server to determine if a certain certificate has been revoked. The OCSP server replies with the revocation status. If this revocation checking protocol is used, the Identity Server does not cache or store the information in the reply, but sends a request every time it needs to check the revocation status of a certificate. The OCSP reply is signed by the OCSP server. To verify that it was signed by the correct OCSP server, the OCSP server certificate needs to be added to this trust store. The OCSP server certificate itself is added to the trust store, not the CA certificate.
Specify the server IP address and port.

The auto-import displays the certificate chain, which you can select for import.
Click OK, then click Close.
Restart Tomcat.

The system prompts you with a dialog box to restart Tomcat. This is necessary whenever security changes are made to the Identity Server.

For more information about enabling security for a basic Access Manager configuration, see Enabling SSL Communication in the Novell Access Manager 3.0 SP4 Setup Guide.

For additional information about managing certificates, see Section V, Security and Certificate Management.