PT-AM-CPE Practice Questions

Affinity mode, also known as session stickiness, is a load balancing strategy. When PingAM is deployed in a cluster behind a load balancer, affinity mode ensures that all requests from a user within the same session are directed to the same PingAM server node. This is critical for maintaining session state, especially for client-side sessions, as the session information is not replicated across all nodes in the cluster. Without affinity, a user's request might be sent to a server that has no knowledge of their session, causing authentication to fail.

A. Authentication: Affinity mode supports the session after authentication has occurred; it is not part of the authentication mechanism itself.

C. Self-service: Self-service processes rely on a valid session, but affinity is a broader infrastructure concept for managing that session across a cluster.

D. Authorization: Authorization decisions depend on a valid session, but affinity mode's purpose is to maintain the session's integrity at the load balancer level.

1. Ping Identity, ForgeRock AM 7 Documentation, Setup and Maintenance Guide, Chapter 3: Configuring Sites and Clusters, Section: "To Configure a Site". The documentation specifies, "When AM is deployed in a site configuration, a load balancer must be configured to provide session affinity (or stickiness)."

2. Ping Identity, ForgeRock AM 7 Documentation, Deployment Guide, Chapter 2: Planning the Deployment, Section: "Load Balancers". This section details the requirement for session stickiness for traffic to AM servers.

Access management policies, such as those in PingAccess, operate at the HTTP layer to protect web applications and APIs. Policies are defined using rules that inspect attributes of the HTTP request, including the HTTP method (or verb). HEAD is a standard HTTP method, alongside GET, POST, PUT, and DELETE. Therefore, a policy can be configured by default to allow or deny requests based on whether the method is HEAD. The other options are not standard HTTP methods.

B. INSERT: This is a database (SQL) command, not a standard HTTP method.

C. CREATE: This is a CRUD operation concept, typically implemented using the HTTP POST method, but it is not an HTTP method itself.

D. UPDATE: This is a CRUD operation concept, typically implemented using HTTP PUT or PATCH methods, but it is not an HTTP method itself.

1. PingAccess 7.3 Documentation, "Managing Rules", section "Add an HTTP Request Rule". The documentation for the "HTTP Method Rule Type" lists the standard HTTP methods that can be specified in a policy, including GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH, and TRACE.

2. MDN Web Docs, "HTTP request methods". This resource, maintained by Mozilla, is a standard reference for web technologies and lists HEAD as a primary HTTP request method. While not a Ping Identity source, it defines the standard upon which PingAccess operates.

For edge-initiated step-up or transactional authorization, the client must indicate which higher authentication context to invoke by supplying the query parameters authIndexType (typically set to service or module) and authIndexValue (the name of that service/module). No other parameters are mandatory.

B – “service” is not a separate parameter; it is the value of authIndexType.

C – ForceAuth is optional; only authIndexType/value are required.

D – Lacks the mandatory authIndexValue and misuses “service”.

1. ForgeRock Access Management 7.3 Authentication & SSO Guide, §6.6.4 “Requesting Step-Up Authentication” (authIndexType & authIndexValue required).

2. ForgeRock Identity Gateway 7.2 User Guide, §“Step-Up Authentication with AM” (lists mandatory parameters).

In PingAM's OAuth 2.0 scripting, the requestedToken object represents the token that is being created and will be issued. The addMayAct(mayAct) method is the specific API call available on this object to insert the mayact claim, which is used for delegation in token exchange scenarios as defined by RFC 8693. The mayAct variable passed to the method must be a JSON object containing the claims for the party that is authorized to act on behalf of the subject.

A. var mayAct = ... token.addMayAct(mayAct): The token object typically represents the incoming or original token, not the new token being issued, making this the incorrect object to modify.

C. var mayAct = ... requestedToken.setMayAct(mayAct): The correct method name in the PingAM scripting API is addMayAct, not setMayAct.

D. var mayAct = ... token.setMayAct(mayAct): This uses both the incorrect object (token) and an incorrect method name (setMayAct).

PingAM Documentation, "Scripts Guide" -> "Scripting API" -> "RequestedToken (Scripting API)". The API documentation lists addMayAct(Object mayAct) as a method on the RequestedToken object, used to "Add the mayact claim to the token." This object is explicitly used in OAuth 2.0 access token modification scripts.

The error "user requires profile to login" occurs when PingAM is configured in a mode where it does not manage user profiles within its own data store, but an authentication journey attempts an action that requires one. This happens when the realm's "User Profile" setting is "Ignored". In this mode, AM expects the identity repository (e.g., an external LDAP) to be the sole source of truth. If a node in the authentication tree (e.g., "Data Store Decision" or "Attribute Collector") tries to read from or write to a local AM profile that doesn't exist, this specific error is triggered.

A. Policy misconfiguration would typically result in an authorization failure or "Access Denied" message, not a profile-specific error during login.

C. If a user has not filled in required profile information, the journey would typically direct them to a profile completion page or fail with a different message.

D. Incorrect credentials would result in a clear "Authentication Failed" or "Invalid username or password" error message.

1. Ping Identity Access Management Documentation, "Realms > To Create a Realm". In the "Identity Store" section, the "User Profile" property is described. Setting this to "Ignored" can lead to the specified error if authentication journeys are not designed accordingly.

2. Ping Identity Access Management Documentation, "Troubleshooting > Authentication". This section details common authentication errors. The error "user requires profile to login" is explicitly linked to the realm's user profile configuration being set to "Ignored" while a journey requires a profile write.

The Core Token Service (CTS) is a foundational component in PingAM designed for high-availability storage of security tokens and session data. Its primary function is to persist OAuth 2.0 tokens (access, refresh), OpenID Connect tokens, and user session tokens in a centralized data store, typically PingDirectory. This enables token validation, introspection, and revocation across a distributed PingAM cluster, ensuring state consistency and supporting stateless clients.

A. Configuration data for PingAM services, realms, and policies is stored in a dedicated configuration store, not the CTS.

B. User profiles and identity data are managed in a user data store, which is distinct from the CTS token store.

C. While Kerberos is an authentication mechanism, the CTS is not designed for storing Kerberos service tickets; its focus is on session and OAuth2/OIDC tokens.

1. Ping Identity, PingAM 7.3 Documentation, "Core Token Service (CTS)," Section: "About the CTS". (Describes CTS storing sessions and OAuth 2.0/OIDC tokens).

2. Ping Identity, PingAM 7.3 Documentation, "OAuth 2.0 Guide," Chapter: "Configuring OAuth 2.0," Section: "Configuring the CTS for OAuth 2.0 Tokens". (Details the requirement of CTS for persisting OAuth 2.0 tokens).

To initiate a service provider (SP)-initiated single sign-on, the request must be sent to the SP's SSO endpoint in PingAM, which is spSSOInit.jsp. To redirect the user to a specific application (myapp.com) after successful authentication, the RelayState parameter must be used. The RelayState parameter is part of the SAML 2.0 specification and is used to preserve and convey state information from the SP to the Identity Provider (IdP) and back. In this context, it carries the ultimate destination URL where the user should be sent post-authentication.

A. idpSSOInit.jsp is used for IdP-initiated SSO, not SP-initiated SSO, which is what the question specifies.

B. This option incorrectly uses idpSSOInit.jsp for an SP-initiated flow and the non-standard goto parameter instead of RelayState.

C. While spSSOInit.jsp is correct for SP-initiated SSO, the goto parameter is not the standard SAML parameter for the final redirect URL; RelayState is.

1. Ping Identity, Access Management 7.5 Documentation, "SAML v2.0 Guide > Implementing SAML v2.0 > Initiating Single Sign-On". The guide details the different SSO initiation endpoints, specifying spSSOInit.jsp for SP-initiated flows.

2. OASIS, "Security Assertion Markup Language (SAML) V2.0 Core Specification", March 2005. Document identifier sstc-saml-core-2.0-os. Section 3.4.1, "AuthnRequest Protocol", describes the use of the RelayState parameter to include "private correspondence" that is returned unmodified to the requester. This is the standard mechanism for passing the target URL.

The OAuth 2.0 Token Exchange impersonation pattern allows a client (the "actor") to obtain a token to access a downstream service while acting on behalf of a user (the "subject"). Therefore, the client's goal is to act as the subject on another service (A). The token exchange request itself, as defined in RFC 8693, involves the client presenting a subjecttoken (representing the user) and typically an actortoken (representing the client itself) to clearly define the impersonation context (D).

B. A subject acting on behalf of another subject describes a delegation pattern, which is a different use case from impersonation.

C. The request must identify both the subject being impersonated and the actor doing the impersonating; a subjecttoken alone is insufficient.

1. Internet Engineering Task Force (IETF), RFC 8693, "OAuth 2.0 Token Exchange," Section 1, "Introduction." This section describes the impersonation use case where a service acts on behalf of a user.

2. Internet Engineering Task Force (IETF), RFC 8693, "OAuth 2.0 Token Exchange," Section 2.1, "Request." This section defines the subjecttoken and actortoken parameters used in the exchange to represent the subject and the acting party, respectively.

3. Ping Identity, PingAM Documentation, "OAuth 2.0 Guide," Chapter: "OAuth 2.0 Token Exchange," Section: "Impersonation." This section details PingAM's implementation of the impersonation grant type, aligning with RFC 8693.

For Proof of Possession (PoP) using mutual TLS (mTLS), as defined in RFC 8705, the client must authenticate itself to the authorization server using its X.509 certificate. During the TLS handshake, the client presents its certificate, and the authorization server can then bind the issued access token to that specific client certificate. This ensures that only the client in possession of the corresponding private key can use the token, preventing it from being used as a simple bearer token if stolen.

A. Nonce: A nonce is a cryptographic value used to prevent replay attacks, but it is not the primary credential for PoP in this context.

B. Client JSON Web Key (JWK): While a JWK can be used in other PoP mechanisms (e.g., DPoP), for mTLS, the standard X.509 client certificate is the required credential.

C. State: The state parameter is used during the authorization code flow to mitigate Cross-Site Request Forgery (CSRF) and is not related to PoP token presentation.

1. Ping Identity AM Documentation, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens". This section explains that for mTLS, the client authenticates with a certificate during the TLS handshake when requesting a token.

2. Internet Engineering Task Force (IETF), RFC 8705, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", Section 2.1 "Mutual-TLS for Client Authentication". This section specifies that the client authenticates by presenting its X.509 certificate.

Ping products (e.g., PingFederate, PingAccess) write debug entries in the same Log4j-based format.

Each record begins with a timestamp header, then the Java thread ID, the originating component (logger name), the configured log level, and the human-readable message. When an exception occurs, a full Java stack trace is appended. Option A lists every one of those mandatory and optional parts; the other options each omit at least one required element.

B – Omits the running thread ID, which is always written.

C – Omits the debug level.

D – Omits the component/logger name.

1. PingFederate 11.3 Administrative Guide, “Server logging,” §3.4.1, p. 135–136 – describes timestamp, thread, logger, level, message, stack trace.

2. PingAccess 9.2 Admin Guide, “Understanding log files,” p. 47 – identical field list for DEBUG output.

3. Apache Log4j 2 Manual, “Layout,” §PatternLayout – corroborates required fields for Ping’s default pattern.