Free Practice Questions for Ping Identity PT-AM-CPE Exam

In a Cross-Domain Single Sign-On (CDSSO) environment, PingAM must manage session cookies across multiple distinct DNS domains.2 By default, a standard SSO token could potentially be stolen and reused by a malicious actor to gain access to other domains within the same realm.3 To mitigate this specific threat, PingAM 8.0.2 utilizes Restricted Tokens.4

According to the documentation on "Securing CDSSO session cookies," a restricted token is a unique SSO token issued for each specific application or policy agent after successful user authentication.5When CDSSO is active with cookie hijacking protection enabled, PingAM issues a "master" SSO token for the domain where AM resides and separaterestricted tokensfor the other fully qualified domain names (FQDNs) where web or Java agents are located.6

The restricted token is "restricted" because it is inextricably linked to the specific agent and application that initiated the redirection. Internally, AM stores a correlation between the master session and these restricted tokens.7If an attacker attempts to hijack a restricted token and use it to access a different application or a different domain, the AM server performs a validation check on the constraint associated with the token (such as the agent's DN or IP). If the request does not originate from the authorized entity, a security violation is triggered, and access is denied. This mechanism ensures that even if a cookie is stolen in one domain, its utility is confined strictly to that domain and cannot be used for "lateral movement" across the enterprise’s other protected resources. It is important to note that restricted tokens requireserver-side sessionsto function; they are not supported for client-side (JWT-based) sessions.8

While OpenID Connect (OIDC) is built on top of OAuth2, it introduces specific endpoints for handling ID Tokens (the identity layer). In PingAM 8.0.2, when a client receives an ID Token, it is recommended to validate it locally using the provider's public keys. However, PingAM also provides a convenience endpoint for validation.

According to the "OpenID Connect 1.0 Endpoints" documentation:

/oauth2/idtokeninfo (Option A): This is the dedicated endpoint designed to receive an ID Token as a parameter.8It validates the token's signature, checks the expiration and audience, and returns the claims contained within the token in a JSON format. This is specifically used forunencryptedID tokens.

/oauth2/userinfo (Option B): This endpoint returns claims about the authenticated user but requires a validAccess Tokenin the authorization header, not an ID Token.9

/oauth2/introspect (Option C): This is a standard OAuth2 endpoint (RFC 7662) used to check the metadata and "activeness" ofAccess TokensorRefresh Tokens, not the internal identity claims of an OIDC ID Token.10

/oauth2/tokeninfo (Option D): This is a legacy/non-standard endpoint that was used in older versions for Access Token validation and is not the primary OIDC validation endpoint in version 8.0.2.11

Therefore, for the specific task of validating an ID Token and retrieving its claims,/oauth2/idtokeninfois the correct and authoritative endpoint in the PingAM 8.0.2 OIDC implementation.

In PingAM 8.0.2, especially when utilizing File-Based Configuration (FBC), the startup sequence relies on a "bootstrap" phase to locate the system's configuration. According to the "Installation Guide" and "Configuration Directory Structure," the primary file involved in this process is named boot.json.

The boot.json file contains the essential connection details required for the AM binaries to find and unlock the configuration store (usually PingDS). This includes the LDAP host, port, bind DN, and references to the secret stores needed to decrypt the configuration.

The location of this file is determined by theConfiguration Directorypath specified during the initial setup. By default, PingAM creates its configuration directory in the home directory of the user running the web container. The standard path structure is //. Therefore, the boot.json file is located at the root of this instance directory:<user-home>/<am-instance-dir>/boot.json.

Options A and Dare incorrect because they place the file inside a /config subdirectory; while AM has many config files in subdirectories, the boot.json sits at the root to be accessible as the first point of entry.

Option Bis incorrect because it suggests the file is stored within the Tomcat webapps folder. PingAM specifically avoids storing configuration data within the web application binaries to ensure that configuration persists even if the .war file is deleted or redeployed.

Understanding the location of boot.json is vital for DevOps engineers who need to automate the deployment of PingAM using tools like Amster or when troubleshooting a "Failed to connect to the configuration store" error during server startup.

In PingAM 8.0.2, the Intelligent Access framework categorizes authentication nodes based on their primary function. While nodes like the Device Profile Collector (A) and Device Profile Save (C) are essential for the device context workflow, they are considered "Utility" or "Data Collection/Persistence" nodes. They do not perform analysis or branching logic based on risk scores or comparisons themselves; they simply gather metadata or write it to the user's profile.

According to the "Authentication Node Reference,"Risk Analysisrelated to device context is performed by nodes that compare real-time data against a baseline or a set of rules. These nodes include:

Device Geofencing node (B): Analyzes the current device's location against a set of predefined "trusted" coordinates to determine if the user is within a permitted geographical area.5

Device Tampering Verification node (D): Assesses the integrity of the device (typically for mobile) to detect if it has been rooted, jailbroken, or otherwise compromised.6

Device Location Match node (E): Compares the current device's location with the user's historical location data stored in their profile to identify anomalies.7

Device Match node (F): Evaluates the current device's hardware and software signatures against a list of "trusted devices" previously registered by the user.8

Nodes B, D, E, and F all provide branching outcomes (e.g., True/False, Inside/Outside, Success/Failure) based on a risk evaluation of the device context. This makesOption Bthe correct selection. Understanding the distinction between a "Collector" and an "Evaluator" is vital for designing effective authentication journeys that can trigger step-up authentication or deny access when device-based risk signals are detected.

Proof of Possession (PoP) tokens, specifically Certificate-Bound Access Tokens as defined in RFC 8705 and supported by PingAM 8.0.2, are designed to prevent token misuse by binding the access token to a specific client's cryptographic material.9

According to the PingAM documentation on "Certificate-Bound Proof-of-Possession," when an OAuth2 client requests a token, PingAM retrieves the client's public key (either from a provided certificate or a JWK) and embeds a thumbprint (the cnf claim) of that material into the issued token. When the client subsequently presents this token to the Resource Server (or the Authorization Server's introspection endpoint), it must also provide "Proof" that it possesses the private key corresponding to that thumbprint.

In theMutual TLS (mTLS)approach, this proof is provided by theClient private certificatepresented during the TLS handshake.10The server verifies that the certificate used to establish the secure connection matches the one bound to the token. Without presenting the certificate (Option D), the token is considered "unbound" or invalid, even if the token itself is otherwise well-formed. This mechanism effectively "pins" the token to the client, ensuring that if the token is stolen, it cannot be used by any other entity that does not possess the matching private key.NonceandState(Options A and C) are used during the initial authorization request for different security purposes (replay protection and CSRF), and while aJWK(Option B) can be used todefinethe public key, the actualpresentationof proof during an mTLS transaction is the certificate.

In the "Additional Cookie Security" section of the PingAM 8.0.2 documentation, HttpOnly is described as a critical security attribute for session cookies (like iPlanetDirectoryPro). Its primary purpose is to mitigate the risk of session hijacking via Cross-Site Scripting (XSS) attacks.

When a cookie is marked with the HttpOnly flag, the browser is instructed to restrict access to that cookie. Specifically, it preventsclient-side scripts—such as those written in JavaScript—from accessing the cookie through the document.cookie API. If an attacker successfully injects a malicious script into a page, the script will be unable to "read" the session token, even though the cookie is still automatically sent by the browser with every valid HTTP request to the server.

Option Bdescribes the Secure flag, which ensures cookies are only sent over encrypted (HTTPS) connections.

Option Cis incorrect because the servermustbe able to read the cookie to validate the user's session.

Option Dis a common misconception; the HttpOnly flag does not restrict the transport to "HTTP-only" (non-secure) protocols; rather, it restricts theaccess methodwithin the browser environment.

By default, PingAM 8.0.2 enables the HttpOnly flag for all session cookies. This is considered a best practice in modern identity management because it ensures that even if a web application has a vulnerability that allows for script injection, the user's primary authentication token remains protected from being exfiltrated by the attacker's script.

Mutual TLS (mTLS) is a security enhancement where both the client and the server provide X.509 certificates to prove their identities.9 In PingAM 8.0.2, mTLS is frequently used for secure "Machine-to-Machine" (M2M) communication, such as between an OAuth2 client and the token endpoint, or between AM and a Directory Server (PingDS).

According to the PingAM documentation on "Secure Network Communication" and "mTLS for OAuth2," the handshake sequence for mTLS follows these logical steps:

Client Hello: The client initiates the request to the server.10

Server Hello & Certificate: The server responds by presenting its own certificate (verifying the server's identity to the client).11In an mTLS scenario, the server also includes aCertificateRequestmessage.12

Client Certificate & Key Exchange: The client validates the server's certificate. If valid, the client then sends its ownClient Certificateto the server, along with the encrypted pre-master secret or key exchange data.

Verification and Establishment: The server validates the client's certificate against its truststore. If the certificate is trusted and the cryptographic signatures match, themutually secure connectionis established.

Option D represents the most accurate "simplified" sequence. Option A is incorrect because the server presents its certificatebeforethe client sends its own certificate. Option B and C are incorrect because the server always responds to the initial "Client Hello" with its own identity (Server Certificate) before the client proceeds with identity submission. This "handshake" ensures that no data is transmitted until both parties have cryptographically verified each other.

In PingAM 8.0.2, once a user successfully completes an authentication journey, the server issues a session token. For browser-based clients, this token is typically delivered via an HTTP cookie. The server-side property that defines the name of this specific cookie is com.iplanet.am.cookie.name.

According to the "Global Properties" and "System Configuration" documentation, this property is found under theSessionservice settings. By default, its value is set toiPlanetDirectoryPro(Option B). While iPlanetDirectoryPro is the defaultvalueof the cookie name, the question asks for thename of the propertyused to configure it.

Administrators often modify this property for security reasons to hide the fact that they are using PingAM or to avoid conflicts with other legacy systems. It is important to note that if this property is changed in the AM server, the corresponding configuration in allPolicy Agents(Web or Java Agents) must also be updated to look for the new cookie name, otherwise, the agents will not be able to find the user's session and will redirect them to login repeatedly. Option D refers to an agent-side configuration key, but the central "Source of Truth" for the session cookie name within the AM platform is the server-side property com.iplanet.am.cookie.name.

PingAM 8.0.2 supports various Multi-Factor Authentication (MFA) methods, each with different hardware and software requirements.7 The question asks specifically for methods that require both a separate device and a specific application.

Push Authentication: This requires a mobile device (separate from the computer used to log in) and theForgeRock/Ping Authenticator app(or a custom app using the SDK) to receive and approve the notification.8

Open Authentication (OATH): This refers toTOTP(Time-based One-Time Password). It requires a separate device (smartphone or hardware token) and an application (like ForgeRock Authenticator, Google Authenticator, or Authy) to generate the 6-digit rotating codes.

Why WebAuthn is excluded: WhileWebAuthn(Option A, B, and C) can use separate devices (like a YubiKey or a secondary phone), it is specifically designed to worknatively with the browser and the operating system(using the FIDO2 standard). It doesnotrequire a specific "Authenticator Application" to be installed by the user; instead, it uses the platform's built-in authenticators (like TouchID, FaceID, or Windows Hello) or a hardware key handled directly by the browser's WebAuthn API.

Therefore, the two methods that strictly fit the "Separate Device + App" criteria in the PingAM ecosystem areOpen Authentication and Push, making Option D the correct answer.

In PingAM 8.0.2, the management of cryptographic material has evolved toward the Secret Store framework, which allows secrets to be stored in various locations (Filesystem, HSM, or Environment Variables). However, for specific core features, the internal PingAM keystore (historically keystore.jks) remains the primary repository for the keys used to protect session integrity.

According to the "Client-side Session Security" documentation, when a realm is configured forClient-side sessions, the entire state of the user's session is encapsulated within a signed and encrypted JSON Web Token (JWT). This JWT is then stored in the user's browser cookie. To ensure that this token cannot be tampered with or read by unauthorized parties, PingAM must sign and encrypt the payload. The AM engine is hardcoded to look for the specific aliases (such as am.services.session.encryption and am.services.session.signing) within thedefault-keystoresecret store, which points directly to the PingAM keystore.

While other features likeOAuth2 providers(Option D) and thePersistent Cookie node(Option B) utilize secret stores, they are designed to be highly flexible and can be configured to use keys from any defined secret store in the realm.Authentication trees(Option C) are logical constructs and do not "use" the keystore directly, although individual nodes within a tree might. The distinction forClient-side sessionsis that the feature's fundamental security model is built specifically around the cryptographic keys managed within the AM keystore to provide "stateless" session management. Administrators must ensure that the same keystore and aliases are shared across all nodes in a cluster to allow any AM instance to validate a client-side session token issued by another node.