← Todos os guias de estudo
PFP-001
Certified Professional - PingFederate
Parte de 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).
Material de estudo independente, construído a partir do blueprint público da prova. Sem afiliação, autorização ou endosso da ping. Os objetivos são transcritos e mapeados à mão, então esta página pode conter erros ou estar defasada em relação ao material atual do fabricante: objetivos, versões, numeração e disponibilidade mudam sem aviso. Trate o portal de certificação da própria ping como a fonte da verdade e confira nele antes de agendar qualquer coisa.
Section 1: Installation and Initial Configuration
1.01 Identify installation requirements for the product.
O que saber:- 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.
1.02 Describe how to install the product on Windows or Linux/UNIX
O que saber:- 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).
Manual oficial: PingFederate documentation - installation (mais recente) ↗1.03 Identify tasks completed during the initial configuration wizard.
O que saber:- 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.
Manual oficial: PingFederate documentation - initial setup (mais recente) ↗1.04 Determine how to upgrade the product.
O que saber:- 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.
Manual oficial: PingFederate documentation - upgrade (mais recente) ↗
Section 2: Server Administration
2.01 Describe the locations and functions of different startup files.
O que saber:- <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.
2.02 Describe how to set up logging into the administrative console with an LDAP data source.
O que saber:- 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.
O que saber:- 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.
Manual oficial: PingFederate documentation - license management (mais recente) ↗2.04 Describe the use of native accounts in PingFederate or how Role-Based Access Controls are used to manage administrative functionality.
O que saber:- 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.
O que saber:- 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.
Manual oficial: PingFederate documentation - notifications (mais recente) ↗2.06 Describe how to manage configuration archive creation and retention.
O que saber:- 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.
2.07 Describe the server endpoints.
O que saber:- 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.
2.08 Describe how to manage SSL certificates, Certificate Authorities, and Certificate Signing Requests.
O que saber:- 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.
2.09 Describe how to configure or manage LDAP and JDBC external data stores.
O que saber:- 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.
Neste site: Data Stores do PingFederate: LDAP e JDBC, Definidos Uma Vez, Usados em Todo Lugar, Fundamentos de LDAP: O Modelo de Diretório por Trás dos Sistemas de Identidade, SCIM: O Padrão Que Provisiona as Contas Que o SSO AutenticaManual oficial: PingFederate documentation - data stores (mais recente) ↗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
O que saber:- 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.
O que saber:- 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.
Manual oficial: PingFederate documentation - log files (mais recente) ↗2.12 Determine how to perform basic configuration of policy trees.
O que saber:- 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.
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.
O que saber:- 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.
Ferramentas: saml-decoder3.02 Describe the SSO endpoints and variables.
O que saber:- 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.
Neste site: Bindings SAML e iniciação por SP vs IdPFerramentas: saml-decoder3.03 Define the difference between IdP-initiated and SP-initiated connections and when each is used.
O que saber:- 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.
Ferramentas: saml-decoder
Section 4: OAuth and OIDC Configuration
4.01 Describe the purpose and use of OAuth Scopes, Token Managers, Clients, and Endpoints.
O que saber:- 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.
4.02 Determine the appropriate usage for different grant types.
O que saber:- 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.
Neste site: O fluxo de código de autorização do OAuth 2.0, Clientes públicos vs confidenciais, e onde o PKCE se encaixaFerramentas: pkceManual oficial: PingFederate documentation - grant types (mais recente) ↗4.03 Describe how to configure OpenID Connect Policy Management.
O que saber:- 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.
4.04 Describe the OpenID Connect endpoints and their purposes.
O que saber:- 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.
Neste site: OIDC Discovery: O Documento openid-configuration, OpenID Connect: identidade sobre o OAuth 2.0Manual oficial: PingFederate documentation - OIDC endpoints (mais recente) ↗4.05 Describe how to use OpenID Connect for SSO.
O que saber:- 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.
Ferramentas: oidcManual oficial: PingFederate documentation - OIDC use cases (mais recente) ↗
Fontes públicas, usadas de boa-fé
Estes guias são materiais de estudo independentes, montados a partir de conteúdo publicamente disponível: blueprints de exame publicados, documentação oficial de produto e catálogos de treinamento dos fabricantes. Nomes de produtos, códigos de exame e marcas pertencem a seus titulares e são usados apenas para identificar o assunto ensinado. Este site não é afiliado a nenhum fabricante aqui citado nem endossado por ele. Se você detém direitos sobre material publicado nesta página e entende que ele deve ser removido ou corrigido, envie a URL exata e uma breve nota sobre o problema pela página de contato; os pedidos são analisados com rapidez e boa-fé. Ler o aviso legal completo →