← All study guides
PAAA-001
Certified Expert - PingAccess
Part of 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.
Independent study aid built from the public exam blueprint. Not affiliated with, authorized by, or endorsed by ping. Objectives are transcribed and mapped by hand, so this page may contain mistakes or may have fallen behind the vendor's current material: exam objectives, versions, numbering and availability all change without notice. Treat ping's own certification portal as the source of truth and verify against it before you book anything.
Objective 1: Advanced Configuration
PAAA-001.1.01 Create a Web+API application object in the admin console
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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)
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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
What to know:- 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.
Public sources, used in good faith
These guides are independent study aids built from publicly available material: published exam blueprints, official product documentation, and vendor training catalogues. Product names, exam codes, and trademarks belong to their owners and are used only to identify the subject being taught. This site is not affiliated with or endorsed by any vendor named here. If you hold rights in material published on this page and believe it should be removed or corrected, please send the exact URL and a short note on the issue through the contact page; requests are reviewed promptly and in good faith. Read the full disclaimer →