Federation Guides › Legacy Federation Guide › Configure CA SiteMinder® as a SAML 2.0 Identity Provider › Validate Signed AuthnRequests and SLO Requests/Responses

Validate Signed AuthnRequests and SLO Requests/Responses

By default, signature processing is enabled because the SAML 2.0 specification requires it. Always enable signature processing in a production environment. CA SiteMinder® always signs SAML 2.0 POST responses and single logout requests; signing does not require configuration using the Administrative UI.

The only setup that is required for signing is that you add the private key/certificate pair of the signing authority to the certificate data store.

Important! For debugging purposes only, you can temporarily disable all signature processing (both signing and verification of signatures). Select Disable Signature Processing in the Signature section of the Encryption & Signing settings.

To validate signatures of AuthnRequests from a Service Provider, or single logout requests and responses, complete the configuration steps in the Administrative UI.

To set up validation:

1. Add the public key to the certificate data store at the Identity Provider.

   The public key must correspond to the private key and certificate that the Service Provider used to do the signing.

2. In the Administrative UI, select one or both of the following check boxes:
   • Require signed AuthnRequests (Encryption & Signing settings)

     If you select this check box, the Identity Provider requires a signed authnrequest and then the IdP validates the signature of the request. If the authnrequest is not signed, the Identity Provider rejects it.

     Important: If you sign AuthnRequests, no unsolicited responses can be sent from the Identity Provider.

   • HTTP-Redirect (SAML Profiles settings)

     If you select this check box, the Identity Provider validates the signature of the SLO request and response.

3. Complete the Issuer DN and Serial Number fields (Encryption & Signing settings).

   The field values must match the certificate in the certificate data store. The certificate is the one that corresponds to the private key/certificate pair of the authority that signs the requests. To verify that you enter a matching value, view the DN of the certificate.

Encrypt a NameID and an Assertion

You can encrypt the Name ID in an assertion or the assertion itself. Encryption adds another level of protection when transmitting the assertion.

When you configure encryption, specify the partner certificate. The certificate is in the assertion. When the assertion arrives at the Service Provider, the Service Provider decrypts the encrypted data using the associated private key.

Note: If you enable encryption, the first federation call can cause the Policy Server memory to increase to load the encryption libraries and allocate additional memory.

Enabling Encryption

To implement encryption

1. Log in to the Administrative UI.
2. Navigate to the Encryption & Signing settings for the Service Provider you want to configure.
3. Configure the settings for assertion encryption.

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

   Be aware of the following conditions:

   • If you select rsa-oaep as an Encryption Key Algorithm, the minimum required key size is a 1024 bits.
   • To use the aes-256 bit encryption block algorithm, install Sun Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. You can download these files from http://java.sun.com/javase/downloads/index.jsp
   • For the IssuerDN and the Serial Number fields, the IssuerDN is the DN of the certificate issuer and its associated serial number. This information locates the certificate of the Service Provider in the certificate data store. The Service Provider supplies this data.

     The IssuerDN and Serial Number that you enter must match an IssuerDN and serial number of a key/certificate pair stored in the certificate data store of the Identity Provider.

4. Click Submit to save your changes.

Request Processing with a Proxy Server at the IdP

Before CA SiteMinder® processes a request as an Identity Provider, it validates the message attributes using the local URL for the Federation Web Services application.

For example, an AuthnRequest message from an SP can contain the following attribute:

Destination="http://idp.domain.com:8080/affwebservices/public/saml2sso"

In this example, the destination attribute in the AuthnRequest and the address of the Federation Web Services application are the same. CA SiteMinder® verifies that the destination attribute matches the local URL of the FWS application.

If CA SiteMinder® sits behind a proxy server, the local and destination attribute URLs are not the same. The Destination attribute is the URL of the proxy server. For example, the AuthnRequest can include the following Destination attribute:

Destination="http://proxy.domain.com:9090/affwebservices/public/saml2sso"

The local URL for Federation Web Services, http://idp.domain.com:8080/affwebservices/public/saml2sso, does not match the Destination attribute so CA SiteMinder® denies the request.

You can specify a proxy configuration to alter how CA SiteMinder® determines the local URL for verifying a message attribute. If you specify a proxy, CA SiteMinder® replaces the <protocol>://<authority> portion of the local URL with the proxy server URL. The result is a match between the two URLs.

Configure Request Processing with a Proxy Server

CA SiteMinder® can sit behind a proxy server. For this deployment, configure the proxy so that CA SiteMinder® finds a match between the URL in a request message attribute and the local proxy URL. There must be a match to process the request. CA SiteMinder® replaces the <protocol>://<authority> portion of the local URL with the proxy server URL, which results in a match between the two URLs.

To use a proxy server at the IdP

1. Log in to the Administrative UI.
2. Navigate to the General settings for the Service Provider you want to configure.
3. Enter a partial URL for the proxy server, of the form <protocol>://<authority>.

   For example, the proxy server configuration would be:

   http://proxy.domain.com:9090
   

   If your network includes the SPS federation gateway, the Server field must specify the SPS federation gateway host and port, for example,

   http://sps_gateway_server.ca.com:9090
   

4. Click Submit to save your changes.

The value that you enter for the Server field affects the URLs for the following IdP services:

• Single Sign-On Service
• Single Logout Service
• Artifact Resolution Service
• Attribute Service
• Authentication URL—use the proxy server URL. After CA SiteMinder® authenticates the user, it redirects the user to the proxy server to get to the Single Sign-On service.

The Server value becomes part of the URL used to verify SAML attributes like the Destination attribute. If you are using a proxy server for one URL, use it for all these URLs.