Authentication challenge policies

Authentication challenge policies set the response sent by PingAccess when it receives unauthenticated requests for protected resources from web applications.

Each authentication challenge policy consists of one default mapping and zero or more challenge response mappings. When a user attempts to access a protected resource and a PingAccess web session has not yet been established, and when the request characteristics match those of a challenge response mapping, the response specified in the challenge response mapping is used. If the request does not match any challenge response mappings, the default mapping is used.

Note:

PingAccess deploys several system-provided authentication challenge policies that are automatically enabled on initial startup. These policies are identifiable by the presence of a gray flag to the right of the policy's name on the Authentication Challenge Policies page. You can view system-provided authentication challenge policies, but you can't edit or delete them. To create your own customizable authentication challenge policies, see Configuring authentication challenge policies.

Screen capture of the Authentication Challenge Policies page. The system-provided authentication challenge policies are marked with a grey flag.
System-Provided Authentication Challenge Policies
System-Provided Authentication Challenge Policy Description

Content Negotiated Authentication Request

Allows the user agent to negotiate the form of the authentication challenge response with an Accept header field in the request. If the user agent requests HTML, a 401 response returns with an HTML body that will automatically initiate an OpenID Connect (OIDC)OpenID Connect (OIDC)OIDC An authentication protocol built on top of OAuth that authenticates users and enables clients (relying parties) of all types to request and receive information about authenticated sessions and users. OIDC is extensible, allowing clients to use optional features such as encryption of identity data, discovery of OpenID Providers (OAuth authorization servers), and session management. login flow via a JavaScript redirect. Otherwise, the user agent receives a JSONJSON (JavaScript Object Notation) An open, lightweight data-interchange format that uses human-readable text to store and transmit data. response.

MS-OFBA

Provides MS-OFBA support, enabling you to open Microsoft (MS) Office documents protected by PingAccess in an in-app browser that redirects to the OpenID Provider (OP)OpenID Provider (OP)OP In OAuth terms, an authorization server (AS). The OP/AS issues access tokens to protected resources for approved clients (relying parties). The clients use the access token to access the protected resources hosted by the OAuth resource server. for user authentication. If the user authenticates successfully, PingAccess establishes a web session and redirects the user to the MS Office application that matches the document type (spreadsheets open in Microsoft Excel, for example).

Note:

The system-provided MS-OFBA authentication challenge policy does not work with any Microsoft Office applications running on macOS. The macOS in-app browser is much more restrictive than the one in Windows. It cannot set the nonce cookie that PingAccess requires before redirecting a user to the OP.

Note:

In some environments, Internet Explorer configurations can dictate the behavior of the in-app browser in Microsoft Office products. If the document you requested fails to download, ensure that Do not save encrypted pages to disk is disabled in Internet Explorer -> Internet Options -> Advanced -> Settings -> Security.

Web sessions are not shared between different MS Office apps, but users do not have to reauthenticate for apps they've already opened. So, if you authenticate after opening an Excel sheet, you can open other Excel sheets without needing to reauthenticate. If you open a Word document after authenticating into an Excel sheet, however, then you must reauthenticate to access the Word document.

Note:

You can configure MS-OFBA challenge response mappings and challenge response generators individually in a custom authentication challenge policy, but a custom creation like this is best used to address unusual circumstances as they come up.

For example, if Microsoft includes a new entry on the list of user agents approved for MS-OFBA, an administrator can create a branching challenge response mapping for the new user agent and set it to trigger the MS-OFBA Authentication Request Redirect response generator.

Alternately, an administrator could set the MS-OFBA header X-FORMS_BASED_AUTH_DIALOG_SIZE using the Append Header Fields challenge response filter.

SPA Support Disabled

PingAccess disables SPA support on a global scale out of the box so admins do not have to manually turn off SPA support on each individual application. SPA support can be re-enabled on a per-application basis, as seen in Application field descriptions. For more information on the benefits of SPA support, see Applications operations.

Unauthorized JSON

Unconditionally returns a 401 JSON response.

Authentication requirements

Authentication requirements are methods of authentication that are ordered by preference.

When a user attempts to access a PingAccess web application configured with an authentication requirement list containing the values password and certificate, PingAccess redirects the user to PingFederate requesting either password or certificate user authentication. PingFederate authenticates the user based on the password and issues an OIDC ID token to PingAccess, containing the authentication method that was used. PingAccess ensures that the authentication method matches the requirements and redirects the user to the originally requested application with the PingAccess cookie set. When the user attempts to access a more sensitive application configured with an authentication requirement list containing the value (certificate), they are redirected to PingFederate to authenticate with a certificate.

You can configure applications with authentication requirement lists that have no overlap. For example, if one list has a password and another list has a certificate, a user navigating between applications might be required to authenticate each time they visit an application. When configuring authentication requirement lists to protect higher value applications with step-up authentication, include stronger forms of authentication when configuring lower value applications.