6.3.1.12. Legacy PUSH Token

The legacy PUSH token uses the unsupported privacyIDEA Authenticator app. You can get it from Google Play Store or Apple App Store.

Warning

The legacy PUSH token type is deprecated and will be removed in the future. We strongly recommend using the eduPUSH Token token type instead.

The token type push sends a cryptographic challenge via the Google Firebase service to the smartphone of the user. This push notification is displayed on the smartphone of the user with a text that tells the user that he or somebody else requests to login to a service. The user can simply accept this request. The smartphone sends a cryptographically signed response to the eduMFA server and the login request gets marked as confirmed in the eduMFA server. The application checks for this mark and logs the user in automatically. For an example of how the components in a typical deployment of legacy PUSH tokens interact reference the following diagram.

A typical legacy PUSH token deployment

To allow eduMFA to send push notifications, a Firebase service needs to be configured. To do so see Firebase Provider.

The legacy PUSH token implements the outofband mode.

6.3.1.12.1. Configuration

The minimum necessary configuration is an enrollment policy edupush_firebase_configuration, push_firebase_configuration.

With the authentication policies edupush_text_on_mobile, push_text_on_mobile and edupush_title_on_mobile, push_title_on_mobile you can define the contents of the push notification.

If you want to use legacy PUSH tokens with legacy applications that are not yet set up to be compatible with out-of-band tokens, you can set the authentication policy edupush_wait, push_wait. Please note, that setting this policy can interfere with other tokentypes and will impact performance, as detailed in the documentation for push_wait.

6.3.1.12.2. Enrollment

The enrollment of the legacy PUSH token happens in two steps.

6.3.1.12.2.1. Step 1

The user scans a QR code. This QR code contains the basic information for the legacy PUSH token and a enrollment URL, to which the smartphone should respond in the enrollment process.

The smartphone stores this data and creates a new key pair.

6.3.1.12.2.2. Step 2

The smartphone sends its Firebase ID, the public key of the keypair, the serial number and an enrollment credential back to the enrollment URL of the eduMFA server.

The server responds with it’s public key for this token.

6.3.1.12.3. Authentication

6.3.1.12.3.1. Triggering the challenge

The authentication request is triggered by an application just the same like for any challenge response tokens either with the PIN to the endpoint /validate/check or via the endpoint /validate/triggerchallenge.

eduMFA sends a cryptographic challenge with a signature to the Firebase service. The firebase service sends the notification to the smartphone, which can verify the signature using the public key from enrollment step 2.

6.3.1.12.3.2. Accepting login

The user can now accept the login by tapping on the push notification. The smartphone sends the signed challenge back to the authentication URL of the eduMFA server. The eduMFA server verifies the response and marks this authentication request as successfully answered.

In some cases the push notification does not reach the smartphone. The smartphone can also poll for active challenges.

6.3.1.12.3.3. Login to application

The application can check with the original transaction ID with the eduMFA server, if the challenge has been successfully answered and automatically login the user.