Servizi Web e ACS

Aggiornamento: 19 giugno 2015

Si applica a: Azure

Di seguito sono riportati i partecipanti dello scenario di base in cui un servizio Web è integrato con Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS):

• Applicazione relying party - Il servizio Web.

• Client - Un client che tenta di eseguire l'accesso al servizio Web.

• Provider di identità - Un sito o un servizio in grado di autenticare il client.

• ACS : partizione di ACS dedicata all'applicazione relying party.

Nel primo scenario, tuttavia, si presuppone che il client non possa accedere a un browser e che sia in esecuzione come sistema autonomo (senza alcun intervento diretto di un utente nello scenario).

Il client deve ottenere un token di sicurezza emesso da ACS per accedere al servizio. Questo token è un messaggio firmato da ACS all'applicazione, con un set di attestazioni sull'identità del client. ACS non rilascia un token a meno che il client non dimostri prima la propria identità.

In uno scenario di servizio Web e ACS, un client può dimostrare la propria identità nei modi seguenti:

• Eseguendo l'autenticazione diretta con ACS e usando i tipi di credenziali dell'identità del servizio ACS

  Nota

  Per altre informazioni sulle identità del servizio, vedere Identità del servizio.

  La figura seguente illustra lo scenario del servizio Web con il client che dimostra la propria identità con i tipi di credenziali delle identità del servizio ACS.

  

  1. Il client esegue l'autenticazione con ACS usando uno dei tipi di credenziali dell'identità del servizio ACS. In ACS può trattarsi di un token SWT (Simple Web Token) firmato con una chiave simmetrica, un certificato X.509 o una password. Per altre informazioni, vedere Identità del servizio.

  2. ACS convalida le credenziali ricevute, inserisce le attestazioni di identità ricevute nel motore regole ACS, calcola le attestazioni di output e crea un token che contiene tali attestazioni.

  3. ACS restituisce il token emesso da ACS al client.

  4. Il client invia il token rilasciato da ACS all'applicazione relying party.

  5. L'applicazione relying party convalida il token emesso da ACS e quindi restituisce la rappresentazione della risorsa richiesta.

• Mediante la presentazione di un token di sicurezza rilasciato da un'altra autorità emittente attendibile (provider di identità) che ha eseguito l'autenticazione del client

  La seguente figura illustra lo scenario del servizio Web in cui il client dimostra la propria identità mediante un token di sicurezza rilasciato da un provider di identità.

  

  1. Il client esegue l'accesso al provider di identità, ad esempio inviando le credenziali.

  2. Dopo l'autenticazione del client, il provider di identità rilascia un token.

  3. Il provider di identità restituisce il token al client.

  4. Il client invia il token rilasciato dal provider di identità a ACS.

  5. ACS convalida il token rilasciato dal provider di identità, inserisce i dati nel token rilasciato dal provider di identità al motore regole ACS, calcola le attestazioni di output e crea un token che contiene tali attestazioni.

  6. ACS rilascia un token al client.

  7. Il client invia il token rilasciato da ACS all'applicazione relying party.

  8. L'applicazione relying party convalida la firma nel token rilasciato da ACS e convalida le attestazioni nel token rilasciato da ACS.

  9. L'applicazione relying party restituisce la rappresentazione della risorsa richiesta.

Vedere anche

Concetti

Servizio di controllo di accesso 2.0
Introduzione con ACS
Procedura: Creare il primo servizio di ASP.NET in grado di riconoscere attestazioni tramite ACS