ESET Secure Authentication SDK documentation
|
.NET SDK
The ESET Secure Authentication SDK allows two-factor authentication to be added to any system implemented using the .NET Framework.
This document describes how to use the SDK to provision a user for text message OTPs and how to authenticate OTPs. The document includes C# code snippets.
The entire SDK is encapsulated in a single .NET 3.5 library. The "ESET.SecureAuthentication.SDK" package must be installed from NuGet, which will manage the required dependencies. The "ESET.SecureAuthentication.SDK" library must be referenced in your Visual Studio project.
The SDK can be installed via NuGet as follows:
The TwoFactorAuthenticator class is the entry point into the SDK and is used to get users and authenticate OTPs for users.
The TwoFactorAuthenticator integrates with your existing user database via the IUserStorage interface. The two-factor user data will be stored in your database as a string for each user. Add this string as a new column called "esa_data" to your users table. You must implement the IUserStorage interface in order to instantiate the TwoFactorAuthenticator class. The following C# snippet gives an example of how to implement the interface:
The TwoFactorAuthenticator requires an instance of the TwoFactorConfiguration class. The TwoFactorConfiguration class requires your SDK credentials (API key and shared secret) and an instance of your implementation of IUserStorage (eg the CustomUserStorage class from the above snippet). The following C# snippet illustrates this:
The authenticator instance can now be used to provision and authenticate users.
Once a user is provisioned for text message OTPs, they will be sent an OTP via text message during each authentication attempt.
The username and mobile number are required to provision a user for text message OTPs.
Note: Mobile numbers must be in the format '42612345678', where '4' is the country code and '26' is the area code.
The following C# snippets details this:
The TwoFactorUser class implements IDisposable and must be disposed (such as in a "using" statement) after use for any changes to be persisted.
The authentication process consists of two steps.
The first step is the pre-authentication step. This step will send a text message OTP to the user:
The second step authenticates an OTP entered by the user. The result from this step will indicate if authentication succeeded or not. The following C# snippet details this:
The TwoFactorUser class exposes the following properties:
The TwoFactorUser class exposes the following methods:
Provisioning users for text message OTPs or mobile app OTPs increments your license's active user count.
Default configuration can be overridden by setting the following properties on the TwoFactorConfiguration class:
The pre-authenticate method returns a PreAuthenticateResult object. The result includes an ExpectedCredential property (of enum type CredentialTypes) that indicates the type of OTP that is to be expected.
The CredentialTypes enum has the following values:
This result can be used to customize OTP prompt text (such as telling the user to expect an OTP via text message).
A user can be enabled for both text message and mobile app OTPs. This state is known as "transitioning". This is done so that a user can be enabled for two-factor authentication without having to install the mobile app immediately.
When a user is in the transitioning state, the pre-authenticate step will still send a text message OTP. A transitioning user can authenticate using either a text message or a mobile app OTP. When a transitioning user authenticates using a mobile app OTP for the first time, they will be automatically transitioned to only being enabled for mobile app OTPs (i.e. they will no longer be enabled for text message OTPs). This is done because mobile app OTPs are preferred to text message OTPs.
The SDK uses Common.Logging for logging non-critical events. Common.Logging makes it easy to use your existing logging framework, see the Common.Logging website for more details: http://netcommon.sourceforge.net
The SDK audits critical security events using an auditor that can be overridden. The default configuration writes audit events to logging.
The default logging auditor can be overridden as follows: