I am developing a chatbot on Microsoft teams for internal use only, which needs to be deployed and hosted on the intranet. In order to NOT make the bot's APIs public I plan to use Azure VNET. Within this VNET how can I connect the azure bot service resource?
Could someone please guide me on how to set this up? Also, direct me to any concepts that I need to understand, to tackle this problem.
I can't advise on the VNET side of things (hopefully the Microsoft Bot engineers here on the site can advise), but here some other things that might be of use/interest in securing your bot for on premises/internal company use:
Of course you'll side-load this app into the private company store, not the real Teams app store - do you need any info on how to do this?
I'd strongly suggest blocking access to your bot from tenant(s) other than your own - Microsoft have a sample middleware to do just this, but as per this link it's now been rolled into the core Bot Framework SDK. This means that even if someone from another tenant (i.e. company) tried to access your bot, it would reject their messages.
There are also mechanisms to sign users in, like using a signin card that could be applicable here, but I'm not sure you can lock users to a specific tenant this way. This would definitely be useful though if your bot is accessing any outside resources though, as it could be used to lock access to those.
Probably (2) above is your easiest and best bet, and it's pretty easy to implement.
Related
Currently there are two portal options to update the endpoint for a Teams Bot:
https://dev.teams.microsoft.com/bots (works intermittently)
https://dev.botframework.com/bots
How can we update this from the command line / with code?
I'm aware of the az bot commands (https://learn.microsoft.com/en-us/cli/azure/bot?view=azure-cli-latest) but this appears to be for managing resources deployed under 'Bot Services', and not bots created via the 'Bot Framework'.
Thanks.
I had a chat just last week with someone else about this - see How to add authentication to a Bot Framework v4 project without Azure Bot Service?
In essence, the "bot portal" is basically just provisioning things for you behind the scenes in the Azure portal in any case - I'd suggest rather just doing everything in Azure directly. In any, the Microsoft Bot "Framework" conceptually consists of two pieces - code samples + SDKs, and a backend core service that underlies every bot. As a result, bot "Framework" bots also have a "Bot Service" backend. Note that, by itself, this does not include hosting for the bot, just a central service registration to handle the traffic routing, security, etc.
Please have a read of the blog post I refer in that other question - it (hopefully) gives a good overview.
In answer to your question directly - az bot should be fine to use, specifically https://learn.microsoft.com/en-us/cli/azure/bot?view=azure-cli-latest#az-bot-update
My client wants to integrate with DocuSign but has a limited budget, enough to cover the DocuSign Basic API plan. This plan has limited functionality compared to the Intermediate and Advanced plans.
Meanwhile a Developer account has access to all features.
How do I know which endpoints I can use if I'm targeting a Basic API plan, such that when I go live, I know my integration will work on the Basic API plan?
The way we typically approach this problem is by ensuring that your client account can be used to perform the operations that your integration will be doing.
So, say client comes with requirement - I want your app to do X.
Ask them - can you do X manually from the web app?
If they can - your app will be able to do it.
It's not really "which API endpoints" but which features. The same endpoint can be used for multiple features and vice versa.
Explore with your client what they want to do, ensure they can do it from the web app - and then you can use the API to do it without any issues.
We're developing a managed app (using ARM templates) that will be deployed to multiple tenants. The solution will, among other things, work with SharePoint sites on the end users' tenant.
We have looked into using a single multi-tenant app registration with the appropriate rights. Because of security restrictions on the SharePoint API when using Azure app-only, a certificate must be added to the app registration and the PFX must be provided in all API calls.
We wish to have as little data at our end as possible, so the we hoped to include the application that connects to SharePoint as part of the deployment. However, this would lead to multiple apps having access to the same PFX, which doesn't seem safe.
I'm hoping there is a better way to go about this. Must the connecting web app instead be hosted on our end? Is there a safe way of storing the PFX in multiple locations, or make it accessible to multiple tenants? It is important to us that we can automate the process as well, preferrably using ARM or an automation job as part of the deployment ... At the very least, I would be thankful for suggestions on making any configurations relatively pain-free for the end user.
PS: We would like to avoid the use of service user accounts.
I've just setup a new Azure Mobile App (first time using one since the old Mobile Services).
After setting up the app you can use one of the "Quick Start" offerings to create a Xamarin.Forms app that connects to your service and they create a dummy ToDoItem table for you. Then you can download the source for the app which is helpful.
The bit where I'm left scratching my head is that previously with the Mobile Services you would have your Mobile Services URL and an API key that was to stay secret (how secret you can keep this is open to debate as at the end of the day it's in your code and is probably possible for someone to reverse engineer the APK or whatever and get it)... BUT with the new Mobile App service there doesn't seem to be any notion of this secret API key. I've hunted around the sample app source and can only find the URL for the app service and nothing else.
So my question is, what's to stop someone else using my Mobile App service URL and reading/writing to (or worse, deleting from) my SQL Server tables?
Perhaps I'm missing something... If anyone can shed any light on the subject that would be great.
The application key was dropped as a security mechanism as it gave a false sense of security. As you mention, there is nothing to stop people from obtaining the key through reverse engineering the app or capturing network traffic - in some ways it is worse than no security at all!
We highly recommend you set up your tables to only allow authenticated access. Using the social media identity providers don't give you any role based access control, but with Azure Active Directory, you can set up groups fairly easily.
You can find some basic information and tutorials (Xamarin.Forms is included) at https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-auth/. There is also a wealth of information on Mobile Apps in general at https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/.
I have an existing Web API 2 project that I'm looking to move over to Azure Service Fabric. I'm planning on creating a single stateless service within Fabric as detailed here (mainly as I don't understand actors/services at the moment!) and move the API across.
My API uses Entity Framework for it's backend and the built in Individual Accounts using OWIN.
Is there anything I need to consider when moving the service over (I mainly thought the the DB and authentication might be an issue) or is it just a case of putting a Service Fabric layer on top?
Thanks
EDIT
I've had a bit more of a thought about this and have some more questions (based on #Mihail's comment)!
So I'm going to have many stateless services (so I'm splitting my Web API project up) which will be exposed via a Web API project (based on this)
So two questions really:
I need to authenticate users based on Individual Accounts. I think I should do this on the Web API frontend so only authenticated users get through to the Fabric services but that means that the API has access to the DB and it's not just a pass through anymore. Is this OK? Should the API call a microservice to authenticate and then call the service it requires or is this overkill?
Entity Framework. If I have many services (and API frontend) accessing the same DB do I have to worry about concurrent connections/locking or will Entity Framework handle this for me?
As Mihail said, the questions around Entity Framework and authentication shouldn't be a problem, or at least not a Service Fabric specific problem.
One thing to consider though is whether Service Fabric is appropriate here if the only thing you'll have is a simple API, or whether an Azure API app would be a better fit for you.
If you went with Service Fabric, you'd have to have at least 5 VMs so you'll need to consider whether your app requires 5 VMs or whether that would be an overkill. Also remember that you'll need to manage those VMs - you don't get the magic that a PaaS solution would give you. You'd also have to deal with certain things that you'd get out of the box from an API app like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Might be worth having a look at this SO question for a comparison between Service Fabric and the App Service.