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.
-
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.
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.
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:
If the All methods check box is not selected:
|
||
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:
|
||
Desktop |
Authentication by a desktop app is permitted. |
||
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.
|
||
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.
|
||
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.
Authentication Action | Description | |||
---|---|---|---|---|
Approve |
Approves access without requiring PingID authentication.
|
|||
Authenticate |
Allows a user to authenticate using any of the authentication methods available to the user and allowed at the policy level.
|
|||
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. |
|||
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:
|
|||
DEPRECATED: Fingerprint (with fallback) |
|
|||
Number matching |
Authenticate by number matching is permitted.
|
|||
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) |
|
|||
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.
|
||
DEPRECATED: Swipe (with fallback) |
|
|||
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.
Use Case | User Paired Devices | Allowed Authentication Methods | Rule Action | Result | Reason |
---|---|---|---|---|---|
1 |
|
All methods |
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 |
|
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 |
|
SMS/ Voice/ Email |
Authenticate |
User is unable to authenticate |
|
4 |
|
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 |
|
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:
|
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:
|
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:
|
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:
|
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 |
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 |
|
13 |
|
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 |
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. |
This configuration guards all devices against a phishing attack. |
15 |
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 |
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. |
This configuration guards all devices against a phishing attack. |