Certificato autofirmato per un SSO SAML avviato da IdP

Question

Certificato autofirmato per un SSO SAML avviato da IdP

#1 da (7 voti)

5

Operiamo come fornitori di servizi in un'integrazione SSO SAML con i nostri clienti. Durante i test di sviluppo e di sviluppo, di solito scambiamo file di metadati e endpoint SSO.

Durante la formazione dei nostri metadati utilizziamo lo strumento da riga di comando openssl per generare un certificato autofirmato che impostiamo il valore del nodo X509Certificate su:

openssl genrsa -out server.pem 1024
openssl req -new -key server.pem -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt

Ora, la domanda , quando si va a production , dovremmo ottenere un certificato legittimo da una terza parte, oppure possiamo semplicemente rigenerare una nuova autofirmata certificato? Quale potenziale sicurezza o altre implicazioni potremmo avere se usassimo uno autofirmato?

Nota: noi, come fornitore di servizi, non inviamo messaggi SAML in questo tipo di installazione avviata da IdP.

Utilizzo di Python, Django e pacchetto djangosaml2 (se pertinente).

sso saml openssl certificates

posta alecxe 22.12.2016 - 18:56

fonte

1 risposta

Leggi altre domande sui tag sso saml openssl certificates

GPG perché la mia chiave di fiducia non è certificata con una firma attendibile? Sto utilizzando Android 4.1.2; include vulnerabilità note. L'installazione di un'immagine del firmware più recente richiederebbe tempo e fatica. Devo davvero farlo?

score 7 · Accepted Answer

TL; DR: I certificati autofirmati sono soddisfacenti e persino consigliati almeno in alcuni contesti. Utilizza tempi di validità lunghi per evitare problemi di rollover dei tasti e, se RSA, utilizza almeno le chiavi a 2048 bit.

SAML 2.0 include il certificato che deve essere utilizzato per la convalida della firma e come destinatario della crittografia come parte dei metadati SAML (tecnicamente, all'interno di EntityDescriptor ).

L'entità che utilizza i metadati dovrebbe convalidare i metadati in un modo "noto bene". Ciò potrebbe, ad esempio, essere scaricandolo solo su un canale fidato (ad esempio tramite HTTPS con normale convalida del certificato) o memorizzando una copia dei metadati localmente dopo averla ottenuta e verificata in un altro modo attendibile.

In pratica, i metadati tendono a essere anche firmati XML, il che fornisce un ulteriore livello di convalida dell'integrità oltre alla protezione offerta, ad esempio, da HTTPS. (Questa è una buona cosa, in particolare dato il numero di implementazioni che sembra richiedere il download e l'archiviazione manuale dei metadati in punti dove potrebbe essere facilmente modificato, accidentalmente o intenzionalmente. Almeno allora la firma XML non riesce a convalidare, causando il rifiuto dei metadati piuttosto dei metadati potenzialmente errati da utilizzare.)

Se non si riesce a scambiare i metadati SAML garantendo l'integrità di detti metadati, allora si ha un significativo problema di bootstrap, al punto che non sono nemmeno sicuro che sia possibile usare SAML in un modo sicuro. Se non ti puoi fidare del certificato che fa parte dei metadati, ciò implica che non puoi fidarti di alcun altro nei metadati uno , inclusi ad esempio gli URI dell'endpoint.

Se sei in grado di scambiare i metadati SAML assicurandone l'integrità, per definizione contiene un blob certificato attendibile, che è destinato (soggetto alle restrizioni indicate nei metadati) da utilizzare per:

Convalidare la firma su qualsiasi dato SAML in entrata, comprese le richieste di autenticazione e le risposte di autenticazione, da l'entità per cui i metadati sono generati
Funziona come chiave del destinatario per i dati SAML crittografati verso l'entità per cui i metadati sono generati (si noti che XML SAML crittografato non è supportato da tutte le implementazioni)

Poiché tale certificato (dai metadati attendibili) è per definizione attendibile, l'utilizzo di un certificato firmato da una CA non offre vantaggi significativi rispetto all'utilizzo di un certificato autofirmato. Non vi è quindi alcun motivo per utilizzare un certificato firmato dalla CA e qualche motivo per non (ad esempio, su Internet2 si consiglia di utilizzare certificati con almeno 10 anni di validità; non sono a conoscenza di alcuna CA commerciale fornendo certificati con quella lunga validità).

Per citare solo un esempio un po 'aneddotico, l'Active Directory Federation Services (ADFS) di Microsoft sembra essere perfettamente soddisfatto dei certificati autofirmati nei metadati SAML; ho fatto sul lato SP praticamente esattamente come nel test, con ADFS che funge da IdP.