Configurer l’autorisation entre locataires avec Microsoft Entra

Pour des raisons de sécurité, votre serveur peut héberger un locataire indépendamment de votre ressource Azure SignalR Service. Étant donné que l’identité managée ne peut pas être utilisée entre les locataires, vous devez inscrire une application dans le locataire A, puis la provisionner en tant qu’application d’entreprise dans le locataire B. Cet article vous aide à créer une application dans le locataire A et à l’utiliser pour vous connecter à une ressource Azure SignalR Service dans le locataire B.

Enregistrer une application multitenant dans le client A

La première étape consiste à créer une application mutualisée. Pour plus d’informations, consultez Démarrage rapide : Inscrire une application dans Microsoft Entra ID.

Si vous disposez déjà d’une application à locataire unique, suivez les instructions de conversion d’une application monolocataire en multilocataire sur l’ID Microsoft Entra.

Il existe quatre types de comptes :

• Comptes dans cet annuaire organisationnel
• Comptes dans n’importe quel annuaire organisationnel
• Comptes dans n’importe quel répertoire organisationnel et comptes Microsoft personnels
• Comptes Microsoft personnels

Veillez à sélectionner le deuxième type ou le troisième type lorsque vous créez l’application.

.

Notez l’ID d’application (client) et l’ID d’annuaire (locataire) à utiliser dans les étapes suivantes.

Approvisionner l’application dans le locataire B

Vous ne pouvez pas attribuer le rôle à l’application inscrite dans d’autres locataires. Vous devez l’approvisionner en tant qu’application d’entreprise externe dans le locataire B. Si vous avez besoin d’informations supplémentaires, vous pouvez en savoir plus sur les différences entre l’inscription des applications et les applications d’entreprise.

En bref, l'application d'entreprise est un principal de service et l'enregistrement de l'application ne l’est pas. L’application d’entreprise hérite de certaines propriétés de l’objet d’application, telles que l’ID d’application (client).

Un principal de service par défaut est créé dans le locataire où l'application est enregistrée. Pour les autres locataires, vous devez approvisionner l’application pour obtenir le principal de service d’une application d’entreprise. Pour plus d’informations, consultez Créer une application d’entreprise à partir d’une application mutualisée dans Microsoft Entra ID.

Les applications d’entreprise dans différents locataires ont des ID d’annuaire (locataire) différents, mais elles partagent le même ID d’application (client).

Attribuer des rôles à l’application d’entreprise

Une fois que l’application d’entreprise est configurée dans votre locataire B, vous pouvez lui attribuer des rôles.

Les étapes suivantes décrivent comment attribuer un rôle App Server SignalR à un principal de service ou une identité managée pour une ressource Azure SignalR Service. Pour obtenir des instructions détaillées, consultez Affecter des rôles Azure à l’aide du portail Azure.

Note

Vous pouvez attribuer un rôle à n’importe quelle étendue, y compris le groupe d’administration, l’abonnement, le groupe de ressources ou une seule ressource. Pour en savoir plus sur l’étendue, consultez Comprendre l’étendue pour Azure RBAC.

1. Dans le portail Azure, accédez à votre ressource Azure SignalR Service.

2. Dans le volet de gauche, sélectionnez Contrôle d’accès (IAM).

3. Sélectionnez Ajouter>Ajouter une attribution de rôle.

   

4. Sous l’onglet Rôle , sélectionnez SignalR App Server. D’autres rôles intégrés Azure SignalR Service dépendent de votre scénario.

   Role	Descriptif	Cas d’utilisation
   Serveur d’applications SignalR	Accès aux API qui créent des connexions serveur et génèrent des clés.	Le plus couramment utilisé pour un serveur d’applications avec une ressource Azure SignalR s’exécutant en mode par défaut.
   Propriétaire du service SignalR	Accès complet à toutes les API de plan de données, y compris les API REST, les API qui créent des connexions serveur et les API qui génèrent des clés/jetons.	Utilisé pour un serveur de négociation avec une ressource Azure SignalR Service s’exécutant en mode serverless. Elle nécessite des autorisations d’API REST et des autorisations d’API d’authentification.
   Propriétaire de l’API REST SignalR	Accès complet aux API REST du plan de données.	Utilisé pour le Kit de développement logiciel (SDK) De gestion Azure SignalR pour gérer les connexions et les groupes, mais il n’effectue pas de connexions serveur ni ne gère les demandes de négociation.
   Lecteur d’API REST SignalR	Accès en lecture seule aux API REST du plan de données.	Utilisé lorsque vous écrivez un outil de surveillance qui appelle des API REST en lecture seule.

5. Cliquez sur Suivant.

6. Pour l’application Microsoft Entra :

   1. Dans la ligne Affecter l'accès à, sélectionnez Utilisateur, groupe ou principal de service.
   2. Dans la ligne Membres , sélectionnez des membres, puis choisissez l’identité dans la fenêtre contextuelle.

7. Pour l’identité managée pour les ressources Azure :

   1. Dans la ligne Assigner l'accès à, sélectionnez Identité managée.
   2. Dans la ligne Membres , sélectionnez des membres, puis choisissez l’application dans la fenêtre contextuelle.

8. Cliquez sur Suivant.

9. Passez en revue votre attribution, puis sélectionnez Vérifier + attribuer pour confirmer l’attribution de rôle.

Important

Les attributions de rôles nouvellement ajoutées peuvent prendre jusqu’à 30 minutes pour se propager.

Pour en savoir plus sur l’attribution et la gestion des rôles Azure, consultez :

• Attribuer des rôles Azure à l’aide du portail Azure
• Attribuer des rôles Azure à l’aide de l’API REST
• Attribuer des rôles Azure à l’aide d’Azure PowerShell
• Attribuer des rôles Azure à l’aide d’Azure CLI
• Attribuer des rôles Azure à l’aide de modèles Azure Resource Manager

Configurer le Kit de développement logiciel (SDK) Azure SignalR Service pour utiliser l’application d’entreprise

Une application utilise trois types d’informations d’identification différents pour s’authentifier :

• Certificats
• Clés secrètes client
• Identité fédérée

Nous vous recommandons vivement d’utiliser des certificats ou des secrets clients pour effectuer des demandes entre locataires.

Utiliser des certificats ou des secrets clients

• Le tenantId paramètre est l’ID de votre locataire B.
• Les clientId paramètres des deux locataires sont égaux.
• Les paramètres clientSecret et clientCert sont configurés dans le locataire A. Pour plus d'informations, consultez Ajouter des identifiants.

Si vous n’êtes pas sûr de votre ID de locataire, consultez Rechercher votre locataire Microsoft Entra.

services.AddSignalR().AddAzureSignalR(option =>
{
    var credential1 = new ClientSecretCredential("tenantId", "clientId", "clientSecret");
    var credential2 = new ClientCertificateCredential("tenantId", "clientId", "path-to-cert");

    option.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint(new Uri("https://<resource1>.service.signalr.net"), credential1),
        new ServiceEndpoint(new Uri("https://<resource2>.service.signalr.net"), credential2),
    };
});

Utiliser l’identité fédérée

Pour des raisons de sécurité, les certificats et les secrets client peuvent être désactivés dans votre abonnement. Dans ce cas, vous devez utiliser un fournisseur d’identité externe ou tester la prise en charge en prévision de l’identité managée. Pour plus d’informations, consultez :

• Configurer une application pour faire confiance à un fournisseur d’identité externe
• Configurer une application pour approuver une identité managée (préversion)

Pour obtenir des informations détaillées et des conseils vidéo, consultez Microsoft Entra Cross-Tenant Application Federated Identity Credential (FIC).

Lorsque vous utilisez l’identité managée en tant que fournisseur d’identité, le code ressemble à l’exemple suivant :

• Le tenantId paramètre est l’ID de votre locataire B.
• Les clientId paramètres des deux locataires sont égaux.

services.AddSignalR().AddAzureSignalR(option =>
{
    var msiCredential = new ManagedIdentityCredential("msiClientId");

    var credential = new ClientAssertionCredential("tenantId", "appClientId", async (ctoken) =>
    {
        // Entra ID US Government: api://AzureADTokenExchangeUSGov
        // Entra ID China operated by 21Vianet: api://AzureADTokenExchangeChina
        var request = new TokenRequestContext([$"api://AzureADTokenExchange/.default"]);
        var response = await msiCredential.GetTokenAsync(request, ctoken).ConfigureAwait(false);
        return response.Token;
    });

    option.Endpoints = [
        new ServiceEndpoint(new Uri(), "https://<resource>.service.signalr.net"), credential);
    ];
});

Lorsque vous utilisez des fournisseurs d’identité externes, le code ressemble à l’exemple suivant :

services.AddSignalR().AddAzureSignalR(option =>
{
    var credential = new ClientAssertionCredential("tenantId", "appClientId", async (ctoken) =>
    {
        // Find your own way to get a token from the external identity provider.
        // The audience of the token should be "api://AzureADTokenExchange" because it is the recommended value.
        return "TheTokenYouGetFromYourExternalIdentityProvider";
    });

    option.Endpoints = [
        new ServiceEndpoint(new Uri(), "https://<resource>.service.signalr.net"), credential);
    ];
});

Le débogage de l’acquisition de jetons avec le Kit de développement logiciel (SDK) Azure SignalR Service est problématique, car il dépend des résultats des jetons. Nous vous recommandons de tester le processus d’acquisition de jetons localement avant de vous intégrer au Kit de développement logiciel (SDK) Azure SignalR Service.

var assertion = new ClientAssertionCredential("tenantId", "appClientId", async (ctoken) =>
{
    // Find your own way to get a token from the external identity provider.
    // The audience of the token should be "api://AzureADTokenExchange" because it is the recommended value.
    return TheTokenYouGetFromYourExternalIdentityProvider;
});

var request = new TokenRequestContext(["https://signalr.azure.com/.default");
var token = await assertion.GetTokenAsync(assertion);
Console.log(token.Token);

Le point clé consiste à utiliser des identifiants internes pour obtenir un clientAssertion paramètre à partir de api://AzureADTokenExchange ou d'autres plateformes approuvées d'identité. Utilisez-le ensuite pour échanger un jeton avec l’audience https://signalr.azure.com/.default pour accéder à votre ressource.

Votre objectif est d’obtenir un jeton avec les revendications suivantes. Utilisez jwt.io pour vous aider à décoder le jeton :

• oid : La valeur doit être égale à votre ID d’objet d’application d’entreprise. Si vous ne savez pas où l’obtenir, consultez Récupérer un ID d’objet d’entreprise.
• tid : La valeur doit être égale à l’ID d’annuaire de votre locataire B. Si vous n’êtes pas sûr de votre ID de locataire, consultez Rechercher votre locataire Microsoft Entra.
• Audience : l’audience doit être https://signalr.azure.com/.default pour accéder aux ressources Azure SignalR Service.

Contenu connexe

• ID Microsoft Entra pour Azure SignalR Service
• Autoriser les demandes aux ressources Azure SignalR Service avec les applications Microsoft Entra
• Autoriser les demandes adressées aux ressources Azure SignalR Service avec des identités managées pour les ressources Azure