Authentication
Authentication challenge policies and authentication requirements let you control how users are authenticated.
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.
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. |
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) login flow via a JavaScript redirect. Otherwise, the user agent receives a JavaScript Object Notation (JSON) 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) 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).
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.
|
||||||
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.