Skip to content
CA Single Sign-On - 12.52 SP1
Documentation powered by DocOps

Getting Started with a Simple Partnership

Last update April 27, 2016

One way to get started with partnership federation is by configuring a partnership. This chapter describes how to set up a basic SAML 2.0 federation partnership—single sign-on with SAML 2.0 POST profile

Contents

Basic SAML 2.0 Partnership

By starting with a basic configuration, you can complete the least number of steps to see how partnership federation works.

Note: This partnership focuses on SAML 2.0; however, the overall process is the same for SAML 1.1. The configuration settings at each step of the partnership can differ depending on the SAML protocol.

The chapter also describes the configuration of additional features, such as digital signing and single logout to reflect a real production environment. You can also add the Artifact binding to the configuration.

The sample network used in this chapter presupposes that CA Single Sign-On is installed at both sites in the partnership. However, you can have CA Single Sign-On at one site and a different SAML-compliant product at the other site and still engage in a partnership.

With CA Single Sign-On at both sites, you have to understand the perspective from which you are configuring a partnership. To configure a complete partnership, you begin by defining a partnership definition at each site, one for each direction of communication from a given site. For example, if the local site is the Identity Provider (IdP), you configure the local IdP-to-remote SP partnership. This configuration is one partnership definition. To complete the partnership configuration, you configure the reciprocal local SP-to-remote IdP partnership at the local SP.

The partnership definition always distinguishes the local and remote entities. The local entity is the entity at the site from where you are configuring partnership federation. This environment is not necessarily the same as the one on which CA Single Sign-On is installed, but the same domain. The remote entity is the entity at a partner that resides in a different domain from where you are configuring partnership federation.

The following process shows the steps for creating the basic partnership when CA Single Sign-On is at both sites:

  1. Establish a user directory connection.
  2. Protect the authentication URL to establish a session.
  3. Create the local and remote entities.
  4. Configure the local IdP-to-SP partnership definition at the IdP.
  5. Configure the local SP-to-IdP partnership definition at the SP.
  6. Activate the partnership.
  7. Test the partnership.

Sample Federation Network

The initial partnership that you are creating represents the following sample network. The URLs in the procedures and sample network are examples and do not resolve to any real site.

  • The Business Partners
    • Identity Provider named IdP1
    • Service Provider named SP1
  • SAML Profiles and Features
    • SAML 2.0 with POST profile
    • Single sign-on
    • No signature processing
    • FIPS_COMPAT mode
  • SSO Service URL at the IdP
    http://idp1.example.com:9090/affwebservices/public/saml2sso
  • Assertion Consumer Service URL at the SP
    http://sp1.demo.com:9091/affwebservices/public/saml2assertionconsumer
Note: You need two systems with CA Single Sign-On installed to implement this sample network.

The following figure shows the sample partnership with CA Single Sign-On at both partners.

partnership federation simple setup

Confirm that Required Components are Installed

To use partnership federation, the following components are required:

  • Policy Server
  • Administrative UI
  • Web Agent
  • Web Agent Option Pack
    The Web Agent Option pack includes the Federation Web Services (FWS) application. FWS is a required component for federation.

This simple partnership deployment example assumes that these components are installed and working.

Was this helpful?

Please log in to post comments.