1.4 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 certificate is used when you establish SSL communication between the Identity Server and the browsers and between the Identity Server and the Access Gateway for 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 NetIQ Access Manager 3.2 SP3 Setup Guide.
Signing: The test-signing (by default) 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 about the services that use the signing certificate, see Access Manager Services That Use the Signing Certificate.

This certificate can be stored in an external HSM keystore. For information about how to use netHSM to replace and manage this signing certificate, see Section 1.7, Using netHSM for the Signing Key Pair.

If you want increased security, you can configure signing and encryption certificate for the service provider. For information, see Section 1.4.1, Configuring Enhanced Security for Service Provider Communications
Data Encryption: The test-encryption (by default) key pair is used to encrypt specific fields or data in the assertions. For more information about the services that use the encryption certificate, see Section 1.4.3, Viewing Services That Use the Encryption Key Pair.

If you want increased security, you can configure signing and encryption certificate for the service provider. For information, see Section 1.4.1, Configuring Enhanced Security for Service Provider Communications.

To force the browser connections to the Identity Server to support a specific level of encryption, see Section 1.5.3, Forcing 128-Bit Encryption.

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 7.2.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 7.2.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 3.1, Configuring Identity User Stores.

This section describes the following tasks:

1.4.1 Configuring Enhanced Security for Service Provider Communications

When a single identity provider authenticates to multiple service providers, all the assertions are signed by using a common signing key. The assertions are also decrypted by using a common encryption key. Using a single certificate can lead to a vulnerability for all the service providers.

For example, if the common signing or encryption cert is compromised, the information can be used on multiple service providers to potentially gather information.

To mitigate this risk, you can use a single signing and encryption certificate for each service provider.

To define signing and encryption certificate for a service provider, see Section 1.4.4, Managing the Keys, Certificates, and Trust Stores

1.4.2 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 Devices > 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 Devices > 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 Trust.
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 Devices > 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.

1.4.3 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 Devices > 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.

1.4.4 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 Devices > 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. Click Add or Remove to add or remove the encryption certificates.
  
  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. Click Add or Remove to add or remove the signing certificates.
  
  SSL: (Required) Displays the SSL connector keystore. Click this link to access the keystore and replace the connector certificate.
  
  Provider: Displays the ID Provider Introductions SSL Connector 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 ID Consumer Introductions SSL Connector 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).
  
  For example, when you click the Provider keystore, the following page appears:
2. To replace a certificate, click Replace, browse to locate the certificate, then click OK.
3. If prompted to restart Tomcat, click OK. Otherwise, update the Identity Server.
To manage trust stores associated with the Identity Server:
1. Click either of the following links on the Security page:
  
  NIDP Trust Store: This Identity Server trust store contains the trusted root certificates of all the providers that it trusts. 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. The trusted root of the CA that created the signing certificate for the service provider needs to be in this trust store.
  
  To use SSL for protocol messages to be exchanged between providers, each provider must trust the SSL certificate authority (CA) of the other provider. You must import the root certificate chain for the other provider. Failure to do so causes numerous system errors.
  
  OCSP Trust Store: The Identity Server uses this 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.
  
  For example, if you click the NIDP Trust Store, the following page appears:
2. Select one of the following actions:
  - To add a trusted root that you have already imported, click Add, click the Select Trusted Roots icon, select the trusted root, then click OK twice.
  - To import the trusted root from the server, click Auto-Import From Server, specify the server’s IP address or DNS name and port, then click OK. The auto-import displays the certificate chain, which you can select for import.
  - To remove a trusted root, select the trusted root, then click Remove.
3. Click Close.
4. Update the Identity Server.

For more information about enabling security for a basic Access Manager configuration, see Enabling SSL Communication in the NetIQ Access Manager 3.2 SP3 Setup Guide.

For additional information about managing certificates, see Security and Certificate Management in the NetIQ Access Manager 3.2 SP3 Administration Console Guide.