FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Debbie_FTNT
Staff & Editor
Staff & Editor
Article Id 415011
Description

 

This article explains the basic principles of Push Notification in the context of MFA in an easily understood manner.

 

Scope

 

FortiToken Mobile Application, FortiGate, FortiProxy, FortiAuthenticator.

 

Solution

 

Push Notifications are pop-up messages on mobile phones triggered by an application and provide updates/information about the application, anything from advertising to special offers to various timers.

Authenticator apps can use Push Notifications as a form of multi-factor-authentication (MFA). Essentially, when a user logs in, instead of being asked to enter a code as a second factor or present a certificate, the user receives a Push Notification and needs to confirm it.

 

A usual authentication flow with push notification includes the following components:

 

User/Client application.

Application/Gateway.

Authentication Server.
The user and client application are connecting to the service in question.

The gateway or application the user is connecting to. It requires the user to authenticate to proceed.

The server validating the user's credentials and triggering push notification as multi-factor-authentication; may be the same device as Server/Application/Gateway.

client.png

 

Example: FortiClient.

application.png

 

Example: FortiGate.

authserver.png

 

Example: FortiAuthenticator.


Authentication, including push notification, follows roughly this flow (excluding SAML authentication):

 

  1. The user/client connects to the application/gateway.
                                                                                             
    strip1.png

     

  2. The user/client provides credentials.
                                                      
    strip2.png

     

  3. The application checks the credentials against the authentication server.
                                                                             
    strip3.png
    Note:
    The application/gateway may be the same as the Authentication Server in some circumstances; for example, a FortiGate with local users.

  4. The authentication server sends a push notification to the user as a second factor.
                                                                            
    strip4.png                                                                       
    Note: 
    The authentication server might not trigger push notification itself and instead involve a different server/service for multi-factor authentication (FortiIdentityCloud, for example), which then performs the push notification. The notification message is sent to Apple/Android/etc messaging servers that forward it to the appropriate user device.

    Note for Fortinet Products specifically: FortiGate or FortiAuthenticator, instead of defaulting to push notification where possible, instead offer a choice to trigger push notification, and FortiClient (or FortiGate acting as application/gateway) may trigger push notification to occur automatically without user input. They may also present a message to the user to either enter a token code or select push notification.

  5. The user confirms the push notification and sends back a reply.
                                                                                         
    strip5.png
    Note: 
    The Authenticator app that receives the push notification (FortiToken Mobile App, for example) sends back the reply to the return address included in the push notification. The return address must be reachable from the user's mobile phone.

  6. The authentication server receives the push reply message (the application/gateway waits in the meantime).
                                                                                       
    strip6.png
    Note: 
    If the application/gateway does not handle the authentication and second factor itself, it has no insight into the push notification/reply and must be configured with a longer timeout to allow enough time for the push notification to be received and replied to. Otherwise, the authentication attempt may time out while the push notification is performed.

  7. The authentication server confirms that user credentials were validated successfully and may return additional information like group memberships.
                                                                                 
    strip7.png
  8. The application/gateway allows the user/client access.
                                                                                                                  
    strip8.png

 

Note on SAML Authentication:

The initial authentication flow for SAML differs significantly as the application/gateway (Service Provider in SAML context, SP) does not pass on the user credentials itself, but instead redirects the user to the Authentication Server (Identity Provider in SAML context, IdP). The SAML Identity Provider itself may trigger push notifications similar to the Authentication Server outlined here. A basic explanation of SAML authentication flow may be found here:

Technical Tip: A basic explanation of SAML authentication  

 

Related articles:

Technical Tip: FortiToken Mobile push notification
Technical Tip: FortiAuthenticator Push Notification Work Flow