Federation planning checklist

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.

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.

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.

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.

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 Server Clustering Guide.

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.

With PingFederate, you define a unique ID for each supported protocol. For more information, see Specifying federation information. 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.

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.

Identify the type of datastore that contains user data when needed. For more information, see Datastores.

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 and Token processors and generators.

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.

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.

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

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.