Autenticazione

  • Articolo

Quando si eseguono chiamate REST, sono necessari diversi passaggi per l'autenticazione corretta. Gli SDK di Servizi di comunicazione di Azure gestiscono automaticamente questo processo, ma l'esecuzione manuale delle richieste significa che sarà necessario gestirlo manualmente.

Tipi di autenticazione

Servizi di comunicazione di Azure ha tre tipi di autenticazione, che vengono usati per scopi diversi:

  • di autenticazione con chiave di accesso per SMS, attraversamento di rete, automazione delle chiamate, identità e token di accesso. L'autenticazione con chiave di accesso è adatta alle applicazioni in esecuzione in un ambiente di servizio attendibile.
  • l'autenticazione con controllo degli accessi in base al ruolo di Azure per controllare l'accesso alle risorse usando il controllo degli accessi in base al ruolo di Azure assegnando ruoli di Azure.
  • di autenticazione del token di accesso utente per chat e chiamate. I token di accesso utente consentono alle applicazioni client di eseguire l'autenticazione direttamente in Servizi di comunicazione di Azure. Questi token vengono generati in un servizio di provisioning di token sul lato server creato. Vengono quindi forniti ai dispositivi client che usano il token per inizializzare le librerie client chat e chiamate.

Autenticazione con chiave di accesso

L'autenticazione con chiave di accesso viene usata quando le richieste non vengono effettuate dall'applicazione dell'utente finale. Eseguire queste richieste all'interno di un ambiente del servizio attendibile.

In questo metodo di autenticazione le richieste vengono firmate usando un codice HMAC (Hash-Based Message Authentication Code) generato dal client.

Prima di iniziare, assicurarsi di avere:

  • Chiave di accesso di Servizi di comunicazione di Azure
  • Endpoint del servizio di comunicazione di Azure
  • Percorso URL e verbo HTTP che si sta chiamando
  • Un ambiente di sviluppo, che può generare HMACs, hash SHA256 ed eseguire operazioni Base64.

Dopo aver creato questi elementi, è possibile continuare con la firma della richiesta.

Firma di una richiesta HTTP

  1. Assicurarsi di disporre dei valori seguenti:

    • Metodo di richiesta HTTP (ad esempio, GET o PUT)
    • Timestamp UTC (Coordinated Universal Time) per la richiesta in base allo standard RFC1123
    • Host richiesta HTTP (componente URI <authority> come specificato in RFC2396)
    • Hash del corpo della richiesta HTTP con l'algoritmo SHA256
    • Percorso della richiesta HTTP (<path> e <query> concatenati dai componenti di ? come specificato in RFC2396)
    Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>

  2. Costruire la stringa da firmare concatenando i valori nel modo seguente:

    StringToSign=Verb + "\n"
URIPathAndQuery + "\n"
Timestamp + ";" + Host + ";" + ContentHash

  3. Generare una firma HMAC-256 della stringa con codifica UTF-8 creata nel passaggio precedente. Codificare quindi i risultati come Base64. È anche necessario decodificare la chiave di accesso in Base64. Usare il formato seguente (illustrato come pseudo-codice):

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))

  4. Aggiungere le intestazioni seguenti alla richiesta:

    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>"

Al momento della ricezione della richiesta, il servizio convalida la firma e il timestamp per proteggersi da determinati attacchi di sicurezza, inclusi gli attacchi di riproduzione. Per informazioni su come firmare la richiesta HTTP in vari linguaggi di programmazione, vedere l'esercitazione sulla firma dell'intestazione HMAC .

Autenticazione controllo degli accessi in base al ruolo di Azure

La piattaforma Azure fornisce l'accesso in base al ruolo (Controllo degli accessi in base al ruolo di Azure) per controllare l'accesso alle risorse. L'entità di sicurezza controllo degli accessi in base al ruolo di Azure rappresenta un utente, un gruppo, un'entità servizio o un'identità gestita che richiede l'accesso alle risorse di Azure.

L'autenticazione di Microsoft Entra offre maggiore sicurezza e facilità d'uso rispetto ad altre opzioni di autorizzazione. Ad esempio, usando l'identità gestita, si evita di dover archiviare la chiave di accesso dell'account all'interno del codice, come si fa con l'autenticazione con chiave di accesso. Anche se è possibile continuare a usare l'autenticazione con chiave di accesso con applicazioni di servizi di comunicazione, Microsoft consiglia di passare all'ID Microsoft Entra laddove possibile.

Il controllo degli accessi in base al ruolo di Azure include molti ruoli predefiniti, può essere assegnato a ambiti diversi e consente di creare ruoli personalizzati. Include oltre 100 ruoli predefiniti. Sono disponibili cinque ruoli fondamentali di Azure: Proprietario, Collaboratore, Lettore, Amministratore controllo degli accessi in base al ruolo e Amministratore accesso utenti. Per altre informazioni su questi ruoli, vedere l'esercitazione sul controllo degli accessi in base al ruolo.

Autorizzazioni supportate da Servizi di comunicazione di Azure

ACS offre autorizzazioni specifiche (acs.read e acs.write) che consentono l'accesso controllato a varie risorse.

  • autorizzazione acs.read: concede la possibilità di recuperare o visualizzare i dati.
  • autorizzazione acs.write: consente la modifica o la creazione di dati all'interno di questi stessi tipi di risorse.

Inoltre, ACS supporta le autorizzazioni correlate alla posta elettronica:

  • acs.email.read: abilita la lettura o l'accesso ai dati dei servizi correlati alla posta elettronica.
  • acs.email.write: consente la modifica o la creazione di dati dei servizi correlati alla posta elettronica.

Queste autorizzazioni sono fondamentali per garantire un controllo di accesso granulare e la sicurezza sulle risorse ACS.

Ottenere un token di controllo degli accessi in base al ruolo aggiuntivo

Per acquisire un token per ACS, è possibile usare MSAL (Microsoft Authentication Library). Ecco una guida dettagliata:

  1. Registrare un'applicazione in Azure AD: assicurarsi che l'app sia registrata in Azure AD.
  2. Installare MSAL: installare la libreria MSAL per la piattaforma , ad esempio Microsoft.Identity.Client per .NET.
  3. Configurare MSAL: configurare MSAL con l'ID client, l'ID tenant e il segreto client dell'applicazione.
  4. Acquisire un token: usare MSAL per acquisire un token con l'ambito necessario (https://communication.azure.com/.default).

Per istruzioni dettagliate ed esempi di codice, vedere la documentazione ufficiale di MSAL e la documentazione del token di accesso.

Richiesta HTTP di esempio per il rilascio del token di accesso ACS

Richiesta:

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"
  ]
}

Risposta:

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

Autenticazione del token di accesso utente

I token di accesso utente consentono alle applicazioni client di eseguire l'autenticazione direttamente in Servizi di comunicazione di Azure come utente o identità specifici.

Generazione/recupero di token di accesso utente

I token di accesso utente vengono generati dall'utente all'interno di un ambiente attendibile. La generazione di tali entità con Identity SDK di Servizi di comunicazione di Azure è il modo più semplice. Per altre informazioni, vedere creazione e gestione dei token di accesso utente.

Uso di un token di accesso utente in una richiesta

Dopo aver ottenuto un token di accesso utente appropriato, è possibile includerlo nelle richieste all'API REST di Servizi di comunicazione di Azure. A tale scopo, è necessario specificarlo all'interno dell'intestazione Authorization usando lo schema di autenticazione HTTP bearer Authorization: Bearer <token>.

Vedere anche

Per altre informazioni sull'autenticazione di Servizi di comunicazione di Azure, è anche possibile esaminare: