The Azure Functions SignalR extension enables serverless integration with the SignalR Service. We’re excited to announce the release of version 1.7.0-beta.1 for .NET, which introduces Azure Identity integration. The required configuration is similar to what has been discussed for other Function extensions in Introducing the new Azure Function extension libraries **Beta**.
Configuration
With the Identity integration, a Function app can authenticate without providing a connection string in the Function configuration. This post discusses the required configuration in the Azure portal’s app settings section of your Function app. For more information on configuring app settings for Functions apps, see Manage your Function app.
General setup
Unless otherwise specified, each configuration option is powered by the DefaultAzureCredential type. There are two ways you can configure the Identity connection settings for the SignalR extension:
- As part of your Connection setting.
- As part of your Endpoints settings.
The SignalR Service Owner role is needed to use an Identity-based connection.
Connection setting
You can configure the service URI in a custom connection setting or in the default connection setting AzureSignalRConnectionString
:
Custom connection setting:
Name | Value |
---|---|
MyConnection__serviceUri |
https://{SignalRHost} |
Default connection setting:
Name | Value |
---|---|
AzureSignalRConnectionString |
https://{SignalRHost} |
Here’s a simple Function that runs when a message is sent from the SignalR Service. This example specifies a custom connection string setting, MyConnection
, where we’ve configured the connection information.
[FunctionName("SignalRTriggerFunction")]
public static void Run(
[SignalRTrigger("SignalRTest", "messages", "SendMessage", ConnectionStringSetting="MyConnection")] InvocationContext invocationContext,
[SignalRParameter] string message,
ILogger logger)
{
logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}
You can still use connection string configuration by setting your connection setting to your connection string. This approach is demonstrated in the library’s README.
Multiple endpoints setting
You can also configure your service URI and other Identity settings per endpoint. The multiple-endpoint feature is only supported on the Persistent transport type.
Name | Value |
---|---|
Azure__SignalR__Endpoints__eastUs__serviceUri |
https://{SignalRHost1} |
Azure__SignalR__Endpoints__westUs__serviceUri |
https://{SignalRHost2} |
When using multiple-endpoint configuration, the connection setting wouldn’t be specified in your Function:
[FunctionName("SignalRTriggerFunction")]
public static void Run(
[SignalRTrigger("SignalRTest", "messages", "SendMessage")] InvocationContext invocationContext,
[SignalRParameter] string message,
ILogger logger)
{
logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}
For more information, see Multiple Azure SignalR Service Instances Support in Azure Functions.
Advanced configuration
In each of the preceding examples, the DefaultAzureCredential type would be used by the extensions to attempt to authenticate with the service. It’s also possible to configure more fine-grained authentication. We’ll use the connection setting approach as an example. The same settings are available when using the endpoints setting.
To configure using Managed Identity, which uses the ManagedIdentityCredential type:
Name | Value |
---|---|
MyConnection__serviceUri |
https://{SignalRHost} |
MyConnection__credential |
managedIdentity |
MyConnection__clientId |
{myClientId} |
To configure using a client secret credential, which uses the ClientSecretCredential type:
Name | Value |
---|---|
MyConnection__serviceUri |
https://{SignalRHost} |
MyConnection__tenantId |
{myTenantId} |
MyConnection__clientId |
{myClientId} |
MyConnection__clientSecret |
{myClientSecret} |
And finally, to configure using a client certificate, which uses the ClientCertificateCredential type:
Name | Value |
---|---|
MyConnection__serviceUri |
https://{SignalRHost} |
MyConnection__tenantId |
{myTenantId} |
MyConnection__clientId |
{myClientId} |
MyConnection__certificate |
{myCertificateThumbprint} |
Conclusion
The Functions SignalR extension enables serverless integration with the SignalR Service. By using Azure Active Directory configuration, you can avoid deploying secrets along with your app.
For more information about the Functions SignalR extension, see the README.
Update on 4/28/2022:
The stable version for Azure Identity support is already released. Please see the Nuget page for the latest version.
——————————————————————–
As an update, 1.7.0-beta.2 is also released. Welcome to have a try!
I have just looked for that a couple days ago :) I have applied it to my Function App running on .net6 in the isolated worker but it still fails with the error:
<code>
The Function App has the following role in the SignalR:
<code>
Here is the syntax of the 'negotiate' function:
<code>
The 'AzureSignalRConnectionString' setting has the following value:
<code>
What am I missing?
--
I tend to believe it does not apply to the isolated worker runtime yet...
Update on 4/28/2022:
For isolated worker, please upgrade to the latest version to use the feature.Microsoft.Azure.Functions.Worker.Extensions.SignalRService
————————————————————
Yes, the code to support Azure Identity is completed for isolated worker runtime but it is not released yet.
There is no documentation for Isolated Azure Func & SignalR, this is just hell for all of us !
Your connexion string should be in the following format, as you can find it in SignalR Hub/Parameters/Connexion Strings in Azure portal :
"Endpoint=https://XXX.service.signalr.net;AccessKey=XXX=;Version=1.0;"
I was able to negociate then broadcast a message after hours of search & tries.
I am now stuck on NOT having my functions triggered on SignalR client connexion / disconnexion, If you are successful with this, please help...
[Function("onconnected")]
public static void OnConnected(
...