← All study guides
PFP-001
Certified Professional - PingFederate
Part of Certified Professional - PingFederate
Proctored by Kryterion (online or at a test center). Credential valid for 3 years. Recommended background: 6-12 months of hands-on PingFederate experience plus identity fundamentals (SAML, OAuth, LDAP, SCIM, REST, JSON).
Independent study aid built from the public exam blueprint. Not affiliated with, authorized by, or endorsed by ping. Exam objectives, versions, and availability change, so always verify against the official blueprint.
Section 1: Installation and Initial Configuration
1.01 Identify installation requirements for the product.
What to know:- PingFederate is a Java application: a supported 64-bit JVM is required - always confirm the exact Java releases on the system-requirements page for your target PingFederate version.
- Supported platforms cover current Windows Server and enterprise Linux distributions; the admin console supports current mainstream desktop browsers (Chrome, Firefox, Edge, Safari).
- Default ports: 9999 for the administrative console, 9031 for the runtime engine (both HTTPS, both set in run.properties). Plan firewall rules for admin access, runtime traffic, and back-channel calls to partners and data stores.
- Sizing separates roles: the console node is light; runtime engines are sized by concurrent SSO/OAuth load. Production runs clustered - one console, multiple engines.
Official manual: PingFederate documentation - system requirements (latest) ↗1.02 Describe how to install the product on Windows or Linux/UNIX
What to know:- The product ships as a distribution ZIP for all platforms (plus a Windows installer): extract to the installation directory, conventionally <pf_install>/pingfederate.
- Start in the foreground with bin/run.sh (Linux/UNIX) or bin\run.bat (Windows); for production install it as a service (Windows service scripts and Linux service integration are provided).
- Run the server as a dedicated non-root service account that owns the installation tree - never as root/Administrator.
- The ZIP install is self-contained: the core product needs no external database (configuration lives on the filesystem; clustering replicates it between nodes).
Official manual: PingFederate documentation - installation (latest) ↗1.03 Identify tasks completed during the initial configuration wizard.
What to know:- First visit to the admin console (https://<host>:9999/pingfederate/app) launches setup: accept the license agreement and import the license file.
- Create the initial administrative account - the first native admin user - and set its password.
- Confirm the server identity, notably the runtime base URL that partners and OAuth clients will use to reach this deployment.
- Recent releases offer an optional connection to PingOne during setup; a standalone deployment can skip it.
Official manual: PingFederate documentation - initial setup (latest) ↗1.04 Determine how to upgrade the product.
What to know:- The standard path is the Upgrade Utility: install the new version beside the old one and run the utility to copy configuration, adapters, and customizations into the new install (the Windows installer can also upgrade in place).
- Read the release notes and upgrade considerations for every version crossed - deprecations, renamed properties, and Java requirements change between releases.
- Classic post-upgrade tasks: merge custom logging configuration (log4j2 customizations are not carried automatically), re-apply UI and template customizations, re-test integrations.
- In a cluster: upgrade the administrative console node first, then the engines, then verify replication.
Official manual: PingFederate documentation - upgrade (latest) ↗
Section 2: Server Administration
2.01 Describe the locations and functions of different startup files.
What to know:- <pf_install>/pingfederate/bin holds the launchers: run.sh / run.bat start the server in the foreground; service scripts wrap them for production.
- bin/run.properties is the operational heart: admin and runtime ports and hostnames, and the operational mode (standalone vs. clustered console / clustered engine roles).
- bin/jvm-memory.options sets the Java heap and related JVM memory flags - the file to edit when sizing memory, not the launch scripts.
- Logging behavior lives in server/default/conf/log4j2.xml; templates, adapters, and deployed integration kits live under server/default/ as well - knowing which file owns which behavior is the exam's angle.
On this site: The PingFederate Startup Files: Who Controls WhatOfficial manual: PingFederate documentation - server configuration files (latest) ↗2.02 Describe how to set up logging into the administrative console with an LDAP data source.
What to know:- Console authentication is pluggable: native accounts are the default, and LDAP (among others) can replace them for admin sign-on.
- The switch is made in bin/run.properties (the console-authentication property selects LDAP), with the LDAP specifics - server reference, search bases, and the mapping of directory groups to admin roles - configured in the accompanying ldap.properties file.
- Role mapping is the point: directory group membership determines which administrative roles a signed-in admin receives.
- A restart of the console is required for the authentication-mode change to take effect; keep a break-glass path in mind when moving away from native accounts.
2.03 Describe how to install or upgrade the PingFederate license.
What to know:- The license arrives as a license file from Ping Identity; the initial setup imports it, and later replacements are imported from the admin console's license page (no restart needed for a console import).
- The license can also be placed directly in the server's configuration directory when scripting or automating installs.
- The console surfaces license details - product edition, expiration - and the server warns as expiration approaches; connection or feature limits depend on the license type.
- Version upgrades commonly require a license issued for the new major version: check license validity as part of every upgrade plan.
On this site: PingFederate Operational Hygiene: License, Notifications, and the Configuration ArchiveOfficial manual: PingFederate documentation - license management (latest) ↗2.04 Describe the use of native accounts in PingFederate or how Role-Based Access Controls are used to manage administrative functionality.
What to know:- Native accounts are created and managed in the admin console; each account is assigned one or more administrative roles rather than blanket access.
- The role set to know: User Admin (manages admin accounts), Admin (configuration changes), Expression Admin (may author OGNL expressions - gated separately because expressions execute code), Auditor (view-only), and the cryptographic role for key and certificate management.
- Roles combine: a working administrator typically holds Admin plus whatever else the job needs; Auditor is exclusive by nature (view-only).
- The same role model applies when console authentication is external (LDAP/RADIUS/certificate): the external identity is mapped onto these roles.
2.05 Describe how to configure runtime notifications.
What to know:- PingFederate can notify administrators of operational events - certificate expiration and licensing events are the classic examples.
- Delivery goes through notification publishers (SMTP-based email being the standard one); a publisher instance is configured once and selected wherever notifications are needed.
- Certificate-expiration warnings are the exam-favorite scenario: configure the publisher, then enable notifications so expiring runtime certificates alert before they break partners.
- Runtime state can additionally be watched via the heartbeat endpoint for monitoring systems - notifications cover events, the heartbeat covers liveness.
On this site: PingFederate Operational Hygiene: License, Notifications, and the Configuration ArchiveOfficial manual: PingFederate documentation - notifications (latest) ↗2.06 Describe how to manage configuration archive creation and retention.
What to know:- The configuration archive (data.zip) is the full export of a server's configuration: export and import live in the admin console, and importing an archive replaces the configuration wholesale.
- PingFederate also snapshots configuration automatically when changes are deployed, retaining recent archives on disk under the server's data directory - the built-in undo.
- Retention of those automatic archives is configurable; treat archives as sensitive material (they contain the configuration, including references to credentials) and back them up accordingly.
- Archives are the supported mechanism for config backup, migration between environments, and disaster recovery of a node.
On this site: PingFederate Operational Hygiene: License, Notifications, and the Configuration ArchiveOfficial manual: PingFederate documentation - configuration archive (latest) ↗2.07 Describe the server endpoints.
What to know:- Two families: administrative endpoints on the console port (the admin console app and the administrative API under /pf-admin-api, with interactive API docs available), and runtime application endpoints on the engine port.
- Runtime SSO application endpoints live under /idp and /sp (startSSO, startSLO, and the protocol endpoints); OAuth authorization-server endpoints live under /as; OIDC adds userinfo and discovery paths.
- The heartbeat endpoint (/pf/heartbeat.ping) answers on the runtime port for load balancers and monitoring.
- Knowing which port and path family an endpoint belongs to - admin vs runtime - is the recurring exam angle.
Official manual: PingFederate documentation - endpoints reference (latest) ↗2.08 Describe how to manage SSL certificates, Certificate Authorities, and Certificate Signing Requests.
What to know:- Security > Certificate & Key Management is the home: SSL server certificates (with separate activation for the admin console vs the runtime), trusted Certificate Authorities, and the signing/decryption keys used for SAML and OAuth.
- The CSR workflow: generate a key pair on the server, export the Certificate Signing Request, have the CA sign it, then import the signed response back onto the same entry - the private key never leaves.
- Trusted CA entries are what let PingFederate validate certificates presented by partners and back-channel connections; missing intermediates are a classic trust failure.
- Rotation discipline: activate new certificates ahead of expiry, and pair this objective with runtime notifications (2.05) so expiry never arrives unannounced.
On this site: Certificate signing requests and how certificates are issued, PEM, DER, and the certificate file formats, How certificate validation actually worksOfficial manual: PingFederate documentation - certificate management (latest) ↗2.09 Describe how to configure or manage LDAP and JDBC external data stores.
What to know:- Data stores are reusable connection definitions consumed by credential validators, attribute lookups, and provisioning - configure once, reference everywhere.
- LDAP data stores: directory type, one or more host entries for failover, service-account bind credentials, and LDAPS/secure options; the directory schema drives later attribute lookups.
- JDBC data stores: the JDBC connection URL, credentials, and a validation query - and the matching JDBC driver JAR must be deployed into the server's library directory before the store can connect.
- Failover and connection testing are built into the definitions; runtime behavior degrades predictably when a store is down, which is why validation queries and multiple LDAP hosts matter.
On this site: PingFederate Data Stores: LDAP and JDBC, Defined Once, Used Everywhere, LDAP Fundamentals: The Directory Model Behind Identity Systems, SCIM: The Standard That Provisions the Accounts SSO Signs InOfficial manual: PingFederate documentation - data stores (latest) ↗2.10 Determine how to configure Password Credential Validators or any of the following adapters: HTML Form Adapter, HTTP Basic Adapter, Kerberos Adapter, OpenToken Adapter, Reference ID Adapter
What to know:- Password Credential Validators (PCVs) verify username/password against a source - the LDAP Username PCV being the workhorse - and are consumed by adapters rather than used directly.
- HTML Form Adapter: the interactive branded login page; chains one or more PCVs, and owns the classic account-service features (lockout tracking, password change and reset flows, remember-my-username).
- HTTP Basic Adapter: the 401 browser challenge backed by a PCV - no page, no session niceties; for APIs and legacy clients.
- Kerberos Adapter: silent desktop SSO via SPNEGO/IWA - requires the realm and KDC details plus a service account/keytab on the PingFederate side and browser configuration on the client side.
- OpenToken Adapter: the integration-kit pattern - passes the authenticated identity to (or from) an application as an encrypted OpenToken via cookie, query parameter, or POST.
- Reference ID Adapter: the agentless pattern - the application exchanges a short-lived reference with PingFederate over a secured back-channel drop-off/pick-up API instead of parsing tokens itself.
2.11 Describe the locations, purposes, and logging levels for different PingFederate log files.
What to know:- All logs live in <pf_install>/pingfederate/log. The cast: server.log (the main application log), admin.log (administrator actions in the console), admin-api.log (administrative API calls), transaction.log (runtime protocol transaction summaries), audit.log (runtime authentication and security events), provisioner.log, init.log, and the HTTP request log.
- Security-event tracking pairs audit.log (who authenticated, how, and with what result) with transaction.log (per-transaction protocol summaries) - the two to name for tracking security-related events and transaction history.
- Verbosity is controlled per logger in server/default/conf/log4j2.xml with the standard level ladder (TRACE, DEBUG, INFO, WARN, ERROR); transaction logging additionally has its own configurable detail modes.
- Operational habit the exam rewards: admin actions are answered from admin.log, runtime SSO questions from audit/transaction logs, server health from server.log.
Official manual: PingFederate documentation - log files (latest) ↗2.12 Determine how to perform basic configuration of policy trees.
What to know:- Authentication policy trees decide HOW a user authenticates: nodes are authentication sources (adapter instances or IdP connections) and selectors, with Fail and Success branches flowing top-down.
- Selectors branch on context without authenticating - by requested application, network range, extended properties, and similar signals - so one tree can route different populations to different sources.
- A successful path ends by fulfilling an Authentication Policy Contract (APC): the normalized set of attributes that downstream mappings consume.
- Reusable fragments keep trees maintainable: build a common sequence once (for example, form login with second factor) and reference it from multiple policies; policy evaluation order and the fallback to defaults complete the basic picture.
Official manual: PingFederate documentation - authentication policies (latest) ↗
Section 3: SSO Connections and Attribute Mapping
3.01 Explain the difference between mapping attributes at the connection level, the adapter level, and authentication policy contracts.
What to know:- Three layers, three jobs. Adapter level: the adapter's attribute contract declares what the authentication source emits (and can be extended with additional attributes the adapter can supply).
- Authentication Policy Contract (APC) level: the normalization layer - whatever source authenticated the user, the policy fulfills one common contract, so downstream configuration is source-independent.
- Connection level: per-partner fulfillment - the SP connection's attribute contract defines what THIS partner's assertion carries, fulfilled from the APC/adapter values, data-store lookups, expressions, or static text.
- The design consequence the exam probes: map partner-specific shaping at the connection, keep the APC generic, and let adapters stay ignorant of partners - changing one partner then never touches the others.
Tools: saml-decoder3.02 Describe the SSO endpoints and variables.
What to know:- Application endpoints start flows: /idp/startSSO.ping begins an IdP-initiated SSO transaction; /sp/startSSO.ping begins an SP-initiated one. Their SLO twins are /idp/startSLO.ping and /sp/startSLO.ping.
- The variables to know cold: PartnerSpId (which SP connection, on the IdP start), PartnerIdpId (which IdP connection, on the SP start), and TargetResource (where the user should land after SSO - the deep link).
- Protocol endpoints then carry SAML itself: the IdP's SSO service and the SP's Assertion Consumer Service receive the protocol messages the start endpoints set in motion.
- Reading a start-URL and stating which side initiates, which partner is addressed, and where the user lands is exactly the exam's use of this objective.
On this site: SAML Bindings and SP vs IdP InitiationTools: saml-decoderOfficial manual: PingFederate documentation - SSO application endpoints (latest) ↗3.03 Define the difference between IdP-initiated and SP-initiated connections and when each is used.
What to know:- IdP-initiated: the flow starts at the identity provider (portal link, /idp/startSSO.ping) and sends an unsolicited assertion to the SP - no AuthnRequest exists.
- SP-initiated: the user arrives at the service provider first; the SP issues an AuthnRequest to the IdP, authentication happens, and the assertion answers that specific request (with RelayState preserving the destination).
- When each fits: IdP-initiated suits portal launchpads; SP-initiated suits bookmarks and deep links into the application and is required whenever the SP insists on validating that it asked (many SPs accept only solicited assertions).
- TargetResource on the start endpoints and RelayState in the protocol are the deep-link carriers - same purpose, different layer.
Tools: saml-decoderOfficial manual: PingFederate documentation - IdP and SP configuration (latest) ↗
Section 4: OAuth and OIDC Configuration
4.01 Describe the purpose and use of OAuth Scopes, Token Managers, Clients, and Endpoints.
What to know:- Scopes are named permissions with descriptions (shown at consent): common scopes are available to all clients, exclusive scopes only to the clients explicitly granted them.
- Access Token Managers (ATMs) define what an access token IS: Internally Managed Reference issues opaque tokens the resource must introspect; the JSON Web Token manager issues self-contained signed JWTs. The ATM's attribute contract decides what the token carries.
- Clients are the registered applications: client ID, an authentication method for confidential clients (secret, private-key JWT, mutual TLS), redirect URIs, the grant types each may use, and the ATM that mints its tokens.
- The authorization-server endpoints live under /as - authorization, token, introspection, and revocation - and knowing which endpoint serves which step of a flow is the recurring question shape.
On this site: Access tokens, refresh tokens, and ID tokens, Public vs confidential clients, and where PKCE fits, Anatomy of a JSON Web TokenTools: jwtOfficial manual: PingFederate documentation - OAuth configuration (latest) ↗4.02 Determine the appropriate usage for different grant types.
What to know:- Authorization Code is the default answer for user-facing applications: browser redirect, code exchanged at the token endpoint - confidential clients authenticate the exchange, public clients protect it with PKCE.
- Client Credentials is machine-to-machine: no user, the client authenticates as itself and receives a token representing the client.
- Refresh tokens extend sessions without re-authentication and come with rotation/reuse policies; Device Authorization serves input-constrained devices via user-code on a second screen.
- Implicit and Resource Owner Password Credentials are the legacy pair: recognize them, know why modern guidance retires them (tokens in front-channel; passwords handled by the client), and prefer code+PKCE in every scenario question.
On this site: The OAuth 2.0 authorization code flow, Public vs confidential clients, and where PKCE fitsTools: pkceOfficial manual: PingFederate documentation - grant types (latest) ↗4.03 Describe how to configure OpenID Connect Policy Management.
What to know:- An OIDC Policy defines the ID token: its attribute contract (the claims), how each claim is fulfilled from the authentication result and data stores, and inclusion of session-related claims.
- Policies are selected per client (with a default policy for the authorization server), so different applications can receive differently shaped ID tokens from the same provider.
- ID-token signing and the issuer identity come from the OAuth/OIDC server configuration the policy rides on - the policy shapes content, the server settings shape trust.
- Standard claims (sub, iss, aud, exp, auth_time, nonce) arrive from the protocol; the policy's job is the additional identity claims your applications actually consume.
On this site: The ID Token Claims, and What a Relying Party Checks, OpenID Connect: An Identity Layer on OAuth 2.0Official manual: PingFederate documentation - OpenID Connect policies (latest) ↗4.04 Describe the OpenID Connect endpoints and their purposes.
What to know:- Discovery first: /.well-known/openid-configuration publishes the provider's metadata - every other endpoint, the supported scopes, response types, and signing algorithms - so clients configure themselves.
- The UserInfo endpoint returns claims about the authenticated user to a caller presenting a valid access token; the JWKS endpoint publishes the public keys that verify ID-token (and JWT access-token) signatures.
- Authorization and token endpoints are shared with plain OAuth under /as - OIDC is OAuth with an identity layer, and the endpoint map shows exactly that.
- Exam angle: match each endpoint to its consumer - browsers hit authorization, clients hit token and discovery, resource servers hit JWKS or introspection, and UserInfo serves the client after login.
On this site: OIDC Discovery: The openid-configuration Document, OpenID Connect: identity on top of OAuth 2.0Official manual: PingFederate documentation - OIDC endpoints (latest) ↗4.05 Describe how to use OpenID Connect for SSO.
What to know:- OIDC as the SSO protocol: the application is an OAuth client (Relying Party), PingFederate is the OpenID Provider, and the authorization-code flow returns an ID token that IS the authentication statement.
- The provider session is what makes it single sign-on: the second application's authorization request finds an existing authenticated session and completes without new credentials.
- Validation discipline on the RP side: verify the ID token's signature against the JWKS, plus issuer, audience, expiry, and nonce - the checklist that makes the ID token trustworthy.
- PingFederate can also sit on the other side - acting as the relying party toward an upstream OIDC provider via an IdP connection - which is how OIDC federates the same way SAML connections do.
Tools: oidcOfficial manual: PingFederate documentation - OIDC use cases (latest) ↗