This post describes how an Azure SignalR Service can be deployed and used through Managed Identity using Bicep. This can be used to provide SignalR capabilities to Azure Functions or WebApps even when behind Azure Frontdoor (still no Websocket support) by leveraging the serverless option of the SignalR Service.
First we create the SignalR Service and set it’s service mode to serverless. Note the way the connection string is constructed in the output section. It does not contain any secrets but instead instructs the SDK to use an Azure Managed Identity for authorization. This way we can also easily use a regular connection string for local debugging using user secrets and without any code changes.
Next we need to provide our app with the proper permissions to access the SignalR Service. There are different roles available depending on our usecase. With the serverless mode there are two responsibilites for our backend:
- Creating a negotiation endpoint to provide clients with credentials to the SignalR Service. For this we need the SignalR App Server role.
- Sending messages via the SignalR REST API that should be relayed to the clients. Here we require the SignalR REST API Owner role.
The following module provides the corresponding role ids necessary for configuring the access control.
In the next post we’ll look at how to authenticate against the SignalR Service from ASP.NET Core and and how to retreive the client connection details from the negotiation endpoint.