Using the Password Reset Feature
Example Scenario
This example scenario for voice and chat is included to show how to authenticate users and update information in an ESM platform with the password reset workflow. This example uses Azure Cognitive Services for voice verification and ServiceNow for the ESM platform. The scenario steps are as follows:
- Setup
- User Identification
- User Verification
- PIN
- Single-Use Code
- Voice Verification
- Password Reset
- ESM Ticket Creation
- Troubleshooting
Downloadable Examples
Click the following links to download a chat or voice version of this scenario example.
Media:App_Password_Reset_-_ServiceNow_-_Chat.zip
Media:App_Password_Reset_-_ServiceNow_-_Voice.zip
Media:App_Password_Reset_-_Random_Phrase.zip
Note: The "Random Phrase" scenario is meant to be used with the "ServiceNow - Voice" scenario.
For instructions on how to import a scenario file into your contact center, see the Contact Center Administrator Guide, section Scenarios Overview > How to Export and Import Scenarios.
For general information about scenarios, refer to section Scenario Builder Overview.
Steps
1. Setup
Adding the variable assignment at the beginning of the scenario allows for easier modification when parameters change. The following is a description of how these are used in the scenario:
- PhoneNumber - Modification of the phone format for ServiceNow use
- contactTable - The table in ServiceNow that will be searched for a contact
- sttEndpoint - The Azure defined endpoint for Speech-to-Text services
- vvEndpoint - The Azure defined endpoint for voice verification
- functionURL - The Azure defined URL for the user Azure function
- Subkey - The subscription key for the Azure account accessed
- CodeLength - The length of the random, one-time-use code
- ServerURL - The URL of the server hosting the password reset service
- ServerPort - The port configured for password reset requests
- Domain - The domain name in use for the reset service
- Token - The token configured for password reset authentication
2. User Identification
This section of the scenario looks for the caller in the ServiceNow table by the phone number used. If the phone number is not automatically found, the caller is prompted to provide their registered phone number to proceed. Without this information, password reset does not continue in this scenario. It is important to locate the contact in the ESM prior to attempting authentication so that the appropriate username and password is supplied.
3. User Verification
PIN
For PIN verification, or any other ESM-stored information, the caller can be prompted to supply the needed information using their voice, or for numerical data the keypad can be used as well. If the information supplied matches what is stored in the ESM system, the user is verified and proceeds to the password reset phase.
Single-Use Code
When the user chooses to use a one-time code, the scenario will generate a random numerical sequence. The number of digits is specified by the CodeLength variable (see step 1). At this point, the user can choose to send this code to an email address or phone number on file. The user then reads the number or uses the DTMF dial pad to enter the code. If it matches, the user proceeds to the password reset phase.
Voice Verification
If voice verification is chosen, the scenario will look into the ESM database for an existing profile ID, which is used to recognize the caller in the speech recognition service. The information can be stored as a custom field with the contact information, or as in this case, a custom table mapping the user sys_id to the profile ID. If no profile ID exists, one is created. If the profile ID is invalid, a new ID is created and the ESM table is updated. This ensures that the verification process continues without additional effort from the service desk admin or caller.
Once the correct profile ID is used, the enrollment process is verified. Enrollments are voice patterns stored in the voice biometric service that are used for verification later. In this scenario, if the enrollment process is not completed, the user is instructed to provide enrollment recordings. This recording is encoded into a Base64 string, and sent to an Azure function that can decode it back into the original .WAV format. This is why the target URL is the Azure function created by the system admins, and the body of the request holds the endpoint for Azure voice biometric services. The profile ID, subscription key, and recording are also included in the body of the request. The Azure function will decode the recording string, and construct a request for user enrollment. The user has the option once enrollments are completed to either provide extra data or to continue with verification.
Once the caller is enrolled in the voice biometric system, the scenario will generate a random phrase to verify the voice pattern of the caller and protect against replay attacks. The scenario “Random Phrase” will generate a short, complex, but grammatically correct sentence for the user to repeat. The phrase is then sent to the Azure function for decoding again, and then to the Azure STT service. It is then evaluated on a word-by-word basis for pronunciation precision as well as phrase clarity and sentence completion.
Using a random phrase provides extra security to the verification process, as it ensures that only a specific phrase from the exact user will authenticate the password generation. If the phrase is spoken correctly, it is sent to the voice biometric service to verify against the enrollments previously collected. If this is a match, the user proceeds to the password reset phase.
4. Password Reset
If the caller has been properly verified through a PIN, random code, or voice biometrics, the scenario will request a new password for the user. The user ID is collected from the ESM table, and the expected token specified in the configuration is then used with the current timestamp to create a hash to authenticate with the password reset service. The hashed token will only be valid for a short period of time, disallowing reuse. The URL is set to the destination server with the specified port. The body of the request follows the format required. Additional data required for the external validation tool must be supplied as part of the JSON body in the request.
5. ESM Ticket Creation
If the new password is created, it is read to the user and sent to their email address on file. Additionally, an incident ticket is created, the form fields are filled out, and then the ticket is automatically closed, giving the IT support group a record of the automated operation. The caller can then return to the main menu for additional tasks, or end the call.
Troubleshooting
Events are kept in the Windows Event Log and accessed through the Event Viewer. Error codes are limited in information in the return body of the REST response for enhanced security. To troubleshoot issues with password reset requests, the required information can be found in the event viewer.
Successful password reset events will be logged with the information label and include the username of the user requesting the password. Unsuccessful attempts are logged as an error, and contain a description of the reason for the failed attempt. In the example above, the request did not contain a valid token.