We have a client requirement in that Bot application should be hosted in On- premises and all the web chat communication directly go the web server. I am planning to develop a Bot .Net application and configure with web chat Channel. I would like to know if it is possible to configure the Bot application On- premises
How can I setup the web chat On- premises?
How can I skip the Bot Registration and avoid message routing?
Do I have to build a service to handle all the request and response in the web server?
If I am using webchat how the client data is secure and how the bot service is routing the request to Webapp?
If I am using webchat how the client data is secure and how the bot service is routing the request to Webapp.
Ok. So lets break down the problem.
What you want to do is isolate your bot from any and all communication that it has with Microsoft Bot Connector/Framework.
First understand what are components are involved within Microsoft Bot Framework Ecosystem.
Understanding Bot Framework Ecosystem
Typically a vanilla bot would interact with 3 Microsoft services -
Microsoft Bot Connector: This guy here is the heart of Bot Framework. It has critical job(apart from other unimportant things(security!)) of Message Routing, Session tracking and channel adaptation.
Microsoft Bot State Service: This service is used to store Conversation (and custom) state.
Microsoft Account (MSA) server: The Bot Connector service uses OAuth 2.0 client credentials for bot authentication. MSA server issues these JWT access token.
Now to create an on-premise bot you would need to replace/mock all the above components. Luckily Bot Builder SDK is open source and well designed. The implementations of interacting with above services is interface driven and easy to change.
Understanding and Modifying Bot Builder SDK to create an On-Premise Bot
Since our aim is to not use any Microsoft Service, we would not be needing MSA server to generate token. So no bot registration required.
The most easiest of the services to replace is Bot State Service. All you need to do is implement IBotDataStore or IBotState interface. So instead of storing state in Bot State Service, for instance you could store it into your own Redis DB. I wrote a blog post on how to do this.
What left is now to replace Bot Connector. This is tricky and not straight forward. Plus it is not open source so you are on your own here. As mentioned above, first important piece is Channel Adaptation. Since you mentioned you only need Web Chat channel, there is not much to adapt(duh?!). The second important thing it does is Session tracking, which relies on different IDs that are generated specially Conversation ID and Activity ID. You must understand what they represent. Conversation IDs are generally created and modified by Channel.
Here you must make a choice on how to create the conversation ID. Web chat by default has transient conversation IDs. You may choose to make it more perpetual (one way is to require user to sign in and use userid).
Message Routing works differently in Web Chat Channel since there is no one specific endpoint that Bot Connector has to call(like Facebook Graph API). So Web Chat channel make use of Direct Line APIs to send message and polls(or use socket) a specific endpoint to receive message. Web Chat channel is open source, go ahead and checkout how they do it.
So to fully replace the Bot Connector API you need to create your own connector service which
Accepts requests from Web Chat channel.
Adapt it and forwards the request to bot
Accept response from bot (we will get to how to do this)
Maintain the response in some persistent store. Needed because the user may have closed the web page, so you may need to deliver it when he comes back.
Return the response to web chat channel on the next poll(or use socket).
Granted this is not trivial, but you can take some design decisions that can make life a little easier. Such as doing away with adapter and keep a single schema for communication from web chat control to the bot and back (but then you will need to change Web Chat Channel code). For starters you may even look at BotFramework Emulator code which simulates the Direct Line API.
Now how to get your bot to send replies to your own connector service? To do this you need to implement IBotToUser interface. This is fairly easy to do. Have a look at my repo where I return the response to Skype For Business client instead of Bot Connector.
This is it I believe. If you can get the above done, you can have a completely isolated bot with no connection made to cloud. For security you may have your own OAuth provider(I recommend IdentityServer) or make user signin before using bot. I cannot answer security detail unless I get more overview of your application ecosystem and usecase.
The conversation data(and state) can be made to be stored in your on-premise database fairly easy. In my opinion, if you can go ahead using Bot Connector and only replace Bot state service it would be best(you can also keep on receiving new features from Bot Framework without having to change any code).
All the above information is from my own experience on working with Bot Framework. If anyone has a better suggestion please feel free to share them and I will make the edits.
Related
I've been trying out to create skills for Cortana and would like to hook it up to a .NET Core web API that I made. This web API already contains implementations for Google Home and Alexa and I would like to add Cortana communication to this web API.
Currently I've looked into the examples on the microsoft website and played around with them. The examples give me a .zip file with a pre-generated project which handles the requests, I would like to use my own web API for this.
When publishing apps in LUIS I found some info on endpoints under the Keys and Endpoint settings, but it doesn't seem to be a kind of endpoint that I'm looking for.
Is it possible to use personal Web API's to handle intent behavior similar to Dialogflow
webhooks or Alexa Endpoints for Cortana bots?
Any links or other references would be very helpful.
Thanks in advance!
Using a Bot Channels Registration, a Cortana connected skill will make POST calls to the configured Messaging Endpoint:
All Bot Framework services use industry-standard REST and JSON over HTTPS and communicate with messages based on the Bot Framework -- Activity schema. With the Cortana channel, when a POST is received at the Messaging Endpoint the code must acknowledge the call (HttpStatus 200) and send return messages within 10 seconds (serviceUrl is the base url for the destination). Your code can call into whatever other services or apis you require during that time.
The Bot Builder SDK helps enable more easily communicating with Bot Framework services, including the Cortana Connector Services.
I'm trying to build a bot that would integrate with a REST API. To be more specific, the bot should log into the API, based on credentials provided by the user. Based on certain questions that is asked by the user, the bot should then perform certain actions against the API and report with the results. Something like, 'hey mr. bot, I would like to know my latest sales figures' or 'submit my outstanding events'. The API uses forms authentication, thus after login, the bot would need to send the cookie to the API, otherwise a response of 401 (from API).
Is something like this possible?
[Update]
Since it's unclear as to what I'm asking (down vote), I'll extend my question. I would like to know whether the bot would be able to pass the cookie required by the API to and from the client it's communicating with. Otherwise, with each request to the API, from the bot, the API will see the request as one that is not authorized.
Thanks!
I'm not fully sure if this is going to work with cookies. Maybe in the WebChat channel, because of the nature of the channel, may work just fine.
A common pattern I've seen working pretty good with bots is communicating through APIs via OAuth. A good way to implement this is: you send to the user in the bot a link to log in, then the reply will callback to your API where you will basically resume the authentication with the bot and store the access token in the bot state; so you can reuse it on every call.
Since you are using C#, I would recommend checking AuthBot ( is a .Net library for Azure Active Directory authentication on bots built via Microsoft Bot Framework).
Also, you can check AzureBot to see how the Auth library is being used.
I am a beginner in .NET, and I write a simple social network. What would be better: WCF or ASP.NET 5 WEB API to create a service? And another problem: how to make two-way communication between the service and client (when user1 sends a message to user2, user2's message box has to change)? As far as I know, in WCF CallbackContract can be used, and how to do it in WEB API?
I will be very grateful for an answer :)
I would recommend WCF's inbuilt capability if you want 2 way communication.
But from the scenario you have given you are talking about end users and not clients, today you want to send message to user 2, tommorrow it could be user3,user4 and so on.
So if you just want to collect some input from one of the end user through whatever means you prefer and broadcast to set of users you should user SignalR.
My Google-foo is failing me here... most likely a terminology thing.
Basically, I'm making a desktop (and likely mobile) application that connects to a REST API that returns JSON. I've created a C# class library that handles the the data querying in my local project however this would expose my API key if I were to publish it.
I would like to know what are the appropriate options for simply running a small service in Azure that takes a web request, queries the API and passes the JSON response back. Something lightweight, decently scalable.
Is this something a web role or worker role is good for? Is this something I really should learn Node.js for?
I asked a similar question a few years back: Keeping a secret key secret with Amazon Web Services
One reasonable solution is to build a simple service that returns the headers and url to use when communicating with the authenticated service. Your API key remains secret because it only lives in your service, but the clients can leverage the API key by getting the encrypted request from your service and then making the request for the actual work.
I haven't personally looked into the Azure API App Service, but a brief browse of the main website suggests that it, too, may be relevant to your interests. :)
Check out Azure Mobile Apps. Azure Mobile Apps is a "backend as a service" platform. With Mobile Apps you can easily store information into a SQL Database and expose custom API methods. It is a great place to start and has SDKs for connecting iOS, Andriod, Xamarin, and HTML apps.
As for security, the Mobile service has options to protect the data from allow anonymous access to requiring each user to authenticate.
I followed this Microsoft Azure Mobile Service Authentication Tutorial, to try to add a server authentication function for my Windows Store C# app. However, after completing every step, when I run my app, it showed that the application cannot connect to the service.
I found this useful blog tallking about troubleshooting Azure Authentication issues in Azure Mobile Service. To troubleshoot, I type the link in the firefox web browser: myServiceUrl/login/aad, but I receive the error response:
Authorization has been denied for this request.
I also followed the same tutorial to test with Google Log in. It turns out to work properly. And when I type the link: myServiceUrl/login/google, the web browser directed me to the google log in page, unlike the Unauthorization error message when I type in myServiceUrl/login/aad.
Although google log in works out fine, but it is desired for us to use Azure Active Directory authentication. Could anyone tell us what could possibly be wrong? Any troubleshooting suggestions are also appreciated. Thank you.
The "Application cannot connect to the service" error comes from whenever the Web Authentication Broker in Windows receives an error response from the resource it is trying to reach. There are a couple of issues that can cause this, and I'll try and address the most common ones.
I noticed the tutorial you linked to is for the .NET backend. If you are using the Mobile Services .NET backend, there is an extra step required to configure the AAD server flow, and it's a common cause of the issue being described. In the tutorial, it's under the title "Configure your .NET mobile service for AAD login." On the backend project, you will need to install the Mobile Services .NET Backend Security Extension NuGet package. Then, in WebApiConfig.cs, you will need to include
options.LoginProviders.Remove(typeof(AzureActiveDirectoryLoginProvider));
options.LoginProviders.Add(typeof(AzureActiveDirectoryExtendedLoginProvider));
This allows the runtime to use the server flow in addition to the client flow (leveraging the Active Directory Authentication Library) which was first released with the .NET backend.
Pending that, or in the case of the Node runtime, the next thing to do is check the AAD configuration. In the AAD portal, make sure that your application registration uses your mobile service's /login/aad endpoint for the resource URI. It must match exactly the value provided in the Mobile Services portal. This should also be one of the redirect URIs if you are using the Node backend. For .NET, you would use the /signin-aad endpoint for the redirect URI instead.
You should also check that you have copied the Client ID from the AAD registration and pasted it into the Mobile Services portal's Identity Tab. For completeness, the "Allowed Tenants" field should also be filled out, but I don't believe it is the cause of this issue.
Lastly, if your AAD tenant is federated with ADFS, then there is a wide range of issues that could lead to this. The biggest case comes from the WAB needing to be configured for Enterprise Authentication. This typically only causes problems when the device is domain joined / on the corporate network. That behavior is a known bug for the Mobile Services Windows Store SDK, but there is a workaround available. Glad to provide that if needed.