PingID Administration Guide

Policy and rule authentication methods

Define the authentication methods that you want to allow per policy and the authentication actions you want to enforce for each policy rule.

For examples of specific use cases and more detailed information about implementation, see Authentication method selection and priority - use cases.

Authentication methods are configured:

  • Per policy: Select the authentication methods that you want to allow in the policy.

    A screen capture of the Allowed Authentication Methods section displaying the Methods list and check boxes. The All Methods check box is selected.

    • The authentication methods selected are the only authentication methods the user is allowed to authenticate with if this policy is applied.

    • The methods selected in the Allowed Authentication Methods section determine the actions available in all rules related to this policy.

      For a definition of the allowed authentication methods, see Allowed authentication methods.

      Only authentication methods that are enabled at the organization level are available at the policy level. For details of how to configure authentication options at the organization level, see Configure the PingID service.

  • Per rule: The Rule action determines how the user is authenticated in the event that the rule is applied. For a definition of the available rule authentication actions, see Rule authentication actions.

A screen capture of the Default Action section displaying the Action list.

Allowed authentication methods

Define the authentication methods you want to make available for the policy in the Allowed Authentication Methods section. Only the selected allowed authentication methods are listed as options in the authentication rule Action list.

If a new authentication method is added as a PingID capability and the All Methods check box is not selected in the Allowed Authentication Methods section, you must edit each policy and select the check box of the new authentication method manually to include it in a policy.

A description of the allowed authentication methods is shown in the following table.

Authentication methods allowed per policy
Allowed Authentication Method Description

All Methods

Permit the use of all authentication methods currently configured for the organization.

When the All methods check box is selected:

  • All available authentication methods are permitted at the policy level.

  • If additional authentication methods are added to PingID in the future, they are automatically applied to the policy.

  • Within a policy rule, all available authentication methods are listed in the rule Actions list.

  • Deprecated authentication actions appear and can be selected in policy rule Actions list. See Deprecated authentication actions.

If the All methods check box is not selected:

  • Only the specific authentication methods selected in the Allowed Authentication Methods list are available for the user to authenticate.

  • If additional authentication methods are added to PingID in the future, they are not applied to existing policies automatically. Existing policies must be edited individually and the new authentication method added manually in order to apply it to the policy.

  • Within a rule, only the selected authentication methods are listed in the authentication actions in addition to relevant default actions, such as Approve, Deny, and Authenticate.

  • Deprecated authentication actions are not available in the policy rule Actions list.

Authenticator app

Authentication using an authenticator app, such as Google authenticator, is permitted.

Backup Authentication

Authentication using a backup authentication method is permitted. This option is useful if a user forgets their device, or it is lost or stolen.

The Forgot your device? link only appears if:

  • Either the Authenticate rule action, or a rule action that includes a mobile device authentication method such as Mobile App Biometrics, is configured.

  • At least one backup authentication method is defined. See Configuring backup authentication methods.

Desktop

Authentication by a desktop app is permitted.

Email

Authentication by email is permitted.

FIDO2 Biometrics

Authentication by a FIDO2 biometrics device is permitted for web-based policies only.

Mobile App Biometrics

Authentication by a supported biometrics devices is permitted and applied according to the configuration defined in the Admin portal.

Number matching

Authenticate by number matching is permitted.

  • Number matching has priority overMobile App Biometrics andSwipe authentication methods.

  • If Mobile app biometrics is set to Require in the Configuration tab, the user must authenticate successfully using biometrics and then authenticate using number matching.

  • Number matching is only supported by apps that are using web-based authentication.

Oath Token

Authentication using an OATH Token is permitted.

One-time passcode

Authentication using a one-time passcode (OTP) obtained using PingID mobile app is permitted.

If this option is not selected, fallback to a OTP and direct passcode usage are not allowed, even if it is enabled in the Configuration page.

SMS

Authentication using an OTP obtained through SMS is permitted.

Security Key

Authentication using a security key is permitted for web-based policies only.

Swipe

Authentication using swipe is permitted.

Voice

Authentication using an OTP obtained through voice message is permitted.

YubiKey

Authentication using a YubiKey is permitted.

Rule authentication actions

The list of authentication actions that you can choose to enforce within a policy rule is determined by the authentication methods allowed at the policy level.

Rule authentication actions and deprecated actions
Authentication Action Description

Approve

Approves access without requiring PingID authentication.

This rule action cannot be used in a PingFederate passwordless flow, because at least one factor authentication is required to use the Approve action.

Authenticate

Allows a user to authenticate using any of the authentication methods available to the user and allowed at the policy level.

If a user has a mobile app with both biometrics and swipe capabilities, biometrics authentication is given priority.

Authenticator app

Allows a user to authenticate using an authenticator app only, such as Google authenticator.

Deny

Denies access.

Desktop

Allows a user to authenticate using a desktop app only.

Email

Allows a user to authenticate using an email app only.

FIDO2 Biometrics

Allows a user to authenticate using device built in biometrics on a FIDO2 biometrics device. This option is only available for web-based policies.

Mobile App Biometrics

Allows a user to authenticate with the PingID mobile app using biometrics authentication only. This action works according to the biometrics configuration defined in the admin portal.

Swipe authentication is also permitted if the following conditions are met:

  • If Device Biometrics is configured as Enabled, and biometrics are not defined on the user’s device.

  • If Device Biometrics is not configured as Require in the admin configuration page.

  • If biometrics are not supported on the user’s device.

A one-time passcode fallback is also permitted when selecting this option.

DEPRECATED: Fingerprint (with fallback)

  • If the primary or selected device is the PingID mobile app, fingerprint authentication is used according to the fingerprint configuration defined in the admin portal. Fingerprint is the preferred method, but it is also possible to authenticate using swipe or a one-time passcode (OTP).

  • If the primary or selected device is not the PingID mobile app, the user authenticates with that device.

Number matching

Authenticate by number matching is permitted.

  • Number matching has priority overMobile App Biometrics andSwipe authentication methods.

  • If Mobile app biometrics is set to Require in the Configuration tab, the user must authenticate successfully using biometrics and then authenticate using number matching.

Oath Token

Allows a user to authenticate using an OATH token only.

One-time passcode

One-time passcode (required)

Allows a user to authenticate using a OTP obtained from the PingID mobile app only.

DEPRECATED:

One-time passcode (with fallback)

  • If the primary or selected device is the PingID mobile app, the user must enter an OTP using the mobile app.

Swipe or fingerprint authentication is not permitted in this case.

  • If the primary or selected device is not the PingID mobile app, the user authenticates with that device.

SMS

Allows a user to authenticate using a passcode obtained by SMS only.

Security Key

Allows a user to authenticate using a security key only. This option is only available for web-based policies.

Swipe

Swipe (required)

Allows a user to authenticate using the PingID mobile app swipe action only.

A OTP fallback is also possible when selecting this option.

DEPRECATED: Swipe (with fallback)

  • If the primary or selected device is the PingID mobile app, swipe is always required.

Even if the user has fingerprint authentication defined on their device, fingerprint is not required in this case.

  • If the primary or selected device is not the PingID mobile app, the user authenticates with that device.

Voice

Allows a user to authenticate using a passcode obtained by a voice message only.

YubiKey

Allows a user to authenticate using a YubiKey only.

Deprecated actions

Some of the authentication methods in the rule Action list are in the process of being deprecated and will be removed at a future date. Until they are decommissioned, existing policies that contain deprecated actions remain unchanged.

Deprecated (legacy) actions are available for backward compatibility although the names have been changed to reflect their legacy status. For the updated names, see Rule authentication actions.

Deprecated authentication actions are only available in the rule Action list if the All Methods check box is selected in the Allowed Authentication Methods section at the policy level. We recommend that you upgrade all existing policy rules to the new, more specific authentication actions.

Authentication method selection and priority - use cases

See the following table for detailed examples of use cases where the configuration at the organization level can affect the implementation of an authentication policy.

Authentication method selection by specific use cases
Use Case User Paired Devices Allowed Authentication Methods Rule Action Result Reason

1

  • SMS (primary)

  • Email

All methods

Email

User is requested to authenticate through email

Although the primary is SMS, the user is requested to authenticate using email as the rule action requires email.

2

  • Desktop (primary)

  • Email

  • YubiKey

YubiKey

Authenticate

User is requested to authenticate with YubiKey

User is automatically prompted to authenticate using a YubiKey, regardless of whether the configuration is set to Default to Primary or Prompt user to select. This is because the user only has one allowed authentication method paired with their account.

3

  • The PingID mobile app (primary)

  • SMS

  • Voice

SMS/ Voice/ Email

Authenticate

User is unable to authenticate

  • Default to Primary: Even though the user’s primary device is disallowed (PingID Mobile app), the user is prompted to authenticate with the device that was enrolled first out of the list of allowed secondary devices.

  • Prompt user to select: the user is presented with a list of secondary devices. The user selects the secondary device with which they want to authenticate.

4

  • SMS (primary)

  • YubiKey

  • Email

Mobile App Biometrics/ Swipe / One-time passcode

Authenticate

Authentication denied

User does not have one of the allowed authentication methods paired with their account.

5

  • The PingID mobile app (primary)

  • Desktop

  • Voice

All methods

SMS

Authentication denied

User does not have the required authentication method paired with their account.

6

The PingID mobile app (Swipe disabled)

Mobile App Biometrics/ Swipe

Authenticate

Authentication denied

Swipe is disabled in the PingID mobile app and the user is unable to receive a push notification.

As a one-time passcode (OTP) is not included in the Allowed Authentication Methods, the user cannot use an OTP, even if OTP Fallback is enabled.

7

The PingID mobile app (Swipe disabled)

All methods

Mobile App Biometrics (required)

Authentication denied

Mobile App Biometrics (required) permits authentication with biometrics only, and does not allow use of an OTP.

“Swipe disabled” prevents the user from receiving a push notification to their device, preventing the user from authenticating with biometrics.

8

The PingID mobile app where:

  • Device supports biometrics

  • Biometrics not defined on device

Mobile App Biometrics

Mobile App Biometrics (required)

The user is able to authenticate using swipe or their device passcode in the event that their device screen is locked.

If a device does not support biometrics, PingID allows the user to authenticate using swipe as an exception. If the device supports biometrics, but biometrics are not defined on the device, the user can use swipe.

This is possible because biometrics is enabled (and not required) by the biometrics configuration

9

The PingID mobile app where:

  • Device does not support biometrics

  • Biometrics required at configuration level

Mobile App Biometrics

Mobile App Biometrics (required)

The user is able to authenticate using swipe or their device passcode in the event that their device screen is locked.

Although biometrics is required, because the user’s device does not support biometrics, the user is still able to authenticate with swipe (if device unlocked), or using their device passcode (if device is locked).

10

The PingID mobile app where:

  • Device supports biometrics

  • Biometrics not defined on device

  • Biometrics required at configuration level

Mobile App Biometrics

Mobile App Biometrics (required)

The user is not able to authenticate

Biometrics are required at the configuration level, and biometrics authentication is possible on the user’s device. The user is not able to authenticate because they have not defined biometrics on the device.

11

The PingID mobile app where:

  • Device supports biometrics

  • Biometrics are defined on device

  • Biometrics required at configuration level

Mobile App Biometrics / Swipe

Authenticate

User is able to authenticate with biometrics

Biometrics have a higher priority over swipe, and the user is prompted to authenticate with biometrics.

12

  • Security key (primary)

  • Email

  • SMS

Where the browser used does not provide WebAuthn support required for security key.

All methods

Authenticate

User is able to authenticate with email or SMS

  • Default to Primary: Even though the user’s primary device is disallowed because the browser does not support WebAuthn, the user is prompted to authenticate with the secondary device that was enrolled first out of the list of allowed secondary devices.

  • Prompt user to select: A security key is not included in the list of devices, as the browser does not support WebAuthn. The user is presented with a list of secondary devices only. The user selects the secondary device with which they want to authenticate.

13

  • Security key (primary)

  • Email

  • SMS Where the browser used does not provide WebAuthn support required for security key.

All methods

Security Key

User is unable to authenticate

Even though the user has a security key paired with their account, they are signing on using a browser that does not support WebAuthn.

14

  • The PingID mobile app (primary)

  • Security key

  • Email

Where the browser supports WebAuthn. Policy rule authenticating from a new device is applied and requires a security key.

All methods

Security key

User is able to authenticate with a Security key only. In the case of a phishing attack, the user is not able to authenticate with any device.

  • If authenticating from a new device a security key is required.

  • If the user is subject to a phishing attack, PingID can distinguish between a known and a fraudulent copy of a web page. If fraudulent, PingID does not recognize the source and triggers the accessing from new device policy rule. Even though the user has other devices paired, they are prompted to authenticate using a security key only, and cannot change device due to the policy rule restrictions.

This configuration guards all devices against a phishing attack.

15

  • FIDO2 biometrics (primary)

  • Email

  • SMS

Where the browser used does not provide WebAuthn Platform support.

All methods

FIDO2 Biometrics

User is unable to authenticate

Even though the user has a FIDO2 biometrics device paired with their account, they are signing on using a browser that does not support WebAuthn.

16

  • The PingID mobile app (primary)

  • FIDO2 Biometrics

  • Email

Where the browser supports a WebAuthn Platform. Policy rule authenticating from a new device is applied and requires a security key.

All methods

FIDO2

User is able to authenticate with FIDO2 only. In the case of a phishing attack, the user is not able to authenticate with any device.

  • If authenticating from a new device, FIDO2 biometrics device is required.

  • If the user is subject to a phishing attack, PingID can distinguish between a known and a fraudulent copy of a web page. If fraudulent, PingID does not recognize the source and triggers the accessing from new device policy rule. Even though the user has other devices paired, they are prompted to authenticate using a FIDO2 biometrics device only and cannot change device due to the policy rule restrictions.

This configuration guards all devices against a phishing attack.