security of app service for bot built for Teams - botframework

I am building a bot for Teams so that users can get information of my backend service. To achieve that, I need build an app service as a middle layer to connect teams and my backend service. In such a case, I am wondering how to make my middle layer app service more secure such that nobody can call the app service except the messages from Teams. Or is it not necessary to consider such protection?
Teams ----> middle layer APP ---> backend service

Posting the Answer for better knowledge
Copying from #RajeeshMenoth comments
You can allow only ms team users by AD privilege's through grahp api and middle layer is look like your bot app and their you need to write your logic.

Related

How can I create a custom screen in the messaging section in Microsoft Teams add-on

I don't want to use bot framework in pop-up or chat window.
Can I use the web API I created myself.
When I do a call, I want the api to request it to list the returned data.
Can I select multiple data listed?
From your description you seem to want to create a Teams Message extention, specifically a search extention that will be used from the compose box.
this is indeed powered by a webservice that you will write and host,
however the communication channel between Teams and your webservice must use the bot framework for communication.
Note that you do not need to write a chatbot as such;
I like to think of it as the 'communication channel' between all the Teams clients that have your app installed , and your webservice.
High level steps:
Create and deploy your web service (while developing use a tunneling
service like ngrok to run it locally)
Register your web service with
the Bot Framework
Create your Teams app package
Install your App into Teams
More steps and details in the messaging extensions documentation

Is it possible to create a custom app for Microsoft Teams that dosn't use a central service provider?

I am working on adding support for our cloud storage solution to MS Teams but there is no central server you can send http messages to and get meaningful relies back from. I have no experience with creating Teams apps so I was hoping someone with Teams apps experience could tell me if this is even possible. At this point I only need my app to work on Windows and OS X.
This is how I would like my Teams App to work:
Each member of the team already has our cloud storage app running locally on their machine which provides access to the files.
Within MS Teams the user adds a file reference to a message via a message extension that would result in a link unfurl creating a card that contains an 'Open' button. The URL in the card would be one generated by our locally running cloud storage app. Other members of the team could then open this file by clicking the 'Open' button. The action of the open button would be to send the URL to our cloud storage app that would then open the local copy of the file on that team members machine.
Is it possible to do something like this within a Teams app? The communication between the Teams app and our cloud storage app would be done over our own protocol.
If it weren't for the fact that all bot communication must be done over https rather than http the local cloud storage app could act as the server.
All the communication in Teams with 3P apps needs to happen over https public endpoint. You could use ngrok to tunnel to local.

Can we build a product which enables end user to create conversational chat bot using bot framework on a self hosted environment?

I want to develop a product which simplifies the way of creating conversational chat bots using Microsoft BotFramework SDK. As we can build and host web application on-premise completely.
So can we build the similar thing using bot framework on a self hosted environment?
Here is the link for Microsoft Bot Framework: https://dev.botframework.com/
You can, indeed, build a bot entirely on-premises/self-hosted, provided that you don't need to connect to a Channel like Teams.
Background
Basically, bots communicate via:
User interaction with DirectLine Client (like Web Chat) ->
DirectLine API receives data and sends to bot ->
Bot hosted anywhere receives message
Note:
WebChat is just a DirectLine client. If you want to build your own WebChat, you can clone the repo and build it yourself. However, that all this does is make it so you can host your own webchat.js file, if you really want to be self-hosted.
Steps
With that in mind, all you need is:
A Direct Line client like Web Chat (specify domain property with your own endpoint when you call createDirectLine), or you can write your own client
You own DirectLine API implementation like offline-directline (more info)
Host your bot somewhere
Security
With this approach, you won't be able to use the typical appId/password setup.
You can manually implement our security protocol by following this document
Even though it is possible to manually implement the security protocol, we recommend reusing our existing open-source libraries
Based on answers, putting a more complete answer here. Since the option exists to have internet connectivity, I'd definitely suggest creating the solution as a "regular" Bot Framework bot, using the Azure Bot registration. Importantly, there are TWO options to do this - the most obvious one creates a "registration" for the bot but ALSO defaults to hosting it in an Azure Web App, which has a cost associated that can be quite significant. HOWEVER, there's another option, to create just a "Bot Channel" registration, which means you get a bot registered in Azure, but not necessarily hosted in Azure.
I've described this more in this post and you want to use the "Bot Channels Registration" in Azure, not the "Web App Bot". Then, on the "settings" screen you can define what the bot's actual address is (see here for a view of the Settings screen).
So, overall that should help - basically the bot just needs to have an HTTPS, internet-accessible endpoint. HOWEVER, that said, it's possible to host your bots inside Azure Functions, rather than Azure Web Apps, and the cost is dramatically cheaper (cents vs dollars, especially with low traffic). It's a bit of work, especially as the default samples default to the more standard options, but it works quite well.
I've recently launched a new blog, by the way, and I've got a post describing some of what I've learned so far about how bots work, that would be good to know as part of this. See How Bot Calls Actually Work.
We're in the process of migrating from an entirely on-premise solution with our own DirectLine server to Azure Bot Channels Registration because of the requirement for MS Teams integration.

Scale out Microsoft bot framework app in multi region environment

I am setting up the MS Bot framework service environment in Azure. I was able to successfully set up the channel which connects to single bot service for a single app. Now, we would like to scale this environment globally (all over the world) and we would like to setup multi-region environments. When a user connects from the channel app (MS Team) then they should be able to connect to their nearest Azure region and get the response back. How can we set up the geographic load balancer for Microsoft bot framework web app bot service?
We tried to set up the traffic manager however we have constraint since Microsoft bot channel registration service has Microsoft APP ID (ClientID) and Password and it can only connect to only one messaging endpoint URL
Actual results:
Microsoft Bot channel registration app cannot connect to more than one messaging endpoints of the different region and how can we load balance MS Bot Service.
Expected results:
How can we load balance (latency by region) MS Bot Application?
Sample Scale out diagram
Amit,
Azure bots typically run as Azure App Services. The Azure App Service has built in scaling capabilities. Depending on the pricing tier you select for the App Service, you can scale out to as many as 20 instances. You can go to 100 instances if you're in an 'Isolated' tier. You can also scale up to add memory and cpu. That's some really powerful resources you can bring it to.
I realize that you're trying to reduce latency but I wanted to point the scaling feature out first. You have another challenge I don't think if possible to overcome at this time.
If MS Teams is the only channel you're users will be using, then trying to manage traffic on your own is probably going to be ineffective. You're constraint is going to be where the MS Teams service is located. Teams is what's talking to your bot, not the user directly.
The path is something like this:
User -> MS Teams -> Azure Bot Service -> Azure App Service.
Since you have no control over the Teams to Bot connection, you cant manage the traffic.
You could deploy multiple bots to different regions, then instruct your users to connect to the appropriate regional bot channel in Teams. This isn't an automatic traffic management but would at least provide some of the region support you're looking for.

The benefits of hosting a bot on Azure Bot Service compare to hosting a bot on a typical Web App hosting

A bot is essentially a web API and so it can be hosted on any web service.
I am abit confused when one of the following approaches should be prefered over each other:
Option #1 Host a Bot on Azure Bot Service
Option #2 Host a bot as a plain PaaS Web API
Currently I am hosting my bot on a plain Azure PaaS App Services. It is working very well.
However, I expect there must be some advantages to hosting a bot on Azure Bot Service.
When I go through the documentations the following example shows how to Create an Azure Bot Service in Azure Portal, download its code, change it then deploy it again to the same Azure Bot Service:
https://learn.microsoft.com/en-us/azure/bot-service/bot-service-build-download-source-code?view=azure-bot-service-4.0
In contrast, the following example shows how to build a bot in Visual Studio and publish it to an Azure Web App:
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-howto-deploy-azure?view=azure-bot-service-4.0
What are the advantages of hosting a bot on Azure Bot Service?
Is there any resource or article that contrasts the two options?
They are essentially the same thing under the hood. A bot is basically just an API endpoint so there are many ways to host you bot. If you create A bot service you get options to add other services from the creation page. Whereas if you just create a web app or app service you will have to manually add these things.
Creating a Web App Bot will allow you to all in one step create:
Bot Channels Registration
Choose a template to start with
Configure a Luis app
Add Azure Storage
Add application insights

Resources