4
votes

We are planning to deploy a BoT as a kind of help-desk to accept queries and raise support tickets based on the text from user. We want to integrate our BoT with our own AD for authentication. If AD authentication doesnt work then plan-B for us is say we host out BoT as a web chat BoT inside our webpage and all authentication is done at the web application. But still we need to capture the user logged into the web application when we want to raise some support tickets on his behalf. Any idea how logged in user details can be passed from the hosting web page to BoT. Hosting web page can be a Azure or On-premises implementation.

Is AuthBoT is the only way out for this using which user will be re-directed to a web application for login and with a magic code will be authenticated and sent back BoT. Do we have a seamless way of authentication with out redirection to another web page for authentication?

My client doesn't want to go to another web page and enter his credentials to get authenticated here. He wants a more seamless authentication. In a way he is right because he has already authenticated himself and logged into the web page and BoT is another snippet in his web-page. His point is why do we need to login again, why cant the BoT pick up authentication/token from hosted webpage. Any suggestions here?

1

1 Answers

4
votes

There are a few ways to go about resolving your situation.

So as I understand it, when the client arrives at the web page with the chat bot widget, the user has already authenticated with your website through a web page.

EDIT: I've added a 3rd method that is the preferred way of carrying out communication between a web page and embedded WebChat box.

Method 1:

One way to transfer the user's credentials (authentication token) to the chat bot within the page is to use the credentials from the authentication endpoint of your server to begin a new dialog with the user.

However, in order for this to work, you would need the IAddress of the user. In other words, the user would have had to have previously conversed with your bot, and you would have had to store it somewhere, maybe in a database.

For example, here would be your server code (this is in NodeJS):

//where user is sent after authenticating through web page
server.post("/authenticated", function(req, res){

    //get user iaddress from database using credentials
    //(you will need the Iaddress of the user to begin a dialog)
    var address = getAddressFromDB(req.body.credentials)

    //then use beginDialog to start a new dialog with the user you just authenticated
    //(this dialog route will only be accessible from here to guarantee authentication)
    bot.beginDialog(address, "/authenticated", { userAuthToken: auth_token });

    //success
    res.status(200);
    res.end();
});

//user is sent here from the above bot.beginDialog() call
bot.dialog("/authenticated", function(session, args){

    //extract credentials (auth token) from args
    var authToken = args.userAuthToken;

    //use auth token here.......
});

You would then carry out your normal logic to create and process support tickets at the bot dialog endpoint. You could even store authToken inside the session object if it is needed in later dialog routes. session.userData.authToken = authToken;

Method 2:

Another way you could authenticate your user is simply through the chat window itself via a waterfall dialog. However, this wouldn't really solve your problem of having the user authenticate twice, but it would solve the problem of the user having to leave the current web page to authenticate.

The bot would guide the user through the process of entering their credentials:

//begin user authentication here
bot.dialog("/get_username", [

        function(session){
                //prompt user for username here
                botbuilder.Prompts.text(session, "Hello, what is your username?");
        },
        function(session, results){
                //store username
                session.userData.username = results.response;
                //begin new dialogue
                session.beginDialog("/get_password");
        }
]);

bot.dialog("/get_password", [

        function(session){
                //prompt user for password here
                botbuilder.Prompts.text(session, "What is your password?");
        },
        function(session, results){
                //store password
                session.userData.password = results.response;
                //check credentials
                if(checkCredentials(session.userData.username, session.userData.password){
                    //good credentials, send to post-authentication dialog
                    session.beginDialog("/authenticated");
                } else {
                    //bad credentials
                    //reset user data and retry
                    session.userData.username = "";
                    session.userData.password = "";
                    session.beginDialog("/get_username");
                }
        }
]);

You can actually check out a working example of the above Method 2 code here.

Method 3:

The preferred way of having a web page communicate with an embedded WebChat bot is through the Direct Line REST API that allows you to create a "backchannel."

With the WebChat control (which you can download and learn about from the repo here), you can set up your embedded bot and the web page that houses it to communicate with each other by listening for and broadcasting events that you define.

You can see a great example of this by checking out this example code that shows the client side.

While this code demonstrates what the bot & server-side code is doing behind the scenes.

You could then use this method to have your bot listen for an authentication activity from your web page, and when the user authenticates, broadcast that activity with the desired credentials attached so that they can be used by your bot.

I hope this helps!