Authenticating the identity of a user through digital messaging channels
|Description||Authenticate the identity of a customer being serviced via a digital messaging channel.|
|Version as of||8.5|
|Capability/Industry Area||Conversational Channels|
You often need to authenticate the identity of a customer being serviced via a digital messaging channel. Protecting our clients' customer information is vital if it is to be utilized in any self-service capacity, such as service provided by bots.
Use case overview
Below is the summary of how such a typical operation through a messaging bot would be handled (see the image to the right):
- Customer asks for access to sensitive data (cases or responses that have been marked as "Requires authentication").
- Bot responds with a URL to our client's branded Authentication page.
- This will be rendered as either a link or a button depending on the channel's presentation treatment capabilities.
- The URL contains an encoded callback URL which contains a unique session token.
- The visitor is presents with the Brand's Login page and upon successfully logging in, that system invokes the callback URL.
- The POST method is used with an identifier for the user as the request payload.
- The assigned token is how the service reconciles which messaging channel user session is associated with this ID.
- The Bot channel now responds to the customer's initial request with the sensitive data.
Before you begin with authentication
You should have a BotAgent Channel configured with at least one Integration (Figure 1). This "bot" should also have at least a couple of responses configured, and you should be able to readily , successfully get those responses using the current NLP models or keywords associated with the channel. For details configuring channels, see the creating-web-chatbot-channel article on Pega Community.
Parts of authentication
Configure at least one of your responses to require authentication (Figure 2), and update your channel's Authentication URL to the page that will be responsible for handling the customer's login (Figure 3).
Upon a user successfully logging in, the Authentication server must generate an HTTP Request using the POST method, back to your Pega instance in which the bot is running, by using the ack query string parameter. The payload of this post will be JSON and contain something like one of the following:
|Least secure, as it is the easiest to guess a useful value using a brute force attack. Also requires that searches for a contact using their email address are reliable.|
|Using the Primary Key for the Contact objects (pxInsName) mitigates the resolution issues around ambiguity.|
|Most secure, as no identity is actually communicated in the affirmative response for the session. Instead, this one time GUID would be resolved with a subsequent REST lookup against the auth server.|
- The pyVerifyUser Activity Extension point is called as part of the botAgentAuthentication service. This gives the integrator a place to validate the userId value in the payload. Specifically reconcile it against a configured contact or format, or fetch the corresponding value associated with a ONE_TIME_GUID_TO_RESOLVE.
- pyOnAuthenticationSuccess is the second extension point related to authentication and is invoked a little further down in the processing flow. This is where you should fetch all the Application related context around the authenticated userId. For example if the userId is an email address that needs to be resolved through search, this would be the right place to do so. Upon running this activity, the Interaction .Contact and perhaps .Account embedded pages should be populated so that the IVA can fulfill inquiries against the customer's particular data (such as account balance or payment due date).
Once you have successfully challenged the user to authenticate, your channel should be able to provide responses that refer to the specific values associated with this Contact, and their related configured Accounts.