Previous Topic: Test SAML 2.0 Single Sign-onNext Topic: Overview of a CA SiteMinder® Federation Setup

Federation Guides › Legacy Federation Guide › Use a Sample Configuration to Learn About Legacy Federation › Add Functionality to the Federation Deployment

Add Functionality to the Federation Deployment

After you complete the POST single sign-on configuration, you can add more features to the federated network.

The additional tasks covered in this deployment example are:

Some of these additional features are required for single sign-on in a production environment, such as digital signing for POST binding. Required tasks are noted.

Configure Single Logout

The single logout protocol (SLO) results in the simultaneous end of all sessions for a particular user, to help ensure security. Associate these sessions with the browser that initiated the logout. Single logout does not necessarily end all sessions for a user.

Configuring single logout enables the Identity Provider and Service Provider to support the single logout protocol. The configuration also determines how single logout is handled.

Enable Single Logout at the IdP

You can initiate single logout at the IdP. At the IdP, idp.demo, enable single logout on a per-SP basis.

Follow these steps:

  1. Log in to the Administrative UI and access the SAML Service Provider object for sp.demo.
  2. Navigate to the SAML Profiles page.
  3. Select HTTP-Redirect.

    The remaining fields become active.

  4. Enter values for the following fields:
    SLO Location URL

    http://www.sp.demo:81/affwebservices/public/saml2slo

    Defines the SLO servlet at the SP.

    SLO Confirm URL

    http://www.idp.demo:80/idpsample/SLOConfirm.jsp.

  5. Accept defaults for the other fields.
  6. Click Submit.
  7. Log in to the Policy Server Management Console and enable the session store.

    For instructions, see the Policy Server Administration Guide.

Enable Single Logout at the SP

You can initiate single logout at the Service Provider.

Follow these steps:

  1. Verify that the realm with the protected resources is configured for persistent sessions.
  2. Navigate to the authentication scheme named Partner IDP.demo Auth Scheme.
  3. Modify the SAML 2.0 Configuration for the scheme to access the SLO tab.
  4. In the SLO tab, select HTTP-Redirect.

    The rest of the fields become active.

  5. Complete the fields as follows:
    SLO Location URL

    http://www.idp.demo:80/affwebservices/public/saml2slo

    SLO Confirm URL

    http://www.sp.demo:81/spsample/SLOConfirm.jsp

  6. Accept the default values for all other fields.
  7. Log in to the Policy Server Management Console and enable the session store.

    For instructions, see the Policy Server Administration Guide.

Test Single Logout

Use your own web pages to test single logout. Verify that your HTML page for testing SP-initiated single sign-on includes a hard-coded link to the single logout service.

After you successfully test single sign-on, you can test single logout. From the landing page that you created, click a link that directs the browser to the single logout URL using the HTTP redirect binding.

Configure SAML 2.0 Artifact Single Sign-on

Complete tasks at the Identity Provider and Services Provider to configure artifact single sign-on.

Required tasks at the Identity Provider:

Required tasks at the Service Provider:

Set Up the IdP Session Store for Artifact Single Sign-on

For artifact binding, set up and enable the session store at the IdP. When you use the artifact binding, the session store is required to store the assertion before it is retrieved with the artifact.

To enable the session store

  1. Install and configure an ODBC database to serve as the session store. In this deployment, we are using Microsoft SQL Server.

    For instructions, see the Policy Server Installation Guide.

  2. Open the Policy Server Management Console.
  3. Select the Data tab.
  4. Select Session Server From the Database drop-down list.
  5. Complete the following fields:
    Data Source Information

    SiteMinder Session Data Source

    User Name

    admin

    Password

    dbpassword

    Confirm Password

    dbpassword

    Maximum connections

    16 (default)

  6. Select the Enable Session Server check box.
  7. Click OK to save the settings.
  8. Enable SSL for the IdP Web Server for Artifact Single Sign-on.
Enable SSL for the IdP Web Server for Artifact Single Sign-on

Enable SSL for the web server where the Web Agent Option Pack is installed. Enabling SSL verifies that the back channel over which the assertion is passed is secure.

Follow these steps:

  1. Create a server-side certificate request.
  2. Have the Certificate Authority sign the server-side certificate.
  3. Specify the server-side certificate in the web server configuration.

    For the IIS Web Server used in the sample network, the IIS Certificate Wizard would be used.

  4. Enable a Persistent Session to Store Assertions at the IdP.
Permit Access to FWS Policy for the Artifact Resolution Service

The Web Agent Option Pack installs the Federation Web Services application (FWS). When you install the Policy Server for the same IdP as the Web Agent, several policies for services within the FWS application are automatically created. One of these policies protects the artifact resolution service for HTTP-Artifact single sign-on.

Specify which relying partners can access the artifact resolution service by enforcing protection of this artifact resolution policy.

Follow these steps: at the IdP

  1. Log on to the Administrative UI.
  2. Click Infrastructure, Agent, Agents.
  3. Click Create Agent.
  4. Enter idp-webagent in the Name field, which is the name of the agent in this sample deployment. Click Submit.
  5. Select Infrastructure, Agent Groups.
  6. Select the FederationWebServicesAgentGroup entry.

    The Agent Groups dialog opens.

  7. Click Add/Remove and the Agent Group Members dialog opens.
  8. Move idp-webagent from the Available Members list to the Selected Members list.
  9. Click OK to return to the Agent Groups dialog.
  10. Click Submit then click Close to return to the main page.
  11. Specify that all Service Providers in the affiliate domain Federation Sample Partners can access the artifact resolution service, as follows:
    1. Select Infrastructure, Policies, Domain, Domains.
    2. Select the FederationWebServicesDomain.
    3. Select the Policies tab, then click Modify.
    4. From the Policy List, click the Edit arrow to the right of the SAML2FWSArtifactResolutionServicePolicy entry.

      The Policy dialog opens.

    5. From the Users tab, select Add Members for the SAML2FederationCustomUserStore directory.

      The Users/Groups dialog opens.

    6. Select affiliate:FederationSamplePartners from the list and click OK.
    7. Click Submit to complete the changes.

The policy that protects the artifact resolution service is now being enforced.

Enable a Persistent Session to Store Assertions at the IdP

Enable a persistent session for the realm that contains the protected authentication URL (Protect the Authentication URL). The persistent session is required to store assertions for SAML artifact binding.

If you did not enable a persistent session when you protected the authentication URL, enable it now.

Follow these steps:

  1. Log in to the Administrative UI.
  2. Navigate to Infrastructure, Domain, Domains.
  3. Access the domain for the authentication URL. realm.
  4. From the Realms page, select the realm with the authentication URL and modify it.
  5. In the Session section, select Persistent.
  6. Click OK.
  7. Select the Artifact Binding at the IdP.
Select the Artifact Binding at the IdP

For artifact single sign-on, enable the artifact binding.

Follow these steps:

  1. Click Federation, Legacy Federation, SAML Service Providers.
  2. Select sp.demo to access the settings for this partner.
  3. Click Modify and select the SAML Profiles page.
  4. Complete the following fields:
    Audience

    sp.demo

    This value must match the value at the Service Provider.

    Assertion Consumer Service
    http://www.sp.demo:81/affwebservices/public/
saml2assertionconsumer
    Authentication Level, Validity Duration, AuthnContext Class Ref

    accept the defaults

    In a test environment, you can increase the Validity Duration value above 60, the default, if you see the following message in the Policy Server trace log:

    Assertion rejected (_b6717b8c00a5c32838208078738c05ce6237) - current time (Fri Sep 09 17:28:33 EDT 2005) is after SessionNotOnOrAfter time (Fri Sep 09 17:28:20 EDT 2005)
  5. In the Artifact Bindings section, select HTTP-Artifact
  6. For the Artifact Encoding field, select URL.

    The artifact is added to a URL-encoded query string.

  7. Go to the Attributes page.
  8. In the Backchannel section, complete the following fields:
    Password

    smfederation

    Confirm Password

    smfederation

    The Identity Provider uses this password for secure communication across the backchannel.

  9. Click Submit.
  10. Add a CA certificate to the certificate data store at the SP.
Add a CA Certificate for an SSL Back Channel at the SP

For artifact single sign-on, if Basic over SSL is the authentication scheme protecting the Artifact Resolution Service, add a certificate to the certificate data store at the Service Provider.

The certificate data store holds the Certificate Authority certificate that establishes an SSL connection between the Service Provider and the Identity Provider. The certificate secures the back channel that the assertion is sent across. Protect the Artifact Resolution Service and secure the back channel so the Service Provider knows that a trusted authority secures the SSL connection.

A set of common root and intermediate CAs are included with CA SiteMinder®. To use CA certificates that are not in the certificate data store, import them.

For this deployment, the alias is sampleAppCertCA and the certificate of the CA is docCA.crt.

Follow these steps:

  1. Log in to the Administrative UI.
  2. Click Infrastructure, X509 Certificate Management, Certificate Authorities.
  3. Click Import New.

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

  4. At the Select File step, select docCA.crt.

    The wizard skips the Password step.

  5. In the Select Entries step, enter sampleAppCertCA in the Alias column.
  6. At the Confirm step, review the certificate information and click Finish.

    The CA certificate is imported into the certificate data store. The change takes place directly after the import is complete.

  7. Enable the Artifact Binding for SAML Authentication at the SP.

Important! You cannot delete a CA certificate that is part of a trust chain for other certificates the system uses. If you try to delete a CA certificate in use, an error message states that the certificate cannot be deleted.

Enable the Artifact Binding at the Service Provider

At the Service Provider, configure the single sign-on bindings for the SAML authentication scheme. The configuration instructs the Service Provider how to communicate with the Identity Provider.

Follow these steps:

  1. Click Infrastructure, Authentication, Authentication Schemes.
  2. Select the Partner IDP.demo Auth Scheme. This authentication scheme is the one you created for the basic configuration.
  3. Select Modify, SAML 2.0 Configuration, SSO tab.
  4. Enter the following value for the Resolution Service field:

    https:/www.idp.demo:443/affwebservices/saml2artifactresolution

  5. Go to the Encryption & Signing page.
  6. In the Backchannel section, complete the following fields:
    Authentication

    Basic

    SP Name

    sp.demo

    Password

    smfederation

    Confirm Password

    smfederation

    The password must match the password at the Identity Provider. This password enables secure access across the back channel to the artifact resolution service at the Identity Provider.

  7. Click OK.
  8. Test SP-initiated artifact single sign-on.
Test Artifact Single Sign-on

Test single sign-on in a CA SiteMinder®-to-CA SiteMinder® network using your own web pages.

Your own HTML page must contain a hard-coded link to the AuthnRequest service. For this deployment, the link for Artifact binding is:

http://<server:port>/affwebservices/public/saml2authnrequest?ProviderID=
IdP_ID&ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
server:port

Defines the name and port of the server at the SP where the Web Agent Option Pack is installed.

IdP_ID

Defines the provider ID.

The link for this deployment is:

http://www.sp.demo:81/affwebservices/public/saml2authnrequest?ProviderID=
idp.demo&ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact

The HTML source file with the link is similar to the following example:

<a href="http://www.sp.demo:81/affwebservices/public/saml2authnrequest?ProviderID=
idp.demo&ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
Link for ARTIFACT Single Sign-on</a>

The AuthnRequest Service redirects the user to the Identity Provider specified in the link to retrieve the authentication context of the user. After the Identity Provider authenticates the user and establishes a session, it directs the user back to the target resource at the Service Provider.

Note: The ProviderID in the Authnrequest link must match the IdP ID field value at the SAML authentication scheme at the SP. The IdP ID field is on the Scheme Setup tab of the Authentication Scheme Properties dialog.

Now, follow the steps to test SP-initiated single sign-on.

Include an Attribute in the Assertion

You can add attributes from the user store record to a SAML assertion to identify a user. The attribute must exist in the user store of the Identity Provider for that specific user who is requesting access to the target resource.

For this deployment, add an attribute for user1 that represents the givenname in the user record.

Follow these steps: at the Identity Provider

  1. Log in to the Administrative UI.
  2. Click Federation, Legacy Federation, SAML Service Providers.
  3. Select sm.demo.
  4. Click Modify then navigate to the Attributes page.
  5. Click Add in the Attributes section.
  6. In the Add Attributes dialog, complete the following fields:
    Attribute Type

    unspecified (default)

    Attribute Kind

    User Attribute

    Variable Name

    firstname

    Attribute Name

    givenname

    givenname is an attribute in the profile of user1.

  7. Click OK to save your changes and return to the Attributes page.
  8. Click Submit.
Configure Digital Signing and Verification

For SAML 2.0 POST single sign-on, the Identity Provider must sign the SAML response. The configuration tasks at the Identity Provider enable digital signing. The configuration tasks at the Service Provider enable signature verification.

Important! In a production environment, signature processing is a mandatory security requirement.

Enable Signing at the Identity Provider

Keys and certificates that sign SAML assertions for POST binding are stored in the certificate data store. Signing a SAML response is required, so the certificate data store at the Identity Provider must contain the appropriate key/certificate pair.

Deploy the sample application using the key/certificate pair that it automatically installs. If you want to import a new key/certificate pair, complete the following procedures.

To import a private key/certificate pair

  1. Log in to the Administrative UI.
  2. Navigate to Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
  3. Import the private key/certificate idp.demo to the certificate data store.

    idp.demo signs the SAML response.

  4. Select Federation, Legacy Federation, SAML Service Providers.
  5. Select the Service Provider, sp.demo then go to the Encryption & Signing tab.
  6. Clear the Disable Signature Processing check box. Deselecting this check box means that signature processing is enabled.
  7. Complete the following fields:
    Signing Alias

    Enter the alias that you specified when importing the private key/certificate pair.

    Signing Algorithm

    RSAwithSHA1 (default)

    POST Signature Options

    Sign Assertion (default)

  8. Click Submit.
Enable Signature Validation at the Service Provider

For POST single sign-on, the Identity Provider must digitally sign the SAML assertion. Consequently, the Service Provider must validate the signature.

To validate a digital signature

To import the public key

  1. In the Administrative UI, navigate to Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
  2. Add the public key/certificate pair to the certificate data store. In this deployment, the certificate is post-cert.crt.

    The key/certificate pair is added to the data store.

  3. Click Submit.
  4. Navigate to Infrastructure, Authentication, Authentication Schemes.
  5. Select the SAML 2.0 authentication scheme, Partner IdP.demo Auth Scheme.
  6. Select the Encryption & Signing tab.
  7. In the D-Sign Info section, clear the Disable Signature Processing check box to enable signature processing.
  8. Specify the following field values:
    Issuer DN

    CN=Certificate Manager,OU=IAM,O=CA.COM

    Serial Number

    008D 8B6A D18C 46D8 5B

    The D-Sig information enables the Service Provider to verify the SAML response signature. The values for the Issuer DN and Serial Number are from the certificate stored in the certificate data store at the Service Provider.

  9. Click OK.

    Validation configuration is now complete.

  10. Test POST single sign-on.
Encrypt and Decrypt the Assertion

For added security, you can encrypt the assertion. Encryption is an optional task that can be performed after you have configured a basic single sign-on network.

The Identity Provider encrypts the assertion with the certificate that corresponds to the private key/certificate pair that the Service Provider uses to decrypt the assertion.

The configuration tasks are available at the Identity Provider and Service Provider.

Enable Encryption of the Asserton at the IdP

In this deployment, sp_encrypt.crt is the certificate for encryption.

To enable encryption at the IdP

  1. Log in to the Administrative UI.
  2. Navigate to Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
  3. Import the sp-encrypt.crt certificate into the certificate data store.
  4. Navigate to Federation, Legacy Federation, SAML Service Providers.
  5. Select sp.demo.
  6. Select Modify, SAML 2.0 Configuration.
  7. Go to the the Encryption & Signing tab.
  8. Select the Encrypt Assertion.
  9. Accept the defaults for the Encryption Block Algorithm and the Encryption Key Algorithm.
  10. In the Issuer DN, enter the issuer of the certificate. In this deployment, the DN is:

    CN=Doc Certificate Authority, OU=Doc, O=CA.COM

    Note: The value you enter for the Issuer DN field should match the issuer DN of the certificate in the certificate data store. View the DN to verify at you enter a matching value.

  11. In the Serial Number field, enter the serial number of the certificate in the certificate data store. In this deployment, the value is 00EFF6AFB49925C3F4

    The number must be hexadecimal.

  12. Click OK to save your changes.
  13. Decrypt an Encrypted Assertion at the SP.
Enable Decryption of the Assertion at the SP

If the assertion is encrypted at the Identity Provider, the Service Provider must have the private key and corresponding certificate in the certificate data store.

The Service Provider accepts an encrypted assertion from the Identity Provider as long as it has the private key/certificate pair to decrypt the assertion.

Note: You do not have to enable the Require an Encrypted Assertion feature to accept an encrypted assertion at the Service Provider.

Follow these steps:

  1. Open a command window.
  2. Navigate to Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
  3. Add the private key/certificate pair sp-encrypt.crt into the certificate data store. The alias for this pair is sp1privkey. The password for the private key is fedsvcs.
  4. Test single sign-on. Go to either of the following: