Configuring Passwordless Biometric Authentication on ForgeRock
About Juan Redondo
For any queries, feedback you may have please contact me on firstname.lastname@example.org
Today we are going to focus on how to deploy a passwordless solution to our ForgeRock AM instance that will provide a biometric authentication that can be integrated to your mobile or desktop application.
The solution will make use of standard RSA signature verification provided by the java.security package and has been successfully tested on iOS and Android devices.
Note that a key requirement for the solution to work is that the device where the mobile/desktop app is running has a fingerprint reader and is able to generate RSA asymmetric keys.
The solution will be provided using two different authentication trees (both which we include with our Midships ForgeRock Accelerator). The trees provide the following features:
· Device enrolment
· Device login
In order to provide a passwordless biometric experience to the user, it is required to first enrol the device under the user profile so that the footprint of the device and the user fingerprint are successfully recognized during the login process.
To do so, the following device enrolment tree is required:
The device enrollment tree will collect the following information from the application:
· Username & Password
· Unique Device footprint
· Public key
The collection of this parameters is done using the Input Collector authentication nodes that can be installed in your AM platform following the instructions provided in the official ForgeRock Git repository (https://github.com/ForgeRock/input-collector-auth-tree-node).
Page node is used in conjunction with the Input collector nodes so that all the information is collected from the same AM callback, reducing the crosstalk between the application and the AM platform. The tree also makes use of the Search for User node (https://github.com/ForgeRock/search-for-user-node), that will be used to search the provided username under the configured Data Store. When the user is found, we have setup so that AM will ask for the user password (the only time) before enrolling the device under the user profile with the Device registration node.
Many customers also opt to provide an additional OTP validation (SMS) at this point.
If we take a closer look to the device registration authentication node, we will see that some input configuration is required to be provided to the authentication node:
The configuration to be provided is used to limit the maximum number of devices that a user can enroll under his profile as well as some attribute names that will be used to collect the parameters that have been set to the shared state by the Input Collector nodes.
So, as we have observed, the process of enrolling a device to a user profile is relatively simple, since the application will only need to generate an Asymmetric keypair (keystore), send the device footprint, the public key generated and the user information (username+password). Note that the generation of the asymmetric keypair on the application needs to be authorized using the user fingerprint, so that the keypair generated is uniquely tied to the biometric data of the user (held by the O/S).
At this point, the user has successfully enrolled a device under his profile. After this if they need to login, all the user needs to provide is their fingerprint.
To provide the login functionality, the following tree is configured in AM:
The device login tree will collect the following information from the application after the user's fingerprint has been successfully authenticated by the O/S:
· Unique Device footprint
· Signed device footprint
Again, the collection of the parameters is done using a combination of Input Collector and a Page Node authentication nodes. The application will need to use the private key generated during the enrollment process to sign the device footprint data and send it to AM, along with the username and the raw device footprint data. Note the private key held in the keystore is ONLY available after the user has successfully authenticated against the local O/S.
In this case, and to uniquely identify the device and the user, as part of the login process, AM will first verify that the provided user exists in the configured Data store (making use of the Search for User node). If the user is found, then the Device login authentication node will verify if the incoming device footprint matches to any of the devices that have been stored in the user profile as part of the enrollment process and, also making use of the stored public key, it will verify if the signature of the signed device footprint is valid. If the signature is valid, then AM can be confident that the incoming login request has been originated by the same device and user that was used during the device enrollment process!
Note that algorithms and signing algorithms can be configured as part of the input parameters of the Device Login authentication node. Tests have been conducted using RSA as algorithm and SHA512withRSA as signing algorithm.
I hope this provides useful information for those struggling to provide a biometric experience to their customers and if you need further help please contact me...