Signature and Encryption Configuration for Federated Partnerships

Securing and encrypting data is a critical part of partnership configuration.
casso127
Securing and encrypting data is a critical part of partnership configuration.
Keys and certificates for federation are stored in the certificate data store (CDS). To manage the CDS and perform tasks, such as importing, deleting, and updating keys and certificates, see Key and Certificate Management.
In a federation environment, key/certificate pairs and standalone certificates serve several 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)
This topic describes how to configure the following signature and encryption features:
For only SAML 2.0 partnerships, you can modify certificate settings without deactivating the partnership.
SSL Server Certificates for Federation
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.
To enable SSL for the web server where the Web Agent is installed, see the web server documentation.
If you enable SSL, it affects all URLs for all services, even the Base URL parameter. All service URLs must begin with
https://
.
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.
casso127
 
 
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.
In a test environment, you can disable signature processing to simplify testing. Click the 
Disable Signature Processing
 check box.
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.
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.
casso127
 
 
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.
In a test environment, you can disable signature processing to simplify testing. Click the Disable Signature Processing check box.
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.
Signature configuration is complete.
Signature Configuration at a SAML 2.0 IdP
The Signature and Encryption step 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.
casso127
 
 
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.
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.
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 is required.
 Enable signature processing in a SAML 2.0 production environment.
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. This field indicates which private key the asserting party uses to sign assertions, single logout requests, and responses.
    If there is no private key available, click
    Import
    to import one. Alternatively, click
    Generate
    to create a certificate request. 
  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. The system uses the algorithm that you select for all signing functions.
    RSAwithSHA256 is more secure than RSAwithSHA1 due to the greater number of bits used in the resulting cryptographic hash value. 
     
  4. Select an alias from the certificate data store for the
    Verification Certificate Alias
    field. This field indicates which certificate verifies signed authentication requests or single logout requests or responses. If there is no certificate in the certificate data store, click
    Import
    to import one.
  5. (Optional) Select another alias from the certificate data store for the 
    Secondary Verification Certificate Alias
    field. If verification of a signed authentication or logout request fails using the primary verification certificate alias, the IdP uses this secondary verification alias. If the certificate is not already in the certificate data store, click 
    Import
     to import one. When secondary certificates are configured or updated for an active partnership, the run time automatically picks up the changes. You do not need to flush the cache manually from the UI for the changes to take effect.
  6. (Optional) Specify Artifact and POST signature options for the assertion or response or both.
  7. (Optional) Specify an SLO SOAP signature option for the logout request, the logout response or both when you are using single logout.
  8. (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.
  9. 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.
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 checkboxes 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
    To use the AES-256 bit encryption block algorithm, install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files.
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. For SAML 2.0 POST binding, the IdP is required to sign assertions.
  • Sign single logout responses and requests (HTTP-Redirect and SOAP bindings).
In a test environment, you can disable signature processing to simplify testing. Click the
Disable Signature Processing
check box. Enable signature processing in a SAML 2.0 production environment.
To configure signing options:
  1. Select 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. This field indicates which private key/certificate pair the SP uses to sign authentication requests and single logout requests and responses. If there is no private key/certificate pair in the database, click
    Import
    to import one. Alternatively, click 
    Generate
    to create a key pair and generate a certificate request.
  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. The algorithm that you select is used for all signing functions.
    RSAwithSHA256 is more secure than RSAwithSHA1 due to the greater number of bits used in the resulting cryptographic hash value.
  4. Select an alias from the certificate data store for the
    Verification Certificate Alias
    field. This field indicates 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) Select an alias for the 
    Secondary Certificate Verification Alias
     field. If verification of a signed assertion response or logout request fails using the primary verification certificate alias, the SP uses this secondary verification alias.
    If the certificate is not already in the certificate data store, click
    Import
    to import one. When secondary certificates are configured or updated for an active partnership, the run time automatically picks up the changes. You do not need to manually flush cache for the changes to take effect.
  6. (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.
  7. 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.
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.
casso127
 
 
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.
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.
casso127
 
 
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
      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 Oracle.
  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.