PingFederate cheat sheet

PingFederate Administration

• PingFederate runs as a Java-based server with two node roles: the engine (runtime SSO/STS processing) and the admin console (configuration UI); a single install can host either or both.

• Configuration is stored in a central datastore (internal H2 by default, or external database such as MS SQL/MySQL/Oracle); clustered nodes must point to a shared external datastore, not H2.

• Replication across a cluster is triggered by config changes propagating from the admin node; a node that cannot reach the datastore or admin will serve stale config and must be re-synced.

• Admin API is enabled per node (Admin API Applications and Client Credentials) and is the supported path for automated configuration; OAuth client credentials grant issues the access token used against /pf-admin-api endpoints.

• Connection types determine protocol role: SP Connections for SAML/OIDC/WS-Fed relying party, IdP Connections for federation partners, and IdP Adapter instances (HTML Form, Kerberos, composite, etc.) for authentication sources.

• Signing and encryption certificates live under Security > Signing & Encryption; each certificate has an assigned usage (signing, encryption, SSL) and must be valid and trusted by partners to avoid signature validation failures.

• Authentication policies (IdP) bind adapters to contract mappings; selectors route by attribute, and policy must map every required attribute in the authentication contract or SSO fails with a missing-attribute error.

• Session management is configured under Session settings: idle timeout, maximum session lifetime, and per-SP session overrides; revoking a session invalidates the SSO cookie and forces re-authentication.

• Backups use the administrative console export (configuration archive) and database-level dumps; restore requires matching product version and re-establishing cluster membership.