1.3 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.

To force the browser connections to the Identity Server to support a specific level of encryption, see Section 1.4.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:

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.3.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:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. 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.

  3. 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:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. Select the protocol (Liberty, SAML 1.1, or SAML 2.0), then click the name of an identity provider or service provider.

  3. Click Access.

  4. 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:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click the name of a profile, then click Descriptions.

  3. Click the Description Name.

  4. 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.3.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:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click the name of a profile.

  3. 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.3.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.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Security.

    Identity Server security
  2. 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 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:

      Replacing Identity Server certificates
    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.

  3. 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:

      Importing trusted roots
    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 Novell Access Manager 3.1 SP2 Setup Guide.

For additional information about managing certificates, see Security and Certificate Management in the Novell Access Manager 3.1 SP2 Administration Console Guide.