PAME-101
Certified Expert - PingAM
Parte de Certified Expert - PingAM
Proctored hands-on exam (3.5 hours). Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingAM version 8 or later.
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: Federation
PAME-101.1.01 Delegate authentication using SAML v2.0 (SAML2)
O que saber:- PingAM as hosted IdP or SP: circle of trust, entity providers, and the metadata exchange that bootstraps both sides.
- Delegated authentication means PingAM sends the user to a remote IdP and consumes the assertion; know which side owns the session.
- Assertion signing and encryption keys come from the secret stores configured in Section 4 - a federation failure is often a secret-store failure.
- Attribute mapping decides what the SP actually receives; NameID format choices (persistent, transient, email) drive account linking.
- Auto-federation and dynamic profile creation are the two answers to 'the user does not exist locally yet'.
PAME-101.1.02 Configure OAuth 2.0 (OAuth2)/OpenID Connect (OIDC) integration
O que saber:- PingAM as authorization server: clients (confidential vs public), grant types allowed per client, and scope-to-claim mapping.
- OIDC adds the ID token; know the claims script hook for customizing claims beyond the defaults.
- Authorization code with PKCE is the expected answer for browser and native clients; implicit and ROPC are retired.
- Token lifetimes, refresh-token rotation, and where the token store lives (CTS) are exam-relevant operational knobs.
- Consent handling and the OAuth2 provider service settings are configured at the realm level.
PAME-101.1.03 Configure Secret Token Service integration
O que saber:- Security Token Service (STS) bridges token formats: SAML assertion in, OIDC/JWT out, and the reverse - REST STS and SOAP STS instances.
- Token transformation is the core use case: a legacy SAML-speaking application fronting a modern OAuth API, or vice versa.
- Each STS instance declares its issuer, supported token types, and the credential it uses to sign issued tokens.
- Validate the trust chain on both input and output tokens; a transformation is only as trustworthy as its weakest validation step.
Section 2: Authorization
PAME-101.2.01 Integrate with a preconfigured PingGateway instance
O que saber:- PingGateway (formerly IG) enforces at the edge; PingAM decides. Know the agent/gateway split of responsibilities.
- The route configuration determines which requests are protected, and the PingAM policy set determines the decision.
- Single sign-on between gateway and PingAM relies on the session cookie domain and the configured AM URL.
- Common failure: gateway cannot reach the AM policy endpoint, or the agent profile credentials are wrong - check both before touching policy logic.
PAME-101.2.02 Configure policies
O que saber:- Policy sets contain policies; each policy names resources, actions, subjects, and environment conditions.
- Resource types define the actions available (GET/POST for URLs); policy evaluation returns allowed actions plus advice and response attributes.
- Subject conditions (authenticated users, groups, OAuth2 scope) and environment conditions (IP, time, authentication level) compose the decision.
- Advice is how a deny becomes a step-up prompt - the mechanism that ties authorization back into an authentication journey.
- Test with the policy evaluation REST endpoint before blaming the enforcement point.
PAME-101.2.03 Demonstrate how to check for risk continuously
O que saber:- Continuous risk means the session is re-evaluated after login, not just at the door - transactional authorization and session property changes.
- Policy advice can force step-up mid-session; combine with authentication level to gate sensitive actions.
- Signals can come from PingOne Protect or comparable risk sources feeding a decision node in the tree.
- The exam framing is scenario-based: given a risk signal, produce the configuration that re-challenges without ending the session.
Section 3: Authentication Trees
PAME-101.3.01 Demonstrate how to modify a user's authentication experience based on context
O que saber:- Trees are node graphs with outcomes; context comes from nodes that inspect device, IP, risk, or user attributes.
- Scripted decision nodes are the general-purpose escape hatch when no stock node fits.
- Inner trees allow reuse of a subflow across multiple journeys - the DRY principle applied to authentication.
- Shared state carries values between nodes; know which state (shared vs secure vs transient) is appropriate for secrets.
PAME-101.3.02 Configure social authentication
O que saber:- Social identity provider nodes (Google, Facebook, Apple, generic OIDC) federate the login and return a profile.
- Provisioning the local account is a separate decision: create, link to existing by email, or reject.
- Client ID and secret for each provider live in the social IdP service configuration; secrets belong in a secret store.
- Watch redirect URI registration on the provider side - the most common cause of a broken social flow.
PAME-101.3.03 Implement single sign-on (SSO)
O que saber:- SSO within a realm rests on the AM session cookie; cross-domain SSO (CDSSO) handles the different-domain case.
- Session upgrade preserves the session while raising the authentication level after a step-up.
- Know the difference between the AM session, the OIDC session, and the application session - three lifetimes that must be reasoned about separately.
- Logout must be considered end to end: local, federated, and back-channel where supported.
PAME-101.3.04 Given a scenario, configure mutli-factor authentication (MFA
O que saber:- Stock nodes cover OATH (TOTP/HOTP), push notification, WebAuthn/FIDO2, and recovery codes.
- Registration and authentication are distinct node paths; a complete tree handles the not-yet-registered user.
- Device profile and device match nodes let you skip MFA on a known device - the usual 'remember this device' requirement.
- Recovery codes and an administrative reset path are part of a correct design, not an afterthought.
Section 4: Core implementation tasks
PAME-101.4.01 Configure secret stores
O que saber:- Secret stores abstract where key material lives: keystore file, filesystem, HSM/KMS, or environment variables.
- Secret IDs are mapped to purposes (signing OIDC tokens, SAML assertions, TLS) - the mapping is the configuration.
- Rotation is supported by listing multiple secrets against one ID with different valid-from times.
- A misconfigured secret store surfaces as a federation or token-signing failure, so check it early in troubleshooting.
PAME-101.4.02 Demonstrate proper system tuning
O que saber:- JVM heap sizing, garbage collector choice, and thread pools are the first-order knobs.
- CTS (Core Token Service) sizing drives session and token throughput; monitor its LDAP backend.
- Connection pools to the identity store and CTS are common bottlenecks under load.
- Cache settings (session, policy, config) trade memory for latency; measure before and after.
PAME-101.4.03 Troubleshoot common issues
O que saber:- Read the logs in order: audit logs for what happened, debug logs for why, and the container log for startup failures.
- Increase debug level per component rather than globally to avoid drowning in output.
- Isolate the layer: browser (cookies, redirects), gateway/agent, AM, then the identity store.
- Reproduce with a REST call where possible - it removes the browser from the equation.
PAME-101.4.04 Demonstrate proper security hardening
O que saber:- Change all default administrative credentials and restrict the admin console to trusted networks.
- Disable unused authentication modules, services, and endpoints - reduce the reachable surface.
- Enforce TLS everywhere, set secure and httpOnly on cookies, and configure the cookie domain no broader than necessary.
- Follow the vendor hardening guide for the version deployed; hardening is version-specific and changes between releases.
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 →