Delen via


Authenticatie

Bij het maken van REST-aanroepen zijn verschillende stappen vereist om goed te verifiëren. Azure Communication Services SDK's verwerken dit proces voor u, maar het handmatig indienen van aanvragen betekent dat u dit zelf moet afhandelen.

Typen verificatie

Azure Communication Services heeft drie typen verificatie. Ze worden gebruikt voor verschillende doeleinden:

  • toegangssleutelverificatie voor sms-, netwerkkruising, oproepautomatisering, identiteit en toegangstokenbewerkingen. Toegangssleutelverificatie is geschikt voor toepassingen die worden uitgevoerd in een vertrouwde serviceomgeving.
  • Azure RBAC-verificatie om de toegang tot resources te beheren door gebruik te maken van Azure RBAC door Azure-rollen toe te wijzen.
  • verificatie van tokens voor gebruikerstoegang voor chatten en bellen. Met tokens voor gebruikerstoegang kunnen uw clienttoepassingen rechtstreeks worden geverifieerd met Azure Communication Services. Deze tokens worden gegenereerd op een tokeninrichtingsservice aan de serverzijde die u maakt. Ze worden vervolgens verstrekt aan clientapparaten die gebruikmaken van het token om de chat- en belclientbibliotheken te initialiseren.

Toegangssleutelverificatie

Toegangssleutelverificatie wordt gebruikt wanneer aanvragen niet worden gedaan door uw eindgebruikertoepassing. Voer deze aanvragen uit in een vertrouwde serviceomgeving.

In deze verificatiemethode worden aanvragen ondertekend met behulp van een door de client gegenereerde op hash gebaseerde berichtverificatiecode (HMAC).

Voordat u aan de slag gaat, moet u het volgende doen:

  • Uw Azure Communication Services-toegangssleutel
  • Uw Azure Communication Service-eindpunt
  • Het URL-pad en het HTTP-werkwoord dat u aanroept
  • Een ontwikkelomgeving die HMACs, SHA256-hashes kan genereren en Base64-bewerkingen kan uitvoeren.

Zodra u deze items hebt, kunt u doorgaan met het ondertekenen van uw aanvraag.

Een HTTP-aanvraag ondertekenen

  1. Zorg ervoor dat u de volgende waarden beschikbaar hebt:

    • HTTP-aanvraagmethode (bijvoorbeeld GET of PUT)
    • Utc-tijdstempel (Coordinated Universal Time) voor de aanvraag volgens de RFC1123-standaard
    • HTTP-aanvraaghost (het <authority> URI-onderdeel zoals opgegeven in RFC2396)
    • HTTP-aanvraagbody gehasht met behulp van het SHA256-algoritme
    • HTTP-aanvraagpad (het <path> en <query> samengevoegd door ? onderdelen zoals opgegeven in RFC2396)
    Verb=<http_method>
    Timestamp=<current_datetime>
    Host=<uri_authority>
    ContentHash=SHA256(<request_body>)
    URIPathAndQuery=<uri_path>?<uri_query>
    
  2. Maak de tekenreeks die moet worden ondertekend door de waarden op de volgende manier samen te voegen:

    StringToSign=Verb + "\n"
    URIPathAndQuery + "\n"
    Timestamp + ";" + Host + ";" + ContentHash
    
  3. Genereer een HMAC-256-handtekening van de gecodeerde UTF-8-tekenreeks die u in de vorige stap hebt gemaakt. Codeer vervolgens uw resultaten als Base64. U moet uw toegangssleutel ook met Base64 decoderen. Gebruik de volgende indeling (weergegeven als pseudocode):

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))
    
  4. Voeg de volgende headers toe aan de aanvraag:

    x-ms-date: <Timestamp>
    x-ms-content-sha256: <ContentHash>
    host: <URIPathAndQuery>   
    Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"
    

Na ontvangst van de aanvraag valideert de service de handtekening en tijdstempel om te beschermen tegen bepaalde beveiligingsaanvallen, inclusief herhalingsaanvallen. Als u wilt weten hoe u de HTTP-aanvraag in verschillende programmeertalen ondertekent, gaat u naar de HMAC-headerondertekeningszelfstudie.

Azure RBAC-verificatie

Het Azure-platform biedt op rollen gebaseerde toegang (Azure RBAC) om de toegang tot de resources te beheren. Azure RBAC-beveiligingsprincipaal vertegenwoordigt een gebruiker, groep, service-principal of beheerde identiteit die toegang tot Azure-resources aanvraagt.

Microsoft Entra-verificatie biedt superieure beveiliging en gebruiksgemak ten opzichte van andere autorisatieopties. Als u bijvoorbeeld een beheerde identiteit gebruikt, hoeft u uw accounttoegangssleutel niet op te slaan in uw code, net als bij verificatie met toegangssleutels. Hoewel u toegangssleutelverificatie kunt blijven gebruiken met communication services-toepassingen, raadt Microsoft u aan waar mogelijk over te stappen naar Microsoft Entra-id.

Azure RBAC bevat veel ingebouwde rollen, kan worden toegewezen op verschillende bereiken en stelt u in staat om uw eigen aangepaste rollen te maken. Het bevat meer dan 100 ingebouwde rollen. Er zijn vijf fundamentele Azure-rollen: eigenaar, inzender, lezer, op rollen gebaseerd toegangsbeheerbeheerder en beheerder voor gebruikerstoegang. Ga naar de zelfstudie op rollen gebaseerd toegangsbeheervoor meer informatie over deze rollen.

Machtigingen die worden ondersteund door Azure Communication Services (ACS)

ACS biedt specifieke machtigingen (acs.read en acs.write) die gecontroleerde toegang tot verschillende resources toestaan.

  • acs.read-machtiging: verleent de mogelijkheid om gegevens op te halen of weer te geven.
  • machtiging acs.write: staat het wijzigen of maken van gegevens binnen dezelfde resourcetypen toe.

Daarnaast biedt ACS ondersteuning voor e-mailmachtigingen:

  • acs.email.read: hiermee kunt u lezen of toegang krijgen tot gegevens van e-mailgerelateerde services.
  • acs.email.write: hiermee kunt u e-mailgerelateerde servicesgegevens wijzigen of maken.

Deze machtigingen zijn van cruciaal belang voor gedetailleerd toegangsbeheer en beveiliging van ACS-resources.

Extra RBAC-token verkrijgen

Als u een token voor ACS wilt verkrijgen, kunt u MSAL (Microsoft Authentication Library) gebruiken. Hier volgt een stapsgewijze handleiding:

  1. Een toepassing registreren in Azure AD: zorg ervoor dat uw app is geregistreerd in Azure AD.
  2. INSTALLEER MSAL: Installeer de MSAL-bibliotheek voor uw platform (bijvoorbeeld Microsoft.Identity.Client voor .NET).
  3. MSAL configureren: STEL MSAL in met de client-id, tenant-id en clientgeheim van uw toepassing.
  4. Een token verkrijgen: gebruik MSAL om een token te verkrijgen met het benodigde bereik (https://communication.azure.com/.default).

Raadpleeg voor gedetailleerde instructies en codevoorbeelden de officiële MSAL-documentatie en documentatie over toegangstokens.

Voorbeeld van EEN HTTP-aanvraag voor het uitgeven van een ACS-toegangstoken

Verzoek:

POST https://my-resource.communication.azure.com/identities/{identity}/:issueAccessToken?api-version=2023-10-01
Authorization: Bearer <your-access-token>
Content-Type: application/json
{
  "scopes": [
    "chat",
    "voip"
  ]
}

Antwoord:

{
  "token": "token",
  "expiresOn": "2023-10-10T21:39:39.3244584+00:00"
}

Verificatie van token voor gebruikerstoegang

Met tokens voor gebruikerstoegang kunnen uw clienttoepassingen zich rechtstreeks verifiëren bij Azure Communication Services als een bepaalde gebruiker of identiteit.

Tokens voor gebruikerstoegang genereren/verkrijgen

Tokens voor gebruikerstoegang worden door u gegenereerd in een vertrouwde omgeving. Het genereren ervan met behulp van de Azure Communication Services Identity SDK is de eenvoudigste manier. Zie het maken en beheren van tokens voor gebruikerstoegangvoor meer informatie.

Een token voor gebruikerstoegang gebruiken in een aanvraag

Zodra u een geschikt token voor gebruikerstoegang hebt, kunt u het opnemen in uw aanvragen voor de REST API van Azure Communication Services. Hiervoor moet u deze in de Authorization header opgeven met behulp van het Bearer HTTP-verificatieschema Authorization: Bearer <token>.

Zie ook

Voor meer informatie over Verificatie van Azure Communication Services kunt u ook het volgende bekijken: