Federation Guides › Partnership Federation Guide › Sign and Encrypt Federation Messages › Key and Certificate Management for Federation

Key and Certificate Management for Federation

Securing an assertion and encrypting data within the assertion is a critical part of partnership configuration. In a federation environment, key/certificate pairs and standalone certificates serve a number of functions:

• Signing/verification of assertions (all three profiles)
• Signing/verification of authentication requests (SAML 2.0 only)
• Signing/verification of single logout requests and responses (SAML 2.0)
• Signing back channel requests and responses for HTTP-Artifact SSO (SAML 1.1 and 2.0)
• Encryption/decryption of an entire assertion or part of an assertion (SAML 2.0)
• Client credentials across the back channel for artifact single sign–on (SAML 1.1 and 2.0)

The Policy Server Configuration Guide contains information and instructions about managing keys and certificates.

You can use SSL server certificates to do the following tasks:

• Manage federation traffic across an SSL connection.
• Secure communication across the back channel for artifact single sign-on.

Refer to instructions for enabling SSL for the web server where the CA SiteMinder® Web Agent is installed.

Note: If you enable SSL, it affects all URLs for all services, even the Base URL parameter. This means that all service URLs must begin with https://.

SAML 2.0 Signing Algorithms

For SAML 2.0, you have the option of choosing a signing algorithm for signing tasks. The ability to select an algorithm supports the following use cases:

• An IdP-->SP partnership in which the IdP signs assertions, responses and SLO-SOAP messages with the RSAwithSHA1, or the RSAwithSHA256 algorithm.
• An SP-->IdP partnership in which the SP signs authentication requests and SLO-SOAP messages with the RSAwithSHA1, or the RSAwithSHA256 algorithm.

Signature verification automatically detects which algorithm is in use on a signed document then verifies it. No configuration for signature verification is required.

Signature Configuration at a SAML 1.1 Producer and WSFED IP

The Signature step lets you define how the Policy Server uses private keys and certificates to sign SAML assertion or WS-Federation token responses. For SAML 1.1, you can elect to sign only assertions instead of the assertion response.

SAML 1.1 and WS-Federation do not support encryption.

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

Note: If the system is operating in FIPS_COMPAT or FIPS_MIGRATE mode, all certificate and key entries are available from the pull-down list. If the system is operating in FIPS-Only mode, only FIPS-approved certificate and key entries are available.

Follow these steps:

1. Log in to the Administrative UI
2. Select the asserting-to-relying party partnership that you want to modify.
3. Navigate to the Signature step in the partnership wizard.
4. In the Signature section, select an alias from the pull-down list for the Signing Private Key Alias field.

   If there is no private key in the certificate data store, click Import to import a key. Alternatively, click Generate to create a certificate request.

   By completing this field, you are indicating which private key the asserting party uses to sign assertions and responses.

5. (SAML 1.1 only) For the Artifact and Post signature options, select the specific components (assertion, response) that you want signed.

If you are using CA SiteMinder® in a test environment, you can disable signature processing to simplify testing. Click the Disable Signature Processing check box.

Signature configuration is complete.

Signature Verification at a SAML 1.1 Consumer and a WSFED RP

The Signature step lets you define how the Policy Server uses private keys and certificates to verify SAML assertion or WS-Federation token responses. For SAML 1.1, you can elect to verify only assertions.

SAML 1.1 and WS-Federation do not support encryption.

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

Note: If the system is operating in FIPS_COMPAT or FIPS_MIGRATE mode, all certificate and key entries are available from the pull-down list. If the system is operating in FIPS-Only mode, only FIPS-approved certificate and key entries are available.

Follow these steps:

1. Log in to the Administrative UI
2. Select the relying-to-asserting party partnership that you want to modify.
3. Navigate to the Signature step in the partnership wizard.
4. Select an alias from the certificate data store for the Verification Certificate Alias field.

   By completing this field, you are indicating which certificate verifies signed assertions or responses or both. If there is no certificate in the certificate data store, click Import to import one. Alternatively, click Generate to create a certificate request.

Note: If you are using the product in a test environment, you can disable signature processing to simplify testing. Click the Disable Signature Processing check box.

Signature configuration is complete.

Signature Configuration at a SAML 2.0 IdP

The Signature and Encryption step in the partnership wizard lets you define how the product uses private keys and certificates for the following signing functions:

• Sign and verify SAML assertions, assertion responses, and authentication requests.

  For SAML 2.0 POST binding, you are required to sign assertions.

• Sign single logout responses and requests (HTTP-Redirect and SOAP bindings).

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

Note: If the system is operating in FIPS_COMPAT or FIPS_MIGRATE mode, all certificate and key entries are available from the pull-down list. If the system is operating in FIPS-Only mode, only FIPS-approved certificate and key entries are available.

To configure signing options

1. Select the Signature and Encryption step in the partnership wizard.
2. In the Signature section, select an alias for the Signing Private Key Alias field. If there is no private key available, click Import to import one. Or, click Generate to create a certificate request.

   By completing this field, you are indicating which private key the asserting party uses to sign assertions, single logout requests and responses.

   Note: click on Help for a description of the fields.

3. Select the hash algorithm for digital signing in the Signing Algorithm field. The IdP signs assertions, responses and SLO-SOAP messages with the specified algorithm.

   Select the algorithm that best suits your application.

   RSAwithSHA256 is more secure than RSAwithSHA1 due to the greater number of bits used in the resulting cryptographic hash value.

   The system uses the algorithm that you select for all signing functions.

4. Select an alias from the certificate data store or the Verification Certificate Alias field.

   By completing this field, you are indicating which certificate verifies signed authentication requests or single logout requests or responses. If there is no certificate in the database, click Import to import one.

5. (Optional) Specify Artifact and POST signature options for the assertion or response or both.
6. (Optional) Specify an SLO SOAP signature option for the logout request, the logout response or both when you are using single logout.
7. (Optional) Select the check box for Require Signed Authentication Requests. This check box verifies that the asserting party only accepts signed requests from the relying party.

   Activate a partnership for all configuration changes to take effect and for the partnership to become available for use. Restarting the services is not sufficient.

If you are using the product in a test environment, you can disable signature processing to simplify testing. Click the Disable Signature Processing check box.

Important! Enable signature processing in a SAML 2.0 production environment.

Encryption Configuration at a SAML 2.0 IdP

The Signature and Encryption step in the Partnership wizard lets you define how the Policy Server uses private keys and certificates to do the following tasks:

• Sign and verify SAML assertions, assertion responses, and authentication requests.

  For SAML 2.0 POST binding, you are required to sign assertions.

• Sign single logout responses and requests (HTTP-Redirect and SOAP bindings).
• Encrypt and decrypt entire assertions, Name IDs and attributes.

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

To configure encryption options

1. In the Encryption section, select one or both of the following check boxes to specify the assertion data to be encrypted:
   • Encrypt Name ID
   • Encrypt Assertion
2. Select the certificate alias from the certificate data store for the Encryption Certificate Alias.

   This certificate encrypts assertion data. If no certificate is available, click Import to import one.

3. Select values for the Encryption Block Algorithm and Encryption Key Algorithm fields.

   For the following block/key algorithm combinations, the minimum key size that is required for the certificate is 1024 bits.

   • Encryption Block Algorithm: 3DES

     Encryption Key Algorithm: RSA-OEAP

   • Encryption Block Algorithm: AES-256

     Encryption Key Algorithm: RSA-OEAP

     Note: To use the AES-256 bit encryption block algorithm, install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. You can download these files from http://java.sun.com/javase/downloads/index.jsp.

The encryption configuration is complete.

Signature Configuration at a SAML 2.0 SP

The Signature and Encryption step in the partnership wizard lets you define how the Policy Server uses private keys and certificates to do the following tasks:

• Verify SAML assertions signatures and assertion responses and sign authentication requests.

  Note: For SAML 2.0 POST binding, the IdP is required to sign assertions.

• Sign single logout responses and requests (HTTP-Redirect and SOAP bindings).

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

Note: If the system is operating in FIPS_COMPAT or FIPS_MIGRATE mode, all certificate and key entries are available from the pull-down list. If the system is operating in FIPS-Only mode, only FIPS-approved certificate and key entries are available.

To configure signing options

1. Begin by selecting the Signature and Encryption step in the partnership wizard.
2. In the Signature section, select an alias from the certificate data store for the Signing Private Key Alias field. If there is no private key in the database, click Import to import one. Or, click Generate to create a key pair and generate a certificate request.

   By completing this field, you are indicating which private key the relying party uses to sign authentication requests and single logout requests and responses.

   Note: Click Help for a description of fields, controls, and their respective requirements.

3. Select the hash algorithm for digital signing in the Signing Algorithm field. The SP signs authentication requests and SLO-SOAP messages with the specified algorithm.

   Select the algorithm that best suits your application.

   RSAwithSHA256 is more secure than RSAwithSHA1 due to the greater number of bits used in the resulting cryptographic hash value.

   CA SiteMinder® uses the algorithm that you select for all signing functions.

4. Select an alias from the certificate data store for the Verification Certificate Alias field.

   By completing this field, you are indicating which certificate the relying party uses to verify signed assertions or single logout requests and responses. If there is no certificate in the database, click Import to import one.

5. (Optional) For the SP to sign all authentication requests, select the Sign Authentication Requests. If the remote asserting party requires the authentication requests to be signed, check this option.

   Activate a partnership for all configuration changes to take effect and for the partnership to become available for use. Restarting the services is not sufficient.

If you are using CA SiteMinder® in a test environment, you can disable signature processing to simplify testing. Click the Disable Signature Processing check box to disable the feature.

Important! Enable signature processing in a SAML 2.0 production environment.

Encryption Configuration at a SAML 2.0 SP

The Signature and Encryption step lets you configure how the SP uses private keys and certificates, including encrypting and decrypting assertions, Name IDs, and attributes.

There can be multiple private keys and certificates in the certificate data store. If you have multiple federated partners, you can use a different key pair for each partner.

Note: If the system is operating in FIPS_COMPAT or FIPS_MIGRATE mode, all certificate and key entries are available from the pull-down list. If the system is operating in FIPS-Only mode, only FIPS-approved certificate and key entries are available.

To configure encryption options

1. In the Encryption section, select one or both of the following check boxes so that the correct data is encrypted in the assertion:
   • Require encrypted Name ID
   • Require encrypted Assertion

   Note: To use the AES-256 bit encryption block algorithm, install the Sun Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. You can download these files from http://java.sun.com/javase/downloads/index.jsp.

2. Select the alias from the certificate data store for the Decryption Private Key Alias.

   This private key decrypts any encrypted assertion data. If no certificate available, click Import to import one or click Generate to create a key pair and generate a certificate request.

The encryption configuration is complete.