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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.