Triggering push notifications in the agent

The agents provide two user interaction models:

• Simple mode, which is provided by the SafeNet RADIUS Service or SafeNet Agent for NPS 2.0
• Rich user experience, which is provided by the SafeNet SAML Service and SafeNet Agent for AD FS.

Simple mode

With simple mode, if push OTP is enabled, the user can trigger a push notification by:

• leaving the passcode field empty, or
• entering any 1-character passcode (excluding e, s, or g if other authentication methods are present)

To override push and use another authentication method (if present), the user can:

• enter e to trigger email, or
• enter s to trigger SMS, or
• enter g to trigger GrIDsure

If push OTP is disabled for the virtual server, an empty or any 1-character passcode triggers an SMS challenge-response or a GrIDsure, depending on the token type that the user has enrolled.

Passcode triggers are not case-sensitive.

For MS-CHAPv2 encryption, instead of any 1-character, the only passcode triggers that are allowed are p, s, g, or a space. Using any other character causes the authentication to fail.

Rich user experience

With the rich user experience provided by the SafeNet SAML Service and SafeNet Agent for AD FS, if push OTP is enabled, the user is presented with the option to choose between using their mobile device to automatically send a passcode, or manually entering a passcode.

To override push and use another authentication method (if present), the user can:

• Choose Enter a passcode manually, and then:

  • enter e to trigger email, or
  • enter s to trigger SMS, or
  • enter g to trigger GrIDsure

If push OTP is disabled for the virtual server, an empty or any 1-character passcode triggers an SMS challenge-response or GrIDsure, depending on the token type that the user has enrolled.

Passcode triggers are not case-sensitive.

For MS-CHAPv2 encryption: Instead of any 1-character, the only passcode triggers that are allowed are p, s, g, or a space. Using any other character causes the authentication to fail.

Push notification contents

Push notification includes the following content:

• Resource Name: This is the application where the login request originated.

• Organization Name: This matches the custom organization name that is defined in STA (see Set the custom organization name).

• User Name: This is the user who made the request (this name should match what was typed in during login on the application).

• Timestamp: This is the login request start time, localized for display on the phone.

• Geolocation and IP Address: This is the location and the user IP address where the request originated. For web-based agents, this is the browser IP address, and for login agents, this is the machine IP address. The user IP address is not supported for the STA RADIUS service.

What happens...

...when a user accepts a push notification?

When a user receives a login request on their phone, and taps APPROVE, the notification automatically generates an OTP and sends it to STA. When the authentication succeeds, the user is granted access to the protected resource.

...when a user denies a push notification?

When a user receives a login request on their phone and taps DENY, two options are presented:

• It wasn’t me! — Tapping this option ends the authentication, and treats it as a failed authentication (as if the user had typed the wrong passcode).

• I made a mistake — Tapping this option ends the authentication. This is treated the same as a timeout or expired notification.

If configured, rejecting a notification sends a push notification rejection alert email to the user and the operator. If the user’s account gets locked due to this push OTP rejection, the body of this alert is appended to the user lockout alert that is sent to the user.

See the Customize the rejection alert for the user and Customize the rejection alert for the internal operator.

...if a push notification times out?

If a push notification times out, the user can either initiate push again, or manually enter a generated OTP.

...if a user is challenged for an OTP to resync the token?

If a user is challenged for an OTP to resync the token, the OTP is not automatically sent and has to be entered manually. In the STA Token Management console in Snapshot > Authentication Activity, this is logged as an Outer Window Authentication event in the Result column, and the user needs to resynchronize the token by manually entering a new OTP.

Authentication activity logging

Push log activity can be viewed in the STA Token Management console in Snapshot > Authentication Activity.

• Push notifications are listed in the Result column as Challenge, and are displayed with the same information that is included in the push notification to the user.

• Push notifications that are accepted (approved) by the user are listed in the Result column as Success.

• Push notifications that are rejected (deny & report) by the user are listed in the Result column as Failure, with a message to indicate that the failure was due to user rejection.

• Push notifications that are ignored by the user do not result in another entry after the Challenge.

Push OTP authentication history report

This report lists Push OTP transactions and their outcome in chronological, descending order.