← Todos os guias de estudo
PAAA-001
Certified Expert - PingAccess
Parte de Certified Expert - PingAccess
Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingAccess version 7 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.
Objective 1: Advanced Configuration
PAAA-001.1.01 Create a Web+API application object in the admin console
O que saber:- A Web+API application serves both browser traffic and programmatic API calls under one application object.
- Web traffic uses a web session (cookie-based); API traffic uses OAuth bearer tokens; the application carries both configurations.
- Resource-level settings decide which path patterns are treated as web and which as API.
- This is the pattern for a single-page application calling its own backend API on the same host.
- Get the destination and virtual host right first; authentication configuration on top of a broken route is unverifiable.
PAAA-001.1.02 Create an application
O que saber:- An application binds a virtual host and context root to a site or agent, plus a web session and identity mapping.
- Application type (Web, API, or Web+API) determines which authentication mechanisms are available.
- Context root determines the path prefix PingAccess owns; overlapping roots on the same virtual host are a configuration error.
- Resources within the application refine policy per path.
- The application is the top-level unit of policy; almost every other object is referenced from it.
PAAA-001.1.03 Create a virtual host
O que saber:- A virtual host is host plus port, matched against the incoming Host header.
- Wildcards are supported for the host portion; the most specific match wins.
- Agents and gateways both dispatch on virtual host, so it must correspond to the name the client actually uses.
- Key pair selection for TLS is associated with the listener, and the certificate must cover the virtual host name.
- A mismatch between the browser's Host header and the configured virtual host is the most common cause of unexpected 404s.
PAAA-001.1.04 Create a web session
O que saber:- A web session defines the cookie that represents an authenticated browser session at PingAccess.
- Configuration covers audience, cookie type (encrypted JWT), idle and max timeouts, and the OIDC client used against the token provider.
- Audience scopes the cookie so it cannot be replayed against a different application.
- Session state can be stored in the cookie or server-side, which affects clustering and revocation.
- Timeout values are a security and usability trade; document why the chosen values were selected.
PAAA-001.1.05 Create a web identity mapping
O que saber:- A web identity mapping decides how the authenticated identity is passed to the backend site.
- Header identity mapping injects attributes as HTTP headers; JWT identity mapping passes a signed token.
- The backend must trust PingAccess and refuse the same headers from any other source, or the mapping becomes a spoofing vector.
- Attribute names in the mapping must match what the application expects, exactly.
- Identity mapping is the bridge between federated identity and a legacy application that only understands headers.
PAAA-001.1.06 Create a site
O que saber:- A site is the backend target: one or more host:port targets plus TLS and connection settings.
- Availability profiles decide how failures are handled across targets; load balancing strategies decide distribution.
- Trust for the backend certificate comes from a trusted certificate group when the site uses TLS.
- Expected hostname must match the backend certificate, or verification fails.
- Sites are referenced by applications, so one site can serve several applications.
PAAA-001.1.07 Create a site authenticator
O que saber:- A site authenticator lets PingAccess authenticate itself to the backend site.
- Types include basic authentication, mutual TLS, and the token mediator.
- This is separate from authenticating the end user; it secures the hop between PingAccess and the application.
- Without one, a backend that requires credentials will reject PingAccess-forwarded requests.
- Credentials are stored in the configuration and should be rotated as normal secrets.
PAAA-001.1.08 Configure POST preservation
O que saber:- POST preservation captures a form submission that arrives at an unauthenticated session, so it survives the redirect to the token provider.
- Without it, the user authenticates and then loses the data they had typed.
- Configure the maximum preserved body size; oversized posts are dropped rather than stored.
- It applies to web applications, not APIs.
- Test with a real form, because the failure mode is invisible until a user complains about lost input.
PAAA-001.1.09 Configure redirects, for example, from port 80 to port 443
O que saber:- Redirects from HTTP to HTTPS are configured with a listener on the plain port and a redirect target.
- The redirect should preserve path and query string so the user lands where they intended.
- HSTS response headers complement the redirect by preventing the plaintext request next time.
- Confirm the redirect target uses the externally-visible hostname, not an internal one.
- This is infrastructure hygiene rather than access policy, but it is examinable configuration.
PAAA-001.1.10 Create an authentication requirements rule
O que saber:- An authentication requirements rule enforces that the user authenticated with a sufficient method or context.
- It compares the authentication context reference values returned by the token provider against a required list.
- This is how step-up authentication is enforced: a sensitive resource requires a stronger ACR than the session currently holds.
- If the requirement is not met, PingAccess triggers re-authentication rather than simply denying.
- The values must match what the token provider actually issues, which is a coordination point between the two systems.
PAAA-001.1.11 Create a Groovy script rule
O que saber:- A Groovy script rule evaluates custom logic against the request, the identity, and the session.
- It is the escape hatch for policy that the built-in rules cannot express.
- Scripts must return a policy decision; the available objects and methods are defined by the PingAccess scripting API.
- Scripts run on every matching request, so they are a performance and reliability risk if written carelessly.
- Treat scripts as code: review them, version them, and test them before deployment.
PAAA-001.1.12 Create an HTTP request header rule
O que saber:- An HTTP request header rule matches on the presence or value of a named request header.
- Matching can be exact or by pattern, and can be negated.
- Headers are client-controlled, so a header rule is a routing or convenience control, not a security boundary on its own.
- Common uses: differentiating clients, enforcing a required header on API traffic.
- Combine with an authenticated identity check when the decision has security consequences.
PAAA-001.1.13 Create an HTTP request parameter rule
O que saber:- An HTTP request parameter rule matches on query string or form parameters.
- Like header rules, the value is client-supplied and must not be the sole basis for an access decision.
- Useful for routing and for enforcing that required parameters are present.
- Be explicit about whether the rule inspects the query string, the body, or both.
- Body inspection has performance implications on large requests.
PAAA-001.1.14 Create a network range rule
O que saber:- A network range rule permits or denies based on the client IP address in CIDR form.
- Source address is taken from the connection or from a forwarded header, depending on configuration; this distinction matters behind a load balancer.
- If forwarded headers are trusted, they must be stripped and re-set by a trusted upstream or the control is spoofable.
- Typical uses: restricting administrative paths to corporate ranges.
- IPv6 ranges must be handled explicitly, not assumed.
PAAA-001.1.15 Create an OAuth attribute rule
O que saber:- An OAuth attribute rule evaluates a claim from the access token against an expected value.
- It applies to API applications where the bearer token carries the authorization context.
- The claim must be present in the token the provider issues; coordinate the token contract with PingFederate.
- This is finer-grained than scope checking, since it can test arbitrary claim values.
- Missing claims should fail closed; verify the behavior rather than assuming it.
PAAA-001.1.16 Create an OAuth Groovy script (for API) rule
O que saber:- An OAuth Groovy script rule applies custom logic to API requests with access-token context available.
- Use when scope and attribute rules cannot express the required condition, such as relational checks between claims and the request path.
- The same performance and code-review cautions as the web Groovy rule apply.
- Return values must conform to the policy decision contract.
- Log enough from the script to make denials explainable in production.
PAAA-001.1.17 Create an OAuth scope rule
O que saber:- An OAuth scope rule requires the access token to carry one or more named scopes.
- Scope is the coarse-grained API authorization mechanism and should reflect the operation being protected.
- Requiring multiple scopes means all must be present unless configured otherwise.
- Scopes are defined at the token provider; PingAccess only checks them.
- This is the first rule to reach for on an API resource, before more specific attribute rules.
PAAA-001.1.18 Create a one-time authorization rule
O que saber:- A one-time authorization rule permits a single use of a resource, after which the authorization is consumed.
- Typical uses: download links, confirmation endpoints, and other actions that must not be replayed.
- State must be shared across the cluster for the rule to work correctly behind a load balancer.
- Understand the expiry behavior as well as the single-use behavior.
- Test replay explicitly, since a rule that fails open here defeats its own purpose.
PAAA-001.1.19 Create a rate limiting rule
O que saber:- A rate limiting rule caps request volume per client over a time window.
- Identify the client by IP, by OAuth client, or by authenticated identity depending on what the limit should protect.
- The counter must be cluster-aware, or each node enforces its own limit and the effective ceiling multiplies.
- Rate limiting is a protection against abuse and accidental overload, not a substitute for authentication.
- Choose the response code and message deliberately; 429 with a retry hint is the well-behaved answer.
PAAA-001.1.20 Create a redirect rule
O que saber:- A redirect rule sends matching requests to another location instead of proxying them.
- Useful for retiring paths, moving applications, and enforcing canonical URLs.
- Specify whether the redirect is permanent or temporary, because caches and browsers act on that difference.
- Preserve query strings when the target expects them.
- Redirect loops are the common error; verify the target does not match the same rule.
PAAA-001.1.21 Create a rejection rule
O que saber:- A rejection rule denies matching requests outright.
- Pair it with a rejection handler to control what the user actually sees.
- Rejections should be logged with enough context to distinguish attack traffic from a misconfiguration.
- Placing a rejection rule early in a rule set avoids wasted evaluation.
- Denying by default and allowing explicitly is the safer construction where the resource is sensitive.
PAAA-001.1.22 Create a time range rule
O que saber:- A time range rule permits access only during defined hours.
- The server's time zone governs evaluation, which matters for distributed deployments.
- Typical uses: restricting administrative functions to business hours, or maintenance windows.
- Combine with a rejection handler that explains the restriction, or support tickets follow.
- Time-based rules are brittle across daylight-saving transitions; confirm the intended behavior.
PAAA-001.1.23 Create a web session attribute rule
O que saber:- A web session attribute rule evaluates an attribute stored in the user's web session.
- Attributes arrive from the token provider during authentication and are carried in the session.
- This is the web equivalent of the OAuth attribute rule for API traffic.
- The attribute must be included in the web session configuration to be available for evaluation.
- Use it for group membership and entitlement checks sourced from the identity provider.
PAAA-001.1.24 Create a web session scope rule
O que saber:- A web session scope rule checks that the session carries a required scope granted at authentication.
- Scopes reach the web session through the OIDC flow PingAccess ran against the token provider.
- The requested scopes must be configured on the web session, or they will never be present to check.
- This is coarse-grained entitlement for browser traffic, complementing the finer attribute rule.
- A denial here usually means the token provider did not grant the scope, so debug at the provider.
PAAA-001.1.25 Create a WebSocket handshake rule
O que saber:- A WebSocket handshake rule governs the HTTP upgrade request that starts a WebSocket connection.
- Policy is enforced at handshake time; frames after the upgrade are not individually evaluated.
- Check origin and authentication at the handshake, because it is the only opportunity.
- Backend sites must permit the upgrade for the connection to succeed end to end.
- Long-lived connections interact with session timeouts; understand what happens when the session expires mid-connection.
PAAA-001.1.26 Create a CORS rule
O que saber:- A CORS rule controls cross-origin browser access by managing the preflight response.
- Configure allowed origins, methods, headers, and whether credentials are permitted.
- Allowing all origins together with credentials is a well-known misconfiguration; the browser blocks it and it signals careless policy.
- The preflight is an OPTIONS request and must be permitted to reach the rule.
- CORS is a browser-enforced control, so it protects users, not the server.
PAAA-001.1.27 Create an OAuth token cache time to live rule
O que saber:- The OAuth token cache time-to-live rule controls how long PingAccess caches token introspection results.
- Caching reduces load on the token provider at the cost of delayed revocation awareness.
- A short TTL means faster revocation propagation; a long TTL means better performance.
- The correct value is a security and capacity trade that should be stated explicitly in the design.
- This applies to reference tokens requiring introspection; self-contained JWTs are validated locally instead.
PAAA-001.1.28 Create a rewrite content rule
O que saber:- A rewrite content rule modifies the response body, typically to correct absolute URLs pointing at internal hostnames.
- It applies to text content types; binary responses are not rewritten.
- Body rewriting requires buffering, which costs memory and latency on large responses.
- Prefer fixing the application to emit relative URLs; rewriting is the compensating control.
- Scope the rule narrowly by content type and path to limit the performance cost.
PAAA-001.1.29 Create a rewrite cookie domain rule
O que saber:- A rewrite cookie domain rule changes the Domain attribute on Set-Cookie headers from the backend.
- Needed when the backend sets cookies for an internal domain that the browser will reject at the external hostname.
- Getting this wrong causes silent session loss, since the browser simply discards the cookie.
- Verify with the browser's cookie inspector rather than by reading the response header alone.
- Consider whether the cookie should be narrowed rather than broadened, for security.
PAAA-001.1.30 Create a rewrite cookie path rule
O que saber:- A rewrite cookie path rule adjusts the Path attribute on cookies returned by the backend.
- Required when PingAccess presents the application at a different context root than the backend uses.
- A mismatched path means the browser will not send the cookie back on subsequent requests.
- Pair with URL rewriting so path handling is consistent in both directions.
- Test the full login and navigation cycle, since the symptom appears only after a redirect.
PAAA-001.1.31 Create a rewrite response header rule
O que saber:- A rewrite response header rule modifies or removes headers in the response.
- Common uses: fixing Location headers that leak internal hostnames, and stripping headers that disclose backend software versions.
- Security headers can also be added here when the backend does not set them.
- Rewriting Location is essential for redirects to work through the proxy.
- Removing headers is as important as adding them; verbose backend headers are an information-disclosure finding.
PAAA-001.1.32 Create a rewrite URL rule
O que saber:- A rewrite URL rule translates between the externally-visible path and the path the backend expects.
- This is what lets PingAccess publish an application at a different context root than it is deployed under.
- Rewrites apply to the request path; response content and headers need their own rules to stay consistent.
- Regular-expression rewrites must be anchored carefully to avoid unintended matches.
- Document the mapping, because troubleshooting a rewritten path without it is guesswork.
PAAA-001.1.33 Create rule sets and rule set groups
O que saber:- A rule set groups rules; a rule set group composes rule sets, so policy can be reused across applications.
- Success criteria decide whether all rules must pass or any one is sufficient.
- Evaluation order within a set is significant when rules have side effects such as rewriting.
- Reuse is the point: define once, attach to many applications and resources.
- Deeply nested groups become hard to reason about; keep the hierarchy shallow enough to explain.
PAAA-001.1.34 Configure a header identity mapping
O que saber:- A header identity mapping injects identity attributes into request headers sent to the backend.
- Map each attribute explicitly to a header name the application already expects.
- The backend must reject these headers from any source other than PingAccess, or an attacker can impersonate a user by setting them directly.
- Consider whether values need encoding for non-ASCII content.
- This is the classic mechanism for putting a modern identity layer in front of a legacy application.
PAAA-001.1.35 Configure a JWT identity mapping
O que saber:- A JWT identity mapping passes identity to the backend as a signed JSON Web Token instead of plain headers.
- Signing lets the backend verify that PingAccess produced the token, which headers cannot provide.
- Configure the signing key, algorithm, audience, and lifetime; the backend validates all of them.
- The backend needs the corresponding public key, typically via a JWKS endpoint.
- Prefer JWT over header mapping where the backend can validate it, because it removes the spoofing exposure.
PAAA-001.1.36 Configure a basic authentication site authenticator
O que saber:- A basic authentication site authenticator sends a fixed username and password to the backend on every request.
- It authenticates PingAccess as a service, not the end user.
- Credentials are configuration secrets and should be rotated on a schedule.
- The backend sees one identity for all traffic, so per-user attribution must come from an identity mapping.
- Use TLS to the backend; basic authentication over plaintext exposes the credential on every request.
PAAA-001.1.37 Configure token mediator site authenticator
O que saber:- The token mediator site authenticator exchanges the user's session for a token the backend accepts.
- It bridges a PingAccess web session to a backend expecting an OAuth token or a PingFederate-issued token.
- This preserves end-user identity to the backend rather than collapsing everyone into one service account.
- Configuration coordinates with the token provider on client credentials and the token type expected.
- Token lifetime and refresh behavior need to be understood so long sessions do not fail mid-use.
PAAA-001.1.38 Configure redirects
O que saber:- Redirect configuration covers both listener-level redirects (HTTP to HTTPS) and rule-based redirects for specific paths.
- Know which mechanism is appropriate: infrastructure redirects belong on the listener, policy redirects belong in rules.
- Preserve the original path and query unless deliberately discarding them.
- Use permanent redirects only when the move truly is permanent, because clients and caches remember them.
- Verify the resulting URL is externally resolvable, not an internal hostname.
PAAA-001.1.39 Configure rejection handlers & rules
O que saber:- Rejection handlers control the response a user sees when a rule denies access.
- Options include a templated error page and a redirect to a friendly location.
- The handler should not leak why access was denied, since that informs an attacker.
- Attach handlers deliberately: a default technical error page is a poor user experience and a small information leak.
- Log the detailed reason server-side even when the user-facing message is generic.
PAAA-001.1.40 Configure server-side cipher ordering
O que saber:- Server-side cipher ordering makes PingAccess choose the cipher suite by its own preference rather than the client's.
- This lets you prefer stronger suites and forward secrecy regardless of client ordering.
- It is configured on the engine listeners along with the enabled protocol versions.
- Pair it with a curated cipher list; ordering alone does not remove weak suites.
- Verify with an external scanner after the change rather than trusting the configuration screen.
PAAA-001.1.41 Configure global unprotected resources
O que saber:- Global unprotected resources are paths PingAccess passes through without applying policy, across all applications.
- Typical uses: health checks and well-known endpoints that must be reachable unauthenticated.
- Every unprotected path is a permanent hole, so the list should be short and reviewed.
- Match patterns precisely; a broad pattern can unprotect more than intended.
- Distinguish from anonymous resources, which are still processed by PingAccess.
PAAA-001.1.42 Configure anonymous resources
O que saber:- An anonymous resource is processed by PingAccess but requires no authenticated identity.
- Rules still apply, so network range or rate limiting can protect it.
- Identity mappings have nothing to inject, which the backend must tolerate.
- Use for public pages within an otherwise protected application.
- This is the middle ground between fully protected and entirely unprotected.
PAAA-001.1.43 Configure application unprotected resources
O que saber:- Application unprotected resources bypass policy for specific paths within one application only.
- Narrower and safer than the global list, since the exception is scoped to where it is needed.
- Common uses: static assets, login callbacks, and application-specific health endpoints.
- Confirm the path pattern cannot be manipulated to reach protected content underneath it.
- Review these when the application changes, because stale exceptions accumulate.
PAAA-001.1.44 Configure manual resource ordering
O que saber:- Resource ordering determines which resource definition matches a request when patterns overlap.
- By default matching is by specificity; manual ordering overrides that when the default is wrong.
- Only the first matching resource applies, so ordering directly determines effective policy.
- Manual ordering should be documented, because it is invisible to anyone reading the resources alone.
- Test overlapping paths explicitly after any ordering change.
PAAA-001.1.45 Configure token validation
O que saber:- Token validation decides how PingAccess verifies an incoming access token.
- Reference tokens require introspection at the token provider; JWTs can be validated locally against a signing key.
- Local validation must check signature, issuer, audience, and expiry, not merely that the token parses.
- Introspection gives immediate revocation awareness; local validation gives speed. Caching sits between them.
- Misconfigured audience checking is a common finding, since it allows a token issued for another service to be accepted.
Objective 2: Agent Deployment
PAAA-001.2.01 Create an agent in the admin console
O que saber:- An agent is a plugin in the web server itself rather than a proxy hop; the admin console defines it and issues its credentials.
- Agent deployments keep traffic on the existing web server while policy decisions come from PingAccess.
- The agent name and shared secret from the console are what the agent.properties file carries.
- Choose agent versus gateway based on network topology and whether you can install into the web server.
- Agents cannot perform response rewriting the way a gateway can, which is a real functional difference.
PAAA-001.2.02 Configure an agent using an agent.properties configuration file for Apache
O que saber:- agent.properties contains the PingAccess host, port, shared secret, and the agent's identity.
- For Apache, the module is loaded in the server configuration and pointed at the properties file.
- The file contains a secret and must be protected by filesystem permissions.
- Regenerating the agent in the console invalidates the old properties file; deployment must be coordinated.
- Verify with a request through the web server, then check that the agent appears connected in the console.
Objective 3: Clustering
PAAA-001.3.01 Add a replica administrative node to an existing cluster
O que saber:- A replica administrative node provides a standby for the admin console, which is otherwise a single point of failure for configuration changes.
- The replica receives configuration but does not accept changes until it is promoted.
- Promotion is a deliberate operation, not automatic failover.
- Engines continue serving traffic while the admin node is unavailable, so this protects manageability rather than availability.
- Configure and test promotion before you need it, because the procedure under pressure is where mistakes happen.
PAAA-001.3.02 Configure runtime state clustering
O que saber:- Runtime state clustering shares session and rule state across engine nodes.
- Without it, state-dependent features such as one-time authorization and accurate rate limiting behave per node.
- Configuration designates state servers and the engines that use them.
- Network reachability and latency between engines and state servers directly affect request latency.
- Understand the failure behavior when a state server is unreachable.
PAAA-001.3.03 Configure sticky sessions
O que saber:- Sticky sessions pin a client to the same engine node at the upstream load balancer.
- They compensate for state that is not shared, and reduce cross-node lookups when it is.
- The load balancer implements stickiness; PingAccess relies on it.
- Stickiness complicates draining a node for maintenance, so plan the drain procedure.
- Prefer shared state over stickiness where both are options, because stickiness degrades badly under node loss.
PAAA-001.3.04 Configure admin console single sign-on (SSO)
O que saber:- Admin console SSO delegates administrator authentication to the token provider rather than local accounts.
- Configure the OIDC client and map claims to PingAccess administrative roles.
- This brings admin access under the same MFA and lifecycle controls as the rest of the organization.
- Retain a documented break-glass local account and protect it, or an identity outage locks you out of the console.
- Test role mapping with a non-privileged account before enforcing.
PAAA-001.3.05 Configure an on-prem cluster
O que saber:- An on-premise cluster comprises an administrative node, optional replica, and engine nodes.
- Engines receive configuration from the admin node and serve traffic independently.
- Cluster configuration includes shared keys and the engine listener definitions.
- Time synchronization across nodes matters for token validation and logging correlation.
- Verify each engine independently after a configuration change, since a node can silently fail to pull config.
Objective 4: Troubleshooting
PAAA-001.4.01 Configure logging
O que saber:- Logging configuration uses log4j2; levels and appenders are set in the configuration file.
- Key logs: the audit logs for policy decisions and the engine log for runtime behavior.
- Raising log level in production is a deliberate, temporary act with a plan to revert.
- Log rotation and retention must be configured or disks fill during an incident.
- Structured output makes downstream aggregation practical; decide the format before shipping logs elsewhere.
PAAA-001.4.02 Configure resource auditing
O que saber:- Resource auditing records access to protected resources, producing the evidence trail for compliance.
- Audit logs capture identity, resource, decision, and time.
- Auditing can be enabled per application or resource, so it can be targeted at sensitive areas.
- Audit volume affects performance and storage; scope it deliberately.
- Ship audit logs off the host, since local logs are lost with the host.
PAAA-001.4.03 Troubleshoot common issues
O que saber:- Work the request path in order: virtual host match, application and resource match, rules, identity mapping, then the backend site.
- A 404 through PingAccess usually means the virtual host or context root did not match what you expected.
- Authentication loops usually mean cookie domain or path problems, or an audience mismatch on the web session.
- Backend 401 or 403 with a successful PingAccess policy decision points at the site authenticator or identity mapping.
- Correlate the audit log entry with the engine log using the same timestamp and transaction identifiers before changing anything.
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 →