---
title: Federation planning checklist
description: An essential first step in establishing an identity federation involves discussions and agreements between you and your connection partners. The sections below comprise a partial checklist of items that should be coordinated before you deploy PingFederate.
component: pingfederate
version: 13.1
page_id: pingfederate:introduction_to_pingfederate:pf_fed_plan_checklist
canonical_url: https://docs.pingidentity.com/pingfederate/13.1/introduction_to_pingfederate/pf_fed_plan_checklist.html
llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: July 5, 2022
section_ids:
  standards-and-specifications: Standards and specifications
  signing-and-validation: Signing and validation
  back-channel-security: Back-channel security
  trusted-certificate-management: Trusted certificate management
  deployment: Deployment
  federation-server-identification: Federation server identification
  server-clock-synchronization: Server clock synchronization
  user-data-stores: User data stores
  web-application-and-session-integration: Web application and session integration
  transaction-logging: Transaction logging
  identity-mapping: Identity mapping
  attribute-contract-agreement: Attribute contract agreement
  metadata-exchange: Metadata exchange
---

# Federation planning checklist

An essential first step in establishing an identity federation involves discussions and agreements between you and your connection partners. The sections below comprise a partial checklist of items that should be coordinated before you deploy PingFederate.

## Standards and specifications

Choose which federation protocols your deployment will support. For SAML single sign-on (SSO) configurations, decide which profiles and bindings will be used. For more information, see [Supported Standards](pf_supported_standards.html).

## Signing and validation

Decide which SAML messages—assertions, responses, requests—will be digitally signed and how the messages will be verified by your federation partner. If messages are signed, decide how certificates will be exchanged, for example, secure email. For more information, see [Security infrastructure](pf_sec_infras.html).

## Back-channel security

Determine what type of SOAP channel authentication will be used: Basic or SSL/TLS. If SSL/TLS is used, determine whether server-only or both server and client certificates will be needed and how they will be managed. Also decide what level of security will be required for connections to back-end datastores or identity management systems.

## Trusted certificate management

Determine whether both partners are using SSL/TLS runtime certificates, signing certificates, or both that have been signed by a major certificate authority (CA). If self-signed certificates or nonstandard CAs are used, the signed certificates must be exchanged and imported into Trusted Certificate stores. Also, determine whether you want to adopt a trust model that uses embedded certificates. For more information, see [Digital signing policy coordination](pf_digi_sign_poli_coordin.html).

## Deployment

Decide how PingFederate fits into your existing network. Also, determine whether high-availability, failover options, or both, are required. For more information, see the PingFederate [About Server Clustering](../server_clustering_guide/pf_server_clustering_guide.html).

## Federation server identification

Determine how you and your partners will identify your respective federation deployments. Under federation standards, both the sender, the identity provider (IdP), and the receiver, service provider (SP), of an assertion must be uniquely identified within the identity federation. For more information, see [Configuration data exchange](pf_config_data_exchange.html).

With PingFederate, you define a unique ID for each supported protocol. For more information, see [Specifying federation information](../administrators_reference_guide/help_protocolsettingstasklet_federationinfostate.html). Optionally, you can also use a list of multiple virtual server IDs on a connection-by-connection basis. For more information, see [Multiple virtual server IDs](virtual_server_id.html).

|   |                                                                                                                                                                                                                                                                                                                                                                                                                              |
| - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | PingFederate also provides for virtual host names, which differ from virtual server IDs but are not mutually exclusive; they are intended for use when your network configuration is such that you receive federation messages under more than one domain name. For more information, see [Configuring virtual host names](../administrators_reference_guide/help_managevirtualhostnamestasklet_virtualhostnamesstate.html). |

## Server clock synchronization

Ensure that both the SP and IdP server clocks are synchronized. SAML messages and security token service (STS) tokens provide a time window that allows for small synchronization differentials. However, wide disparities will result in assertion or request time-outs.

## User data stores

Identify the type of datastore that contains user data when needed. For more information, see [Datastores](pf_datastores.html).

## Web application and session integration

Decide how PingFederate as an IdP receives subject identity information, either from an STS token or a user session.

For an SP, decide how PingFederate will forward user identity information to the destination web application or system to start a session. For more information, see [Bundled adapters and authenticators](pf_bundled_adapt_auth.html) and [Token processors and generators](pf_token_proc_and_gen.html).

## Transaction logging

PingFederate provides basic transaction logging and monitoring. Decide whether transaction logging should be integrated with a systems management application and whether you have regulatory compliance requirements that affect your logging processes. For more information, see [PingFederate log files](../administrators_reference_guide/pf_log_files.html).

## Identity mapping

For browser-based SSO, decide whether you will use PingFederate to link accounts on your respective systems using a persistent name identifier, or whether you will use account mapping. For more information, see [Identity mapping](pf_ident_mapp.html).

## Attribute contract agreement

If your federation partnership will not use account linking, or will not use it exclusively, then you and your partner must agree on a set of attributes that the IdP will send in an assertion for either SSO or web service access. For more information, see [Attribute contracts](pf_attr_contract.html)

## Metadata exchange

If you are using SAML, decide whether you will use the metadata standard to exchange XML files containing configuration information. PingFederate makes it easy to use this protocol, which provides a significant shortcut to setting up your partner connections.