Skip to content
On this page

Authentication Methods

Email

Email response authentication is useful when you are using an email-based work flow with AlphaTrust® e-Sign. An email is sent to the designated email address (with follow up emails as configured). The email contains a transaction specific link. Anyone with access to this email could use the link. You can configure any Participant to receive the process access link email by setting the Participant's SendRequestViaEmail property to true.

csharp
participant = new ParticipantInsertModel()
              { 
                  FullName = "John Smith", 
                  EmailAddress = "testing@alphatrust.com", 
                  SendRequestViaEmail = true 
              }

PIN/Password

The Password authentication type allows you to assign a onetime PIN/Password to the participant's process access link. AlphaTrust® e-Sign will prompt the user for this PIN/password before allowing any viewing or signing of the documents. This PIN/password is specific to a participant in a particular transaction. The Email Response authentication may be combined with PIN/password authentication. PIN/Passwords for Participants in a transaction must be at least 4 characters and not more than 128 characters long. Any character is allowed except the space character and control codes (i.e. byte values below 0x20).

csharp
participant = new ParticipantInsertModel() 
              { 
                  FullName = "John Smith", 
                  EmailAddress = "testing@alphatrust.com", 
                  SendRequestViaEmail = true,
                  Authentication = new AuthenticationModel() 
                                   { 
                                       Type = AuthenticationModel.TypeEnum.Password,
                                       Data = "p@ssword123" 
                                   } 
              }

Mobile

Mobile authentication currently requires a Twilio account setup in our Integrations section. Enabling Mobile authentication will require a phone number during Transaction creation setup and will prompt the Participant to send themselves a text to the pre-configured phone number at which point they will need to enter the code sent in order to proceed further.

NameTypeDescription
CredentialNamestringUnique name of the third-party credential set up in the Control PanelUnique name of the third-party credential set up in the Control Panel
MobileSendToPhonestringPhone number to send the One-Time Passcode to. With, or without dashes.
UnmaskedPhoneCountnumber

Default: 4
How many unmasked digits of the users phone number are displayed to the user during the signing ceremony.
RawResultNoStore0 or 1Determines whether the raw result from the mobile authentication provider will be stored in the database.
MobilePasswordLengthnumber

Default: 4
For TwilioVerify and TwilioSms, this will determine the length of the One-Time Passcode sent to the user.
MobileSendTypesms or voice

Default: sms
Used for TwilioVerify to determine how the One Time Passcode will be delivered
MobileCountryCodenumber

Default: 1
Used by TwilioVerify to set the country code of the phone number used.
MobileLocalestring

Default: en
Used by TwilioVerify to specify the language of the message received by the user.
csharp
participant = new ParticipantInsertModel() 
              { 
                  FullName = "John Smith", 
                  EmailAddress = "testing@alphatrust.com", 
                  SendRequestViaEmail = true, 
                  Authentication = new AuthenticationModel() 
                                   { 
                                       Type = AuthenticationModel.TypeEnum.Mobile, 
                                       Data = "credentialname=myMobileCreds;mobilesendtophone=555-555-5555" 
                                   } 
              }

Registered User

RegisteredUser authentication can make use of a Registered User signature image uploaded to the user's profile within AlphaTrust® e-Sign. These profiles are created and maintained by a group administrator. They contain the user's name, email address, title, organization, and may optionally contain an image of the user's handwritten signature. If this image is present, it is used to visually represent the signature. This type of authentication is most often used by regular users of AlphaTrust® e-Sign, such as managers or executives. Email response authentication may be combined with RegisteredUser authentication.

csharp
participant = new ParticipantInsertModel() 
              { 
                  FullName = "John Smith",
                  EmailAddress = "john.smith@your-domain.com", 
                  SendRequestViaEmail = true, 
                  Authentication = new AuthenticationModel() 
                                   { 
                                       Type = AuthenticationModel.TypeEnum.RegisteredUser,
                                       Data = "johnsmith" //username goes here or leave blank for any valid user 
                                   } 
              }

Federation

Active Directory/LDAP claims-based authentication (SAML) - this type delegates authentication to a trusted authentication provider in an enterprise network. The trusted authentication provider is a Microsoft ADFS 3.0+ provider that will authenticate the user and return SAML claims to AlphaTrust® e-Sign for authorization to a transaction. Please see the AlphaTrust® e-Sign - Federation Setup Guide for details on configuring AlphaTrust® e-Sign for Federation authentication (SAML / ADFS 3.0+). This authentication type is only available for on-premise / in-stack deployments of AlphaTrust® e-Sign - not available in our SaaS service.

csharp
participant = new ParticipantInsertModel() 
              { 
                  FullName = "John Smith", 
                  EmailAddress = "john.smith@your-domain.com", 
                  SendRequestViaEmail = true,
                  Authentication = new AuthenticationModel() 
                                   { 
                                       Type = AuthenticationModel.TypeEnum.Federation,
                                       Data = @"yourdomain\johnsmith" //federated username goes here or leave blank for any valid user 
                                   } 
              }

Knowledge-Based (KBA)

Knowledge-based authentication, commonly referred to as KBA, is a method of authentication which seeks to prove the identity of someone accessing a service such as a financial institution or website. As the name suggests, KBA requires the knowledge of private information of the individual to prove that the person providing the identity information is the owner of the identity. There are two types of KBA: static KBA, which is based on a pre-agreed set of shared secrets, and dynamic KBA, which is based on questions generated from a wider base of personal information. KBA authentication through AlphaTrust providers utilize dynamic KBA.

KBA Provider Options

Experian’s Knowledge IQ℠ powered by Precise ID℠ is a revolutionary knowledge-based authentication tool for identity authentication and fraud prevention. Precise ID℠ scoring models and Knowledge IQ℠ interactive challenge-response questions provide innovative and integrated identity authentication and fraud detection on a single platform. By combining the leading-edge analytics and decisioning technology of Precise ID℠ scores with the sophisticated Knowledge IQ℠ challenge-response authentication questions, you have a comprehensive risk-management and identity authentication system. You must have an account set up with Experian prior to utilizing this authentication method.

LexisNexis Risk Solutions™ offers an Authentication product used to quickly verify identities and create multi-layered authentication approaches for better fraud control, and a better customer experience. You must have an account set up with LexisNexis prior to utilizing this authentication method.

Control Panel Configuration

Login to the AlphaTrust® e-Sign Control Panel using an account with Administrative permissions and select Credential Administration. Add a new Credential and select either LexisNexis or ExperianPreciseID. Type a unique Credential Name and remember this value (it will be used later) and complete all fields; click Insert.

API Configuration

There is an Authentication property on the Participant object. Create a new Authentication object and set the property [Type] to Authentication.Types.Kba.

There is also a property on the Authentication object called Data. This accepts a semi-colon delimited string value. Below are the acceptable values: Bold indicates required

NameTypeDescription
credentialnamestringUnique name of the third-party credential set up in the Control Panel
idphone0 or 1Asks for phone number
iddob0 or 1Asks for Data of Birth
idssn90 or 1Asks for SSN9
idssn40 or 1Asks for SSN4
rawresultnostore0 or 1Only applicable to LexisNexis. Determines whether the raw result from LN will be stored in the database. Has PII information.
continueonfail0 or 1Only applicable to LexisNexis. Continue on Fail must also be enabled in the Group within the Control Panel. This feature enables the signing user to continue the signing process when the authentication questions are answered incorrect, or if there is not enough data to correctly identify the user.
bypassinwalletn, y,
or x
Only applicable to LexisNexis. Determines if the In-Wallet form is displayed to the signer. N=Do not bypass; it will show, Y=Bypass for the first attempt, but if there are errors process, it will show, X=Always bypass and never show.
showoptin0 or 1Only applicable to LexisNexis. Determines if the In-Wallet form is displayed to the signer. 1=Always shows, 0=Never shows.
allowedattemptsnumberNumber of attempts a participant has complete before being sent to the access denied screen
datafirstnamestringPre-populates form with data supplied
datalastnamestringPre-populates form with data supplied
datamiddlenamestringPre-populates form with data supplied
datacurrentstreetstringPre-populates form with data supplied
datacurrentcitystringPre-populates form with data supplied
datacurrentstatestringPre-populates form with data supplied
datacurrentzipcodestringPre-populates form with data supplied
datatelephonenumberstringPre-populates form with data supplied
datasocialsecurity#########Pre-populates form with data supplied
datamonthofbirth##Pre-populates form with data supplied
datadayofbirth##Pre-populates form with data supplied
datayearofbirth####Pre-populates form with data supplied

Matching user-entered data with your own system's records

To match data, simply swap out the word “data” for the word “match” in any of the items above. Example: matchmonthofbirth=## or matchsocialsecurity=#########

Button Customization

You can also customize the button text using the following:

  • button-positive-1=I Agree
  • button-negative-1=Exit
  • button-positive-2=Submit My Information
  • button-negative-2=Cancel
  • button-positive-3=Verify My Identity
  • button-negative-3=Cancel
  • “positive” is the yes/submit/continue type button on the page
  • “negative” is the no/exit/cancel type button on the page

Legacy Experian PreciseID

If you were using Experian PreciseID Authentication prior to version 4.31.0.0, then during the upgrade process we upgraded the storage of your Experian credentials to our new Credential Administration. You can edit this information, but please note that if you update the Credential Name, it will require you to update your API calls to conform to the KBA Authentication format above.

HTTP Header Check

The HTTP Header Check functionality allows you to authenticate a Participant via your own web application policy-based or single sign-on authentication provider. You can define HTTP header values that are required and even check for specific user ID values. Any or all of these values can also be included in the document's Audit Report.

The HTTP Header Check is not yet a true Authentication Type so in order to use it, you need to add it to the Participant object as a Workflow Action. Make sure to set the IsPreAuthentication=true so that it checks the headers from your authentication provider prior to AlphaTrust® e-Sign setting its authentication cookie.

csharp
participant = new ParticipantInsertModel()
              {
                  FullName = "John Smith",
                  EmailAddress = "john.smith@your-domain.com",
                  SendRequestViaEmail = true,
                  WorkflowActions = new List<object>
                                    {
                                        new ParticipantActionModel()
                                        {
                                            Description = "Siteminder Authentication", //Shows in Audit Report
                                            IsPreAuthentication = true, //ensures the check happens before it sets the authentication cookie
                                            Data = "UserIdHeaderName=MyIdHeaderName;UserIdHeaderValue=MyIdValue;AuditHeaders=headertocheck1,headertocheck2,etc."
                                        }
                                    }
              }