Verifiëren bij Azure Communication Services
Elke clientinteractie met Azure Communication Services moet worden geverifieerd. In een typische architectuur worden client- en serverarchitectuur, toegangssleutels of Microsoft Entra-verificatie gebruikt voor verificatie aan de serverzijde.
Een ander type verificatie maakt gebruik van tokens voor gebruikerstoegang om te verifiëren bij services waarvoor gebruikersdeelname is vereist. De chat- of belservice maakt bijvoorbeeld gebruik van tokens voor gebruikerstoegang, zodat gebruikers kunnen worden toegevoegd in een thread en gesprekken met elkaar kunnen voeren.
Verificatieopties
In de volgende tabel ziet u de SDK's van Azure Communication Services en de bijbehorende verificatieopties:
| SDK | Verificatieoptie |
|---|---|
| Identiteit | Toegangssleutel of Microsoft Entra-verificatie |
| Sms | Toegangssleutel of Microsoft Entra-verificatie |
| Telefoonnummers | Toegangssleutel of Microsoft Entra-verificatie |
| E-mailen | Toegangssleutel of Microsoft Entra-verificatie |
| Geavanceerde berichten | Toegangssleutel of Microsoft Entra-verificatie |
| Bellen | Token voor gebruikerstoegang |
| Chat | Token voor gebruikerstoegang |
Elke autorisatieoptie wordt hieronder kort beschreven:
Toegangssleutel
Verificatie van toegangssleutels is geschikt voor servicetoepassingen die worden uitgevoerd in een vertrouwde serviceomgeving. Uw toegangssleutel vindt u in de Azure Communication Services-portal. De servicetoepassing gebruikt deze als referentie om de bijbehorende SDK's te initialiseren. Bekijk een voorbeeld van hoe deze wordt gebruikt in de Identity SDK.
Omdat de toegangssleutel deel uitmaakt van de verbindingsreeks van uw resource, is verificatie met een verbindingsreeks gelijk aan verificatie met een toegangssleutel.
Als u de API's van Azure Communication Services handmatig wilt aanroepen met behulp van een toegangssleutel, moet u de aanvraag ondertekenen. Het ondertekenen van de aanvraag wordt in detail uitgelegd in een zelfstudie.
Als u een service-principal wilt instellen, maakt u een geregistreerde toepassing vanuit de Azure CLI. Vervolgens kunnen het eindpunt en de referenties worden gebruikt om de SDK's te verifiëren. Bekijk voorbeelden van hoe service-principal wordt gebruikt.
Communication Services biedt ondersteuning voor Microsoft Entra ID-verificatie voor Communication Services-resources. Meer informatie over de ondersteuning voor beheerde identiteiten vindt u in Managed Identity gebruiken met Azure Communication Services.
Microsoft Entra ID-verificatie
Het Azure-platform biedt op rollen gebaseerde toegang (Azure RBAC) om de toegang tot resources te beheren. Azure RBAC-beveiligingsprincipaal vertegenwoordigt een gebruiker, groep, service-principal of beheerde identiteit die toegang tot Azure-resources aanvraagt. Microsoft Entra ID-verificatie biedt superieure beveiliging en gebruiksgemak ten opzichte van andere autorisatieopties.
Beheerde identiteit:
- Door beheerde identiteit te gebruiken, hoeft u uw accounttoegangssleutel niet op te slaan in uw code, net als bij autorisatie van toegangssleutels. Referenties voor beheerde identiteiten worden volledig beheerd, gedraaid en beveiligd door het platform, waardoor het risico op blootstelling aan referenties wordt verminderd.
- Beheerde identiteiten kunnen worden geverifieerd bij Azure-services en -resources die ondersteuning bieden voor Microsoft Entra ID-verificatie. Deze methode biedt een naadloze en veilige manier om referenties te beheren.
- Raadpleeg deze handleiding voor meer informatie over het gebruik van managed identity met Azure Communication Services.
Service-principal:
- Als u een service-principal wilt instellen, maakt u een geregistreerde toepassing vanuit de Azure CLI. Vervolgens kunnen het eindpunt en de referenties worden gebruikt om de SDK's te verifiëren.
- Bekijk voorbeelden van hoe service-principal wordt gebruikt.
Communication Services biedt ondersteuning voor Microsoft Entra ID-verificatie voor Communication Services-resources. Hoewel u toegangssleutelautorisatie kunt blijven gebruiken met communication services-toepassingen, raadt Microsoft aan waar mogelijk over te stappen naar Microsoft Entra-id.
Gebruik ons hero-voorbeeld van de vertrouwde verificatieservice om Azure Communication Services-toegangstokens toe te wijzen aan uw Microsoft Entra-id.
Tokens voor gebruikerstoegang
Tokens voor gebruikerstoegang worden gegenereerd met behulp van de Identity SDK en zijn gekoppeld aan gebruikers die zijn gemaakt in de Identity SDK. Bekijk een voorbeeld van het maken van gebruikers en het genereren van tokens. Vervolgens worden tokens voor gebruikerstoegang gebruikt om deelnemers te verifiëren die zijn toegevoegd aan gesprekken in de Chat- of Calling SDK. Zie Chat toevoegen aan uw app voor meer informatie. Verificatie van gebruikerstoegangstokens verschilt in vergelijking met de toegangssleutel en Microsoft Entra-verificatie omdat deze wordt gebruikt om een gebruiker te verifiëren in plaats van een beveiligde Azure-resource.
Identiteit gebruiken voor bewaking en metrische gegevens
De gebruikersidentiteit is bedoeld als primaire sleutel voor logboeken en metrische gegevens die worden verzameld via Azure Monitor. Als u bijvoorbeeld alle aanroepen van een specifieke gebruiker wilt bekijken, moet u uw verificatie zo instellen dat een specifieke Azure Communication Services-identiteit (of identiteiten) wordt toegewezen aan een enkele gebruiker. Meer informatie over log analytics en metrische gegevens die voor u beschikbaar zijn.
Volgende stappen
Raadpleeg voor meer informatie de volgende artikelen: