Certificati e chiavi

Aggiornamento: 19 giugno 2015

Si applica a: Azure

Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS) offre due modi diversi per firmare e crittografare i token: certificati X.509 con una chiave privata e 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 certificati e chiavi di firma dei token, crittografia e decrittografia, usare il servizio di gestione ACS o il portale di gestione ACS.

Firma di token

ACS firma tutti i token di sicurezza che rilascia con un certificato X.509 (con una chiave privata) o una chiave simmetrica a 256 bit. La scelta di un tipo di credenziale di firma (certificato o chiave) dipende dal formato di token selezionato per i token rilasciati da ACS. Per altre informazioni, vedere "Firma di token" in Relying Party Applications. 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.

Chiavi e certificati dedicati o specifici dello spazio dei nomi

È possibile configurare un certificato di firma o una chiave simmetrica in modo che venga usato per l'intero spazio dei nomi Controllo di accesso o solo per una particolare applicazione relying party nello spazio dei nomi. La differenza è la seguente:

• Controllo di accesso spazio dei nomi : quando viene configurato un certificato o una chiave di firma per l'intero spazio dei nomi Controllo di accesso, ACS usa il certificato o la chiave per firmare i token per tutte le applicazioni relying party in questo spazio dei nomi che non hanno un certificato o una chiave specifici dell'applicazione. Viene usato anche un certificato con ambito spazio dei nomi per firmare i metadati di WS-Federation ACS.

• Dedicato: se si configura un certificato di firma o una chiave da usare per una determinata applicazione relying party, ACS usa il certificato di firma o la chiave solo per firmare i token recapitati all'applicazione relying party specificata.

  Se si crea o si immette una chiave simmetrica dedicata, ACS usa la chiave dedicata per firmare i token per l'applicazione. Se la chiave dedicata scade e non viene sostituita, ACS usa la chiave simmetrica per lo spazio dei nomi Controllo di accesso per firmare i token per l'applicazione.

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 di ACS WS-Federation, che consente alle applicazioni relying party di automatizzare la configurazione. Le chiavi pubbliche dei certificati assegnati solo a una particolare applicazione relying party non sono presenti nei metadati di ACS WS-Federation e vengono usate solo quando è necessario il controllo indipendente su un certificato di firma di un'applicazione relying party.

Certificati e chiavi primari

In ACS è possibile gestire diversi certificati e chiavi, ma usare solo certificati e chiavi designati per firmare i 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. Quando si esegue questa operazione, ACS abbassa automaticamente le chiavi o i certificati primari esistenti a quelli 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. Tuttavia, se nessuno dei certificati (o delle chiavi) è primario, ACS usa il certificato non primario con la prima data di inizio valida.

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

Date di validità e di scadenza delle chiavi di firma

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.

Crittografia dei token

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

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 di questo tipo, tutti i token rilasciati da ACS per questa applicazione relying party 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 con estensione cer). Il token dell'applicazione relying party decrittografa il token usando una chiave privata per tale certificato X.509. Per altre informazioni, vedere "Crittografia token" in Applicazioni relying party.

Decrittografia dei token

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

Certificati di decrittografia del token primario

È possibile gestire più certificati di decrittografia di token per un'applicazione relying party o Controllo di accesso spazio dei nomi. Quando si designa un certificato come primario, ACS usa tale certificato per decrittografare i token da WS-Federation provider di identità e usa 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. Quando si esegue questa operazione, ACS abbassa automaticamente i certificati di decrittografia primaria esistenti a quelli non primari.

Limiti di ACS per i file di certificato X.509

In ACS, i certificati X.509 che contengono solo una chiave pubblica (file con estensione cer) possono essere usati quando si crea un'identità del servizio, convalidando una firma di un provider di identità o crittografando i token SAML. I file di certificato X.509 che contengono solo una chiave pubblica (file con estensione cer) devono essere codificati con DER da usare con ACS. I file di certificato con codifica Base 64 non sono attualmente supportati. Il caricamento di un certificato con codifica Base64 in ACS genererà 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 funzionerà con i certificati rilasciati da un'autorità di certificazione privata.

Acquisizione di un certificato X.509

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.

Generare un certificato Self-Signed: è possibile generare un certificato autofirmato da usare con ACS. Se si esegue un sistema operativo basato su Windows, è possibile usare MakeCert.exe, uno strumento incluso in Microsoft Windows Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=214104) per generare un certificato autofirmato.

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 spazio dei nomi Controllo di accesso.

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

Esportazione di un certificato autofirmato

Queste istruzioni illustrano come esportare una certificazione autofirmato da un computer che esegue Windows 8, Windows Server 2012, o .

Per esportare un certificato autofirmato

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.

Date valide di chiavi e certificati

ACS valuta le date di inizio e di fine (e le ore di data) dei certificati e delle chiavi nell'ora UTC (Coordinated Universal Time). Di conseguenza, ACS potrebbe considerare le chiavi e i certificati non validi anche quando sono 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, il servizio contenitore di Azure potrebbe non emettere un token perché la chiave o il certificato non è ancora valido.

Vedere anche

Concetti

Componenti di ACS 2.0
Applicazioni relying party
Linee guida per la gestione dei certificati e delle chiavi