Navigating Azure Bot Networking: Key Considerations for Privatization

While the necessity of a public messaging endpoint is outlined in the article 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. The Bot application exposes a public messaging endpoint for receiving activities (messaging endpoint).
• 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.

Now you might be concerned about allowing public traffic to your VM. Here are few suggestions and explanations:

• Bot Framework Security and Privacy Frequently Asked Questions - Bot Service | Microsoft Learn
• Firstly, the Bot Application/Adapter is secured with Entra Authentication and only authentic callers who have capability to generate a valid Entra JWT token can consume the Bot:
• What keeps my bot secure from clients impersonating the Bot Framework Service?
• All authentic Bot Framework requests are accompanied by a JWT token whose cryptographic signature can be verified by following the authentication guide. The token is designed so attackers can't impersonate trusted services.
• The security token accompanying every request to your bot has the ServiceUrl encoded within it, which means that even if an attacker gains access to the token, they can't redirect the conversation to a new ServiceUrl. This is enforced by all implementations of the SDK and documented in our authentication reference materials.
• If the incoming token is missing or malformed, the Bot Framework SDK won't generate a token in response. This limits how much damage can be done if the bot is incorrectly configured.
• Inside the bot, you can manually check the ServiceUrl provided in the token. This makes the bot more fragile if the service topology changes, so while this is possible, it's not recommended.

You can configure additional network/Transport layer security to allow intended channels to consume the Bot.

Options to secure Bot Solution:

• Option 1 – Gateway based privatization:

  • 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.
  • 

  Option 2 – If you want use AppService directly as your messaging endpoint:

  • You can enable public access and add restrictions to allow requests from intended channels - Service Tags for Azure Bot: Simplifying IP Management | Microsoft Community Hub
  • For Directline, you can use "AzureBotService" Service tag as allowed service.
  • 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 - Microsoft 365 URLs and IP address ranges - Microsoft 365 Enterprise | Microsoft Learn
  • For other channels, respective Channel connector Ips needs to be allowed.

  Option 3 - Only if you are using DirectLine channel, then you can make the communications completely private using the DirectLine AppService Extension with considerations.

  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!