Introduction
A commonly used authentication method that can be used as a factor of the type "something you have" is authenticating using one-time passwords (OTP). This type of authentication method is added to the authentication options available during authentication by adding the method "One-Time Password" to the logon procedure.
There are three requirements for using One-Time Password authentication in DualShield;
- A suitable OTP token needs to have been assigned to the authenticating user's account (either time based or event based).
- The authentication method "one-time password" must have been added to the logon procedure of the protected application.
- The user must have received a copy of the token that was sent to them (either by email or SMS) so that it can either be added to an authentication app or programmed onto a programmable token.
DualShield supports the following possible authentication products that can produce one-time passwords;
- MobileID Time/Based tokens
- MobileID Event/Based tokens
- Google Authentiicator Time/Based tokens
- Google Authenticator Event/Basesd tokens
- Microsoft Authenticator Time/Based tokens
- SafeID hardware token
This guide explains how to use Google Authenticator Time/Based tokens, however if a user is logging in to a protected application and has any of the other OTP tokens assigned to them, then they can supply an OTP code from any of the alternative sources.
Policy Setting Options
Before we create and assign the Google Authenticator Tokens to users we should first select the product's policy settings;
From the Management Console navigate to "Administrator | Policies", select the category "GoogleAuthenticator/Time-Based", then click  ; 
A new window will open titled "Policy - Edit", please use the following policy settings; Policy Setting | Set the settings to the following |
|---|
Token Provisioning | "Manual" | Client Provisioning | "Manual" | Token Activation | "Automatically activate the token when created or assigned" | Authorisation | "Authorisation Code not required" | Authentication | "Authentication not required" |
Adding the authentication method to a protected applicationFor the purposes of testing we will protect the password reset portal using a Google Authenticator token (however this can easily be adapted to other applications). From the Management Console, navigate to "Authentication | Logon Procedures" , and use the context menu of the logon procedure that will be protected with Google Authenticator tokens (via OTP), and select "Logon Steps"; 
In order to be able to use Google Authenticator tokens during authentication of a protected application we should include the authentication method "One-Time Password" in our logon steps. For this test we will just use a single step (with this method as the only authentication method being used in the step); 
Using the context menu option "Applications", we must ensure that only the application "Reset Password Service" is selected. If we now navigate to "Authentication | Realms", and from the context menu of the realm "Reset Password Service", select the context menu option "Domains", then ensure that the domain "Management Console" is selected; 
|
|
For a full list of options available to the policy settings available used by Google Authenticator tokens see the following wiki guide;
Creating and Assigning Google Authenticator Tokens
Once you have set the token policy options you are ready to create and assign the tokens to users.
If you are the system administrator, and you want to test this authentication solution prior to deployment to your users, then a good solution would be to create a test account (with an email address) in the management console domain, and then use this account to test that OTP authentication is operating properly prior to deploying the solution to your users.
The following procedure will create an account that can be used for testing google authenticator tokens, and will also demonstrate how google authenticator tokens can be assigned to this account;
From the management console, navigate to "Directory | Users", select the domain "Management Console" and click "SEARCH"; 
For the purposes of testing this solution we will now create a new user "GA Test" in this domain. To create the user account click  button (found at the top right of the page). A new window will now open titled "User Info - Domain (Management Console) - New", fill in the Login Name of "GA Test", and supply a password to be used for this test account; 
Now provide any name details for the "First Name" and "Last Name" fields, an email address that tokens details will be sent to (when testing), then click  to create the account. 
The user account will now have been added to the list of management console users (we have not assigned any role permissions so any test logins to the management console using this account will no have admin privileges). Left click on the context menu of this user and select the option "Tokens"; 
Now user the  button to create and assign a new token; 
A new window titled "Token - New" will now open, at the prompt "Product/Model" select "GoogleAutheticator/Time-Based" then click  ; 
You will now have created and assigned the token to the newly created user account; 
|
|
Preparing a test application
In order to test our newly assigned token we will need to prepare the Google Authenticator policy settings, then Create an application that is OTP protected that can be used to test the token.
From the Management Console, navigate to "Authentication | Logon Procedures" , and use the context menu of the logon procedure that will be protected with Google Authenticator tokens (via OTP), and select "Logon Steps";
In order to be able to use Google Authenticator tokens during authentication of a protected application we need to include the authentication method "One-Time Password" in our logon steps. For this test we will just use one step with this method as the only authentication method used by the step;
Using the context menu option "Applications" we can also ensure that only the application "Reset Password Service" is selected. If we now navigate to "Authentication | Realms", and from the context menu of the realm "Reset Password Service", select "Domains", and ensure that the Domains "Management Console" is selected;
|
|
Testing OTP access using the Goggle Authenticator Token
Now that we have a test application that is protected with OTP authentication, we will open a new incognito window and test logging in to our OTP protected application.
At the protected application we supply the name of our test user ("GA Test") and will then be prompted to enter our OTP code; 
If we now switch back to our management console window and navigate back to our list of tokens assigned to the newly created user, we can use the context menu option "Display OTP"; 
A new window titled "Token Current OTP" will now open, click on the  button to copy this code to you clipboard; 
Now switch back to your test logon screen, and at the OTP prompt paste in the code, and you will be granted access to the protected application.
|
Testing if the server clock needs correcting
QR codes are an efficient method of sending token data to users but before we test this process it is worth checking that the authentication server's clock has been set correctly (if this is not the case then the OTP codes generated by the server will not match those produced by the client).
Whilst a simple comparison of the date and time produced by the authentication server with internet time may prove a good indication that the clock on the server is accurate, a better overall test is to compare OTP codes generated by the system with an independent source that is using the same seed data. To perform this test using a google authenticator seed you will first need navigate to the user and token in question, then use the context menu option "Display Credential Seed"; 
A new window titled "Credential Seed" will now open that displays the base32 encoded seed for this token; 
Make a copy of this seed then open a new incognito window at the URL: https://totp.danhersam.com/ At the prompt "YOUR SECRET KEY" paste in your Credential Seed, and the page will display 6 Digit OTP codes every 30 seconds (that are generated using your credential seed); Organise your windows so that this rolling OTP display is visible whilst you access the management console, then against the token you obtained the seed from use the context menu option "Display OTP"; 
You should find that both sources are producing the same 6 digit OTP code 
If the codes do not much you may need to correct the clock on your authentication server. |
The following procedure can be used to correct the clock on your authentication server;
From the Date & Time settings window 
Correct the clock against internet time then click "OK" Repeat the OTP test performed earlier, and the two OTP codes should now match. |
|
Pushing QR Codes
To test sending the QR code by email you will need to perform some additional preparations.
Before we can push QR codes to users we need to ensure that the template for pushed tokens is updated. After entering the recipient email address save your changes then navigate to "Customisation | Message Templates", at the prompt "Names:", select "Push Token", then click .
Left click on the context menu for the channel "SMTP" and select "Edit"; 
A new window titled "Push Token" will now open, at the prompt "Text:" add the text "[[QRCODE]]", at the prompt "Format:" select "HTML Format", then click  ; 
By making this change you will be ensuring that when a token is pushed to the user a QR code is included in the email. You can now test pushing a QR code to the administrator by navigating back to the administrator's token list and using the context menu option "Push Token By Email"; 
After the token has been pushed you should see a confirmation the email has been sent; 
At the recipient email address an email will then arrive with a download link and a QR Code; 
The recipient will then use the scan feature of their Google Authenticator compatible app to add the token and start generating OTP codes. The QR Code can be used either by scanning the token into a Google Authenticator App, or by using the code to program a programmable hardware token; |
|
Provision and deploy tokens to users
There are several methods that may be used to provision a token to the user;
User Experience
Once tokens have been deployed to the user, and they have been added to their authentication devices (desktop pc app, smartphone or programmable hardware token), the user is ready to use their authentication device during the logon process of a protected application.
For testing with users that are members of an external directory, you will need to ensure that the domain that they are members of, is included in the realm that the protected application is assigned to (in the following example we added the domain "pb.deepnetid.com" to the realm for the reset password service).
The user would first attempt to access the protected application by accessing the logon portal, then after supplying their username the user is prompted to enter their One-Time Password;
The user would then launch their Authentication App (or press the power button on their hardware token) and copy the 6 digit code into the logon screen, click "Verify", and they will be granted access to the protected service.
Related Articles