Differenze tra le versioni di "RolloverCertificati"
Riga 42: | Riga 42: | ||
Alla fine del passo 5 sarà: | Alla fine del passo 5 sarà: | ||
− | <CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem"/> | + | <CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem"/><br /> |
− | |||
− | |||
===Identity Provider=== | ===Identity Provider=== | ||
Versione attuale delle 11:48, 29 mar 2021
Cambio dei certificati in Shibboleth (Certificate Rollover)
Questa pagina descrive il processo di rollover dei certificati per entità Shibboleth. La procedura descritta di seguito consente di sostituire i certificati senza alcuna interruzione del servizio.
Service Provider
Le seguenti informazioni sono tratte dalla documentazione ufficiale Shibboleth SP3.
All'interno di un SP Shibboleth possono essere configurate 2 tipologie di chiave: signing key e encryption key. E' altresì possibile che sia usata una sola chiave per entrambi gli scopi.
Sostituzione della signing key
Nel caso sia necessario sostituire la chiave di signing basterà aggiungere ai metadata del SP in Federazione la nuova chiave ed aspettare che l'informazione si propaghi a tutte le entità (di solito avviene in 24h). Aspettato il tempo necessario basterà aggiornare la configurazione del SP per usare la nuova signing key.
Sostituzione della encryption key o della chiave unica
Nel caso sia necessario sostituire la chiave di encryption o la singola chiave usata per entrambi gli scopi (signing/encryption) è necessario seguire un apposito processo:
- creare un nuovo certificato e aggiornare la configurazione del SP includendo la nuova chiave indicando esplicitamente
use="encryption"
. - aggiungere via Registry il nuovo certificato ai metadata del SP (istruzioni per Registry) e attendere 24h per la propagazione.
- aggiornare la configurazione del SP invertendo il parametro
use="encryption"
dalla nuova chiave alla vecchia. - rimuovere via Registry il vecchio certificato dai metadata del SP (istruzioni per Registry) e attendere 24h per la propagazione.
- aggiornare la configurazione del SP rimuovendo la vecchia chiave.
Come semplice esempio, se la configurazione iniziale fosse la seguente:
<CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
Dopo il passo 1 la configurazione sarà:
<CredentialResolver type="Chaining"> <CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem" use="encryption"/> <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/> </CredentialResolver>
E dopo il passo 3:
<CredentialResolver type="Chaining"> <CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem"/> <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem" use="encryption"/> </CredentialResolver>
Alla fine del passo 5 sarà:
<CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem"/>
Identity Provider
Le seguenti informazioni sono tratte dalla documentazione ufficiale Shibboleth IdP3
All'interno di un IdP Shibboleth possono essere configurate varie tipologie di chiave: Signing Key, Back-Channel TLS Key, Encryption Key o una stessa chiave per tutti gli scopi.
Per maggiori approfondimenti sull'uso delle chiavi in SAML: A Primer on SAML Keys and Certificates
Sostituzione della signing key e back-channel TLS Key
Nel caso sia necessario sostituire la signing key o la back-channel TLS Key basterà aggiungere ai metadata del IdP in Federazione la nuova chiave (use="signing") ed aspettare che l'informazione si propaghi a tutte le entità (di solito avviene in 24h). Aspettato il tempo necessario basterà aggiornare la configurazione del IdP per usare la nuova signing key.
Sostituzione della encryption key
Nel caso sia necessario sostituire la encryption key la configurazione di Idp Shibboleth v3 suggerisce nel file credentials.xml la corretta modalità di procedere attraverso il blocco dei commenti:
For key rollover, uncomment and point to your original keypair, and use the one above to point to your new keypair. Once metadata has propagated, comment this one out again.
<util:list id="shibboleth.DefaultEncryptionCredentials"> <bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean" p:privateKeyResource="%{idp.encryption.key}" p:certificateResource="%{idp.encryption.cert}" p:entityId-ref="entityID" /> <bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean" p:privateKeyResource="%{idp.encryption.key.2}" p:certificateResource="%{idp.encryption.cert.2}" p:entityId-ref="entityID" /> </util:list>
In pratica dovrà essere decommentato il bean
indicante la idp.encryption.key.2 configurando in esso la vecchia chiave e nel primo bean
la nuova chiave.
Dopo aver aggiunto via Registry il nuovo certificato ai metadata del IdP (istruzioni per Registry: qui) attendere 24h per la propagazione e commentare nuovamente il secondo bean
(di fatto rimuovendo la vecchia chiave).
Aggiornare infine il Registry per rimuovere la vecchia chiave.