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 Novell Access Manager 3.1 SP2 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 Access Manager Services That Use the Signing Certificate.
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 1.6, 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 1.3.2, Viewing Services That Use the Encryption Key Pair.
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:
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:
The following services can be configured to use signing:
The protocols can be configured to sign authentication requests and responses.
To view your current configuration:
In the Administration Console, click
> > .In the
section, view the setting for the option. If it is selected, all authentication requests from identity providers are signed.In the
section, view the settings for the s and S options. If these options are selected, assertions and authentication requests are signed.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
> > .Select the protocol (Liberty, SAML 1.1, or SAML 2.0), then click the name of an identity provider or service provider.
Click
.View the
section. If the option is selected, signing is enabled for the SOAP back channel.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
> > > > .Click the name of a profile, then click
.Click the
.If either
or has been selected as the security mechanism, signing has been enabled for the profile.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
> > > > .Click the name of a profile.
If the
option is selected, the encryption key pair is used to encrypt the resource IDs.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
> > > .To view or manage keys and certificates:
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
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
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:
To replace a certificate, click
, browse to locate the certificate, then click .If prompted to restart Tomcat, click
. Otherwise, update the Identity Server.To manage trust stores associated with the Identity Server:
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:
Select one of the following actions:
To add a trusted root that you have already imported, click
, click the icon, select the trusted root, then click twice.To import the trusted root from the server, click
, specify the server’s IP address or DNS name and port, then click . The auto-import displays the certificate chain, which you can select for import.To remove a trusted root, select the trusted root, then click
.Click
.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.