PAP-001 Practice Questions

In PingAccess, enforcing step-up authentication for a specific resource is achieved using an Authentication Requirements Rule. This rule type is designed to inspect the user's session context, which is typically provided by PingFederate in a web session token. The rule verifies if the session meets a pre-defined minimum authentication level or context.

If users are not being prompted for step-up, the issue lies either with the application of the rule or its configuration. The administrator must first verify that an Authentication Requirements Rule is correctly applied to the financial application's URL (B). Second, they must ensure the rule itself is configured with the appropriate minimum authentication level required for the sensitive money transfer operation (C).

A. A rejection handler executes after a rule fails to define the denial action; it does not perform the primary check for the authentication context.

D. Identity mappings are used to transform or add attributes for consumption by the backend application, not to enforce authentication policies on the resource.

E. Token validation confirms the integrity, issuer, and audience of the token itself, but it does not evaluate the business logic of whether the authentication level is sufficient for the resource.

1. PingAccess Administrator's Guide 7.3, Section: Authentication Requirements rule.

Page/Section: In the "Managing rules" chapter, the section "Authentication Requirements rule" states: "Use an Authentication Requirements rule to require that the user's session meets a minimum authentication level or contains a specific authentication context." This directly supports that this rule type is the correct mechanism (validating option B).

2. PingAccess Administrator's Guide 7.3, Section: Add an Authentication Requirements rule.

Page/Section: In the "Configuring rules" chapter, the section "Add an Authentication Requirements rule" details the configuration fields. It shows that the administrator must specify the "Authentication Requirement List" or "Authentication Requirement," which defines the minimum level the user's session must meet. This confirms the need to check the rule's internal configuration (validating option C).

In PingAccess, once the application context-root (/parts) is stripped, the remaining request path is /suspension/struts/manufacturer.

With default ordering, the policy engine chooses the “most specific” resource—i.e., the pattern with the greatest number of explicit path segments and the fewest wildcards.

Among the candidates:

• /suspension/struts/manufacturer contains four fixed segments and no wildcards.

• //struts/manufacturer and //manufacturer both contain multi-segment wildcards (//).

• ///manufacturer contains two wildcards.

Because /suspension/struts/manufacturer is the longest exact match and has zero wildcards, it outranks the others, so the policy engine selects it.

A. //struts/manufacturer – Matches, but wildcard (//) makes it less specific than the exact path; loses in default ordering.

B. //manufacturer – Wildcard plus only one fixed segment; lower specificity than both A and C.

D. ///manufacturer – Two consecutive wildcards; lowest specificity of all candidates.

1. Ping Identity. “PingAccess Administrator Guide 9.3,” Section “Resource Path Patterns → Evaluation Order,” pp. 220-223: “The resource with the greatest number of explicit path segments and the fewest wildcards is chosen.”

2. Ping Identity. “PingAccess 9.3 – Defining Resources,” Example table “/foo/bar vs //bar,” p. 225.

3. Ping Identity. “PingAccess 8.3 Administrator Guide,” Appendix A, “Wildcard Matching Rules,” p. 310 (rules for // multi-segment wildcard).

The "Global Unprotected Resources" feature in PingAccess is specifically designed to define URL patterns that should be accessible without requiring any authentication. This configuration is applied globally, meaning it affects all applications managed by PingAccess. This directly meets the requirement to make resources like style sheets, which are often common across multiple applications, publicly available to all users without an authentication challenge.

A. Define a Protocol Source for the resource.

This option is incorrect. A Protocol Source defines where PingAccess gets identity information (e.g., an OIDC Provider), which is part of the authentication process, not for bypassing it.

B. Define Authentication Challenge Policy of none for the resource.

This is incorrect in this context. While setting a policy to "none" can unprotect a resource, policies are typically applied at the application or virtual host level, not globally across all applications.

D. Define a Default Availability Profile of on-demand for the resource.

This is incorrect. An Availability Profile is used to configure health checks for backend sites to ensure they are online and available to serve requests, which is unrelated to authentication policy.

1. PingAccess 7.3 Administrator's Guide, Section: "Configuring Global Unprotected Resources".

Quote: "You can configure PingAccess to allow access to certain resources without authentication. These resources are considered unprotected and are available to all clients... Unprotected resources are defined globally and apply to all applications." (This directly supports answer C).

2. PingAccess 7.3 Administrator's Guide, Section: "Configuring Policies".

Reference: This section details how policies, including Authentication Challenge Policies, are applied to specific applications, virtual hosts, or resources within them, confirming that this is not a global setting. (This supports why B is less correct than C).

3. PingAccess 7.3 Administrator's Guide, Section: "Configuring Sites".

Reference: This section describes Availability Profiles as a component of a Site configuration, used for "determining the health of the servers associated with the site." (This supports why D is incorrect).

To prevent PingAccess from starting automatically on a Windows Server, the associated Windows Service must be removed. PingAccess provides a specific batch script for this purpose. The uninstall-service.bat command, located in the /bin directory, unregisters the PingAccess service from the Windows Service Control Manager. Once the service is removed, it can no longer be started automatically by the operating system during boot-up.

A. init.bat: This is not a standard script provided with PingAccess for managing the Windows service. Its function is not related to service installation or removal.

C. remove-install.bat: This is not a valid or documented PingAccess command. There is no such script included in the standard PingAccess distribution for service management.

D. wrapper-service.bat: While this script interacts with the Java Service Wrapper, it is not the primary command intended for administrators. The uninstall-service.bat script is the designated high-level utility that calls the wrapper with the correct parameters for service removal.

1. Ping Identity PingAccess 7.3 Documentation, "Start and stop PingAccess," section "Running PingAccess as a service on Windows."

This official guide explicitly states: "To remove the PingAccess service, run /bin/uninstall-service.bat." This confirms that uninstall-service.bat is the correct command to unregister the service, thereby preventing it from starting automatically.

According to Ping Identity’s official “PingAccess Release Notes – Supported browsers” table, only the latest versions of Google Chrome and Microsoft Edge (Chromium-based) are formally tested and supported for the PingAccess administrative console. Safari, Opera, and Brave are not included in the support matrix, so they are outside the vendor’s guaranteed compatibility scope.

A. Apple Safari – Absent from PingAccess supported-browser list; not vendor-tested for admin console.

B. Opera – Not mentioned in the PingAccess support matrix; therefore unsupported.

E. Brave – Chromium-based but explicitly unlisted; no official support statement.

1. Ping Identity. “PingAccess 10.0 Release Notes,” Section 1.4 “Supported browsers,” pp. 3–4.

2. Ping Identity. “PingAccess 9.3 Release Notes,” Section 1.3 “System requirements – Browsers,” p. 2.

3. Ping Identity. “PingAccess Admin Guide 8.3,” Chapter 1 “Supported technology,” Table 1-2, p. 7.

In PingAccess you grant CORS access by listing the domains that are allowed to make the browser request. Setting Allowed Origins to “.anycompany.com” matches every application that sits on a sub-domain of anycompany.com, so every needed app can obtain the images and fonts from www.anycompany.com. Because the resources are static, cookies are not required; therefore Allow Credentials should be left disabled. This combination satisfies security guidelines (no credentials are exposed) while meeting the CORS specification that “” may be used only when Allow Credentials = false.

A. Requires enumerating every single app domain; scalable but not simpler than a single wildcard and still no credentials.

C. Violates CORS spec—“” cannot be returned when Allow Credentials is true; browsers reject the response.

D. Returns Access-Control-Allow-Origin: www.anycompany.com, which does not match the calling applications’ origins, so the browser still blocks the request.

1. Ping Identity, “PingAccess Server 10.0 Administration Guide,” Section “Add a Cross-Origin Resource Sharing rule,” pp. 277-278: Allowed Origins may use a sub-domain wildcard (.example.com); “” is valid only when Allow Credentials is not selected.

2. Ping Identity, “PingAccess Server 8.3 Administration Guide,” Table “CORS Rule Fields,” p. 249: “If Allow Credentials is selected the Access-Control-Allow-Origin header cannot be .”

3. MIT OpenCourseWare, 6.858 Computer Systems Security (Fall 2014), Lecture 4 notes, “Browser Same-Origin Policy and CORS,” para. 8: credentials are unnecessary for public static resources and should be disabled for security.

PingAccess, as a Java-based application, includes a default trust store (the Java Trust Store) which contains the root certificates of most major public Certificate Authorities (CAs). PingAccess exposes this as a pre-configured "Java Trust Store Certificate Group". When a backend target site uses a certificate issued by a publicly trusted CA, no manual certificate import is necessary. The administrator simply needs to configure the Site in PingAccess to use this built-in trust group, which allows PingAccess to validate the target's certificate chain against the already-trusted public CAs.

A. Import the certificate chain into Key Pairs and add it to a Trusted Certificate Group:

Key Pairs are used for PingAccess's own identity (e.g., for listeners or mutual TLS), not for trusting certificates presented by backend sites.

C. Import the certificate chain into Key Pairs:

This is incorrect for the same reason as option A. Key Pairs are for PingAccess's own private keys and certificates, not for storing trusted CA certificates.

D. Drop the certificate chain into a Trusted Certificate Group:

This action is unnecessary. Since the certificate is from a publicly trusted CA, its root is already present in the default Java Trust Store, making manual import redundant.

1. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Trusted Certificate Groups

Reference: "PingAccess provides a default trusted certificate group, the Java Trust Store, which contains a set of default trusted certificate authorities. You can also create your own trusted certificate groups and import certificates into them." This confirms the existence and purpose of the Java Trust Store group for default public CAs.

2. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Add a site

Reference: In the "Add a Site" configuration steps, under the "Secure" option, the guide states: "If you enable this option, you must also select a trusted certificate group from the Trusted Certificate Group list." This shows that the correct procedure is to select an existing group, and for public CAs, the appropriate choice is the "Java Trust Store" group.

3. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Key Pairs

Reference: "Key pairs are used to identify PingAccess to clients. For example, you can assign a key pair to a virtual host to secure communication between a client and PingAccess." This documentation explicitly defines the purpose of Key Pairs as being for PingAccess's own identity, distinguishing them from Trusted Certificate Groups used to trust others.

For PingAccess to terminate SSL/TLS for a proxied application, it must possess the server's private key and its corresponding public certificate chain. In PingAccess, this combination of a private key and a certificate is managed as a "Key Pair". The standard and most common method for importing a private key along with its full certificate chain is by using a PKCS#12 (or PFX) file. This file format securely bundles all necessary components, which are then imported into the "Key Pairs" section of the PingAccess administrative console to be used by an HTTPS listener.

A. The "Certificates" section is for managing trust anchors (like CA certificates), not for storing the server's own private key and certificate used for SSL termination.

B. While a PKCS#12 file is the correct format, it must be imported into "Key Pairs," not "Certificates," as the latter is for trust stores and does not handle private keys.

C. The "Key Pairs" section is correct, but importing only the public key and certificate chain is insufficient. The private key is mandatory for SSL termination, which this option omits.

1. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Managing key pairs.

Page/Section Reference: In the introduction to the "Managing key pairs" section, the documentation states, "Key pairs are used by PingAccess as server certificates for TLS connections...". It further details the import process: "You can import a key pair from a PKCS#12 file...". This confirms that the "Key Pairs" section is the correct location and PKCS#12 is a valid import format for this purpose.

2. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Configuring HTTPS listeners.

Page/Section Reference: This section explains that when configuring an HTTPS listener, you must "Select the key pair that PingAccess presents to clients for the TLS handshake." This directly links the imported Key Pair to the function of SSL termination for an application.

3. Ping Identity PingAccess 7.3 Administrator's Guide, Section: Managing certificates.

Page/Section Reference: The documentation for this section clarifies its purpose: "Use this page to manage certificates for trusted certificate authorities (CAs)...". This confirms that the "Certificates" section is a trust store and is not the correct location for the server's own SSL certificate and private key.

PingAccess is a modern access security solution designed to protect web applications and APIs. Its core functionality is built upon the OAuth 2.0 and OpenID Connect (OIDC) standards. It acts as an OAuth 2.0 Resource Server, validating access tokens to enforce authorization policies and protect resources. For user authentication and session management, PingAccess functions as an OIDC Relying Party, leveraging an identity provider (like PingFederate) to authenticate users and establish secure sessions based on the identity information contained within an ID Token. These two protocols work together to provide a comprehensive authentication and authorization framework.

A. SAML: While PingAccess can integrate into a SAML-based SSO environment (typically via PingFederate), its native and primary protocol for creating modern web sessions is OIDC, not SAML.

B. WS-Fed: This is a legacy federation protocol. PingAccess is built on modern standards and does not use WS-Fed for its core authentication or authorization mechanisms.

C. WS-Trust: This is part of the WS-Federation protocol suite and is not a protocol directly used by PingAccess for its primary functions of authentication and authorization.

1. Ping Identity Documentation, PingAccess 7.3 Administrator's Guide:

Section: "About PingAccess", Page 10.

Content: "PingAccess is a reverse-proxy that protects web applications and APIs by applying security policies to client requests. It works with your identity provider to grant access to protected resources based on OAuth 2.0 and OpenID Connect (OIDC) standards." This statement explicitly names both protocols as the foundation for PingAccess's operation.

2. Ping Identity Documentation, PingAccess 7.3 Administrator's Guide:

Section: "PingAccess for APIs", Page 12.

Content: "When a client application attempts to access a protected API, it must present a valid OAuth 2.0 access token... PingAccess validates the access token with the OAuth Authorization Server..." This confirms the use of OAuth 2.0 for authorization.

3. Ping Identity Documentation, PingAccess 7.3 Administrator's Guide:

Section: "PingAccess for web applications", Page 11.

Content: "When a user attempts to access a protected web application, PingAccess redirects the user's browser to the OpenID Provider (OP) to authenticate. After successful authentication, the OP provides an ID token..." This confirms the use of OIDC for authentication.

To promote a replica administrative node to become the primary console in a PingAccess cluster, the administrator must first change its designated role. This is accomplished by editing the run.properties file on the replica node and changing the pa.operational.mode from CLUSTEREDCONSOLEREPLICA to CLUSTEREDCONSOLE. For this configuration change to be applied and for the node to assume its new role as the primary console, the PingAccess service on that specific node must be restarted. These two actions are the core requirements for the promotion process.

A. Changing an engine node's operational mode to a replica console is irrelevant to the task of promoting an existing replica admin node.

B. Restarting all nodes is not required. Only the node being promoted needs a restart. Engine nodes will be reconfigured and restarted later to point to the new primary.

E. Modifying bootstrap.properties is an action performed on the engine nodes to point them to the new primary console, not a step in promoting the replica itself.

1. PingAccess 7.3 Administrator's Guide, Section: "Clustering", Subsection: "Promoting a replica administrative node".

The guide explicitly states the procedure: "To promote a replica administrative node to an administrative node... 1. Stop the replica administrative node you want to promote... 2. Edit /conf/run.properties and change pa.operational.mode=CLUSTEREDCONSOLEREPLICA to pa.operational.mode=CLUSTEREDCONSOLE... 3. Start the node." This directly supports answers C and D.

2. PingAccess 7.3 Administrator's Guide, Section: "Clustering", Subsection: "Reconfiguring engines".

This section details the subsequent steps after a promotion, which include modifying the bootstrap.properties file on each engine. This confirms that option E is a separate, later step performed on different nodes.