Navigating the complexities of cloud solutions can be a daunting task, and Azure Bot Solutions are no exception. Many customers face the challenge of privatizing their bot’s messaging endpoint, only to encounter communication breakdowns with the channel—resulting in 502 errors and unresponsive bots.

While the necessity of a public messaging endpoint is outlined in the Bot Framework Security and Privacy Frequently Asked Questions – Bot Service | Microsoft Learn, I aim to share insights and practical considerations from my experience working with clients. Please reach to Microsoft Support for more guidance.

Privatizing a bot solution involves more complexity than traditional web applications or APIs, where clients make direct calls to Web Applications. In a bot solution, users do not directly interact with Bot/Web App; instead, their requests are orchestrated and proxied through a channel connector. Additionally, bots can send messages asynchronously, facilitated by these channels.  An example of Network Isolation in Azure Web App, includes all components that can made available within customer managed network.

Bot as a Solution

Clients: User-facing application used to consume/converse with Bot solutions. Examples include Web Chat Widget, Teams, Slack etc.  
The Bot Service: This managed SaaS umbrella includes configuration management, channel services and token services. Services are made available with the <service>.botframework.com endpoints.
The Bot Application: Using the Bot SDK or Composer, you create an HTTP-based application that encapsulates your functional and conversational logic, including recognition, processing, and storage. The Bot application operates using the Bot Framework Activity Specification.
Channel Connectors: While Azure Bot Service offers two primary channels (Direct Line and Webchat), it also allows extensibility for other clients/channels. Channel connectors are implemented by their respective owners and operate within their managed data centers. The messaging endpoint is not exposed to end users; instead, users connect through channel connectors that manage user sessions, activity orchestration, and authentication. Different clients, such as Teams and Slack, represent messages and activities uniquely. Since Bot SDK applications understands and responds with activities as defined in the Bot Framework Activity Specification, channels are responsible for transforming activities and forwarding them to the application.

References:

Basics of the Microsoft Bot Framework – Bot Service | Microsoft Learn
Channels reference – Bot Service | Microsoft Learn
Create a bot in Microsoft Teams – Teams | Microsoft Learn

Simplified view of Directline Bot (Web Chat: Full-featured bundle):

Simplified view of Teams Bot Solution:

The Direct Line and Teams clients do not directly call your bot’s endpoint; instead, their requests are proxied through the Direct Line Service or Teams Channel Connector. When you privatize your bot application/endpoint, there is a high potential of disrupting communication between the channel connector and the bot application. Since these channel connectors operate within managed data centers, the requests from channels to your bot will traverse the public internet. This is why a public messaging endpoint is essential for most channels.

Options to secure Bot Solution:

You can use gateways to expose a public IP address/endpoint and internally proxy to App service. For example, Azure App Gateway, Azure Firewall, Azure Front Door as upstream for App Service. Note that these are not exhaustive options, you should be able to use any firewall/gateway which exposes public endpoint as upstream for private Bot App.

Refer – Secure your Microsoft Teams channel bot and web app behind a firewall – Azure Architecture Center | Microsoft Learn
The messaging endpoint in Bot will be the public endpoint exposed by the gateway. The AppService and AppGW for example can have private communication within Vnet.
Note that you may need additional steps to configure SSL certificate at your gateways.

If you want use AppService directly as your messaging endpoint, then you can enable public access and add restrictions to allow requests from intended channels.

For Directline, you can use “AzureBotService” Service tag as allowed restrictions.

Refer – Azure service tags overview | Microsoft Learn
Azure App Service access restrictions – Azure App Service | Microsoft Learn

For teams Bot you can whitelist IP used by Teams Servers – Secure your Microsoft Teams channel bot and web app behind a firewall – Azure Architecture Center | Microsoft Learn
For other channels, respective Channel connector Ips needs to be allowed.

Only if you are using DirectLine channel, then you can make the communications completely private using the DirectLine AppService Extension.

Explanations:

About network isolation in Azure AI Bot Service – Bot Service | Microsoft Learn
Direct Line App Service extension – Bot Service | Microsoft Learn

Guides:

Private Endpoint & Direct Line App Service Extension Configuration with Bot Services and App Service – Microsoft Community Hub
Deploying Bot APIs to intranet and internal web applications – Microsoft Community Hub

Other Security FAQs:

Bot Framework Security and Privacy Frequently Asked Questions – Bot Service | Microsoft Learn

Considerations with DirectLine App Service Extension (DL-ASE) | The Fully Insolated Directline Bot:

In simple explanation, we host the Channel Connector (Bot Service) in the AppService using Azure Web Sites Extensions | Microsoft Azure Blog. This way the users can directly connect to AppService URL (instead of directLine.botframework.com) which you can restrict with private endpoints. Note that the users need to have access to Vnet (via ExpressRoute, VPN etc.) where the AppService is deployed when you disable public access (Connect privately to an App Service apps using private endpoint – Azure App Service | Microsoft Learn)
This setup is only possible with Windows App service with .Net or Node Bot SDK for DirectLine Client.
While achieving full network isolation, your WebApp must handle WebSocket connections and execute functional logic, unlike the public DirectLine where WebSocket connections are managed by Azure Bot Service. (Pricing – Azure Bot Services | Microsoft Azure) 
The Directline ASE client will use streaming/WebSockets API, and the HTTP rest APIs are not supported (API reference – Direct Line API 3.0 – Bot Service | Microsoft Learn)
Does not support Direct Line enhanced authentication – Bot Service | Microsoft Learn.
Troubleshooting the IPC(or named pipes) can become difficult. While on the public directline it is HTTP post between channel and WebApp which is easily tracked.

Hope this helps!

​Microsoft Tech Community – Latest Blogs –Read More