Questa pagina è stata utile?
I suggerimenti relativi al contenuto di questa pagina sono importanti. Comunicaceli.
Altri suggerimenti?
1500 caratteri rimanenti
Certificati e chiavi

Certificati e chiavi

Pubblicato: aprile 2011

Aggiornamento: giugno 2015

Si applica a: Azure

Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS) offre due distinte modalità per la firma e la crittografia dei token: i certificati X.509 con una chiave privata e le chiavi simmetriche a 256 bit. È possibile configurare ciascun certificato o ciascuna chiave per la firma di token di specifiche applicazioni relying party o di tutte le applicazioni relying party nello spazio dei nomi ed è possibile specificare se i certificati e le chiavi sono di tipo primario o secondario. Per aggiungere e configurare i certificati e le chiavi per la firma, la crittografia e la decrittografia dei token, usare il servizio di gestione o il portale di gestione ACS.

ACS firma tutti i token di sicurezza che rilascia mediante un certificato X.509 (con una chiave privata) o una chiave simmetrica a 256 bit. La scelta del tipo di credenziale di firma (certificato o chiave) dipende dal formato scelto per i token rilasciati da ACS. Per altre informazioni, vedere la sezione "Token signing" in Applicazioni relying party. Quando si sceglie il tipo di credenziale di firma da creare, tenere presente quanto segue:

  • I token SAML vengono firmati con i certificati X.509. SAML è il formato di token predefinito usato dalle applicazioni basate su Windows Identity Foundation (WIF). I token SAML possono essere rilasciati su più protocolli, ad esempio WS-Federation e WS-Trust.

  • I token SWT vengono firmati con le chiavi simmetriche a 256 bit. I token SWT possono essere rilasciati su più protocolli, ad esempio OAuth WRAP e WS-Federation.

  • I token JWT possono essere firmati con i certificati X.509 o con le chiavi simmetriche a 256 bit. I token JWT possono essere rilasciati su più protocolli, ad esempio WS-Federation, WS-Trust e OAuth 2.0.

È possibile configurare un certificato di firma o una chiave simmetrica in modo che possa essere usata per l'intero Spazi dei nomi controllo di accesso o per un'applicazione relying party specifica nello spazio dei nomi. La differenza è la seguente:

  • Spazi dei nomi controllo di accesso - Quando si configura un certificato o una chiave di firma per l'intero Spazi dei nomi controllo di accesso, ACS usa tale certificato o chiave per firmare i token recapitati a tutte le applicazioni relying party dello spazio dei nomi che non hanno un certificato o una chiave specifica dell'applicazione. Un certificato che ha come ambito lo spazio dei nomi viene usato anche per la firma dei metadati WS-Federation di ACS.

  • Dedicato - Se si configura un certificato o una chiave di firma da usare per un'applicazione relying party specifica, ACS usa tale certificato o chiave solo per firmare i token recapitati a tale applicazione relying party.

    Se si crea o si immette una chiave simmetrica dedicata, ACS usa la chiave dedicata per firmare i token dell'applicazione. Se la chiave dedicata scade e non viene sostituita, ACS usa la chiave simmetrica dello Spazi dei nomi controllo di accesso per firmare i token dell'applicazione.

noteNota
  • Come procedura consigliata per la sicurezza, quando si usano le chiavi simmetriche è opportuno creare una chiave dedicata per ogni applicazione relying party. Un certificato X.509 può essere condiviso in sicurezza da più applicazioni in uno Spazi dei nomi controllo di accesso.

  • Quando si aggiunge un'applicazione relying party gestita da Microsoft a uno spazio dei nomi gestito, ad esempio se si aggiunge un'applicazione relying party di Service Bus a uno spazio dei nomi di Service Bus, non usare chiavi o certificati (dedicati) specifici dell'applicazione. Selezionare, invece, l'opzione di ACS che consente di usare le chiavi e i certificati configurati per tutte le applicazioni nello spazio dei nomi gestito. Per tutte le altre applicazioni relying party, usare chiavi e certificati specifici dell'applicazione. Per altre informazioni, vedere Spazi dei nomi gestiti.

  • Quando si configura un'applicazione relying party che usa il certificato X.509 dello Spazi dei nomi controllo di accesso per firmare token JWT, vengono visualizzati sulla pagina dell'applicazione relying party nel portale di gestione ACS collegamenti al certificato e alla chiave dello Spazi dei nomi controllo di accesso. ACS, tuttavia, usa solo il certificato dello spazio dei nomi per firmare i token dell'applicazione relying party.

I certificati di firma in genere vengono usati per firmare i token relativi a tutte le applicazioni relying party in uno spazio dei nomi. Il componente chiave pubblica di un certificato di firma dello spazio dei nomi viene pubblicato nei metadati WS-Federation di ACS e questo consente alle applicazioni relying party di automatizzare la configurazione. Le chiavi pubbliche dei certificati assegnate solo a un'applicazione relying party specifica non sono presenti nei metadati WS-Federation di ACS e vengono usate solo se è necessario un controllo indipendente su un certificato di firma dell'applicazione relying party.

In ACS possono essere presenti più chiavi e certificati, ma è possibile usare solo quelli designati per la firma dei token. Le chiavi e i certificati designati per la firma vengono definiti primari.

Per designare una chiave o un certificato come primario, selezionare l'elemento Make primary nella pagina relativa alla chiave o al certificato. Per designare un certificato differente come primario, selezionare l'elemento Make primary nella pagina relativa a tale chiave o certificato. Per effetto di questa operazione, ACS automaticamente abbassa di livello eventuali chiavi o certificati primari modificandoli in non primari.

Quando almeno una chiave o un certificato è primario, le chiavi e i certificati non primari non vengono usati per firmare finché non vengono alzati di livello dall'amministratore allo stato primario, anche se la chiave o il certificato primario non è valido o è scaduto. Se tuttavia nessuno dei certificati (o delle chiavi) è primario, ACS usa il certificato non primario con la data di inizio valida più recente.

Il componente chiave pubblica dei certificati primari e non primari viene pubblicato nei metadati WS-Federation di ACS per consentire il rollover dei certificati a livello di codice. ACS usa tuttavia solo le chiavi e i certificati primari per firmare i token.

Quando si aggiungono chiavi di firma simmetriche a 256 bit, è inoltre necessario specificare una data di validità e una data di scadenza. La prima indica quando la chiave diventa valida, mentre la seconda indica quando la chiave scade e non può più essere usata per firmare i token.

In ACS è possibile scegliere di crittografare qualsiasi token SAML 1.1 o SAML 2.0 rilasciato da ACS alle applicazioni relying party.

ImportantImportante
ACS non supporta la crittografia dei token SWT o JWT.

La crittografia dei token è necessaria per i servizi Web che usano token proof-of-possession sul protocollo WS-Trust. Se si usa ACS per gestire l'autenticazione per un'applicazione relying party, tutti i token rilasciati da ACS per tale applicazione devono essere crittografati. In tutti gli altri scenari la crittografia dei token è facoltativa.

ACS crittografa i token SAML usando un certificato X.509 contenente una chiave pubblica (file cer). Il token dell'applicazione relying party decrittografa il token usando una chiave privata per tale certificato X.509. Per altre informazioni, vedere la sezione "Token encryption" in Applicazioni relying party.

ACS può accettare token crittografati da provider di identità WS-Federation, ad esempio . Il provider di identità WS-Federation riceve la chiave pubblica di un certificato X.509 quando importa i metadati WS-Federation da ACS e usa questa chiave pubblica per crittografare il token di sicurezza inoltrato a ACS. Quest'ultimo quindi decrittografa il token usando la chiave privata del certificato X.509. Per altre informazioni, vedere Procedura: configurare ADFS 2.0 come provider di identità.

Per un'applicazione relying party o uno Spazi dei nomi controllo di accesso è possibile disporre di più certificati di decrittografia dei token. Se un certificato viene designato come primario, ACS usa tale certificato per decrittografare i token dei provider di identità WS-Federation e usa i certificati non primari solo se il tentativo di usare il certificato primario ha esito negativo.

Per designare un certificato di decrittografia come primario, selezionare l'elemento Make primary nella pagina relativa a tale certificato. Per designare un certificato differente come primario, selezionare l'elemento Make primary nella pagina relativa a tale certificato. Per effetto di questa operazione, ACS automaticamente abbassa di livello eventuali certificati di decrittografia primari esistenti modificandoli in non primari.

In ACS i certificati X.509 che contengono solo una chiave pubblica (file cer) possono essere usati quando si crea un'identità del servizio, si convalida la firma di un provider di identità o si crittografano i token SAML. Per poter usare i file di certificato X.509 contenenti solo una chiave pubblica (file cer) con ACS il formato di codifica dei file deve essere DER. I file di certificato con codifica Base 64 non sono attualmente supportati. Se si carica un certificato con codifica Base 64 in ACS, viene restituito un errore di convalida quando ACS riceve un token in ingresso che richiede tale certificato.

In ACS i certificati X.509 devono essere autofirmati o firmati e concatenati direttamente a un'autorità di certificazione pubblica. ACS non funziona con i certificati rilasciati da un'autorità di certificazione privata.

noteNota
I certificati X.509 importati in ACS non devono essere scaduti.

Per ottenere un certificato X.509 per la firma, la crittografia o la decrittografia dei token, è possibile procedere in diversi modi. Il metodo da usare dipende dai propri requisiti e dagli strumenti disponibili nella propria organizzazione.

Autorità di certificazione commerciale - È possibile acquistare un certificato X.509 da un'autorità di certificazione commerciale.

Generazione di un certificato autofirmato - È possibile generare il proprio certificato autofirmato da usare con ACS. Se si esegue un sistema operativo Windows, per generare un certificato autofirmato è possibile usare MakeCert.exe, uno strumento incluso in Microsoft Windows Software Development Kit (http://go.microsoft.com/fwlink/?LinkID=214104).

Il seguente comando, ad esempio, genera un certificato autofirmato nel proprio archivio certificati personale.

MakeCert.exe -r -pe -n "CN=<service_namespace_name>.accesscontrol.windows.net" -sky exchange -ss my -len 2048 –e <1 year from today>

dove <service_namespace_name> è il nome dello Spazi dei nomi controllo di accesso.

È quindi possibile esportare la chiave privata dall'archivio personale come file pfx e caricarla in ACS mediante il portale di gestione.

Queste istruzioni spiegano come esportare un certificato autofirmato da un computer che esegue Windows 8, Windows Server 2012, o .

  1. Avviare MMC.exe e aggiungere lo snap-in Certificati alla console MMC.

  2. Fare doppio clic su Certificati - Utente corrente, Personale, quindi Certificati.

  3. Fare clic con il pulsante destro del mouse su un certificato, fare clic su Tutte le attività, quindi scegliere Esporta.

  4. Nella pagina iniziale dell'Esportazione guidata certificati fare clic su Avanti.

  5. Nella pagina Esportazione della chiave privata con il certificato selezionare Sì, esporta la chiave privata, quindi fare clic su Avanti.

  6. Nella pagina Formato file di esportazione selezionare Scambio di informazioni personali – PKCS #12 (*.PFX).

  7. Nei campi Password immettere una password e una password di conferma, quindi fare clic su Avanti.

  8. Nel campo Nome file immettere il percorso e il nome del file con estensione pfx, quindi fare clic su Avanti.

  9. Fare clic su Fine.

ACS valuta le date di inizio e fine (e i valori di data e ora) di chiavi e certificati in Coordinated Universal Time (UTC). ACS può quindi identificare come non validi chiavi e certificati anche se risultano validi nell'ora locale del computer locale o in un altro fuso orario.

Per garantire che la chiave o il certificato sia valido immediatamente, regolare le date al valore UTC. In caso contrario, è possibile che ACS non riesca a rilasciare un token perché la chiave o il certificato non è ancora valido.

Vedere anche

Aggiunte alla community

AGGIUNGI
Mostra:
© 2015 Microsoft