You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 9, 2022. It is now read-only.
Le Regole Tecniche SPID, così come modificate anche dall'avviso 1, impongono che i Service Provider usino HTTPS protetto con TLS 1.2 e che possano eventualmente supportare SSLv3.0 (tuttavia sconsigliabile) e TLS 1.1. Altri protocolli non sono ammessi.
Per come funziona SAML in realtà non abbiamo chiamate dirette tra IdP e SP (tranne che nel caso del logout IdP-initiated), quindi non c'è un flusso in cui possiamo inserire questa validazione e dobbiamo farla apposta.
Un'idea è quella di eseguire il controllo (su tutti gli endpoint degli SP configurati) ad ogni avvio del testenv. Questo coprirebbe lo scenario 1 descritto in #19.
Per lo scenario 2 (configurazione SP da interfaccia web) la validazione potrebbe avvenire all'atto della creazione di un nuovo SP, con un ulteriore tasto per forzare la rivalidazione.
Per lo scenario 3 (controllo dell'IdP di test via API da parte del portale di onboarding) idem ma via API anziché da interfaccia web.
import ssl
from urllib.request import urlopen
url="https://sp.fqdn.org"
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
# set other SSLContext options you might need
response = urlopen(url, context=ctx)
Tuttavia consiglio di gestire la validazione TLS/SSL con strumenti appositi e scorporati dalla suite di test SPID SAML2.
Riterrei più smart usare tool specializzati per competenza piuttosto che ideare soluzioni monolitiche
Le Regole Tecniche SPID, così come modificate anche dall'avviso 1, impongono che i Service Provider usino HTTPS protetto con TLS 1.2 e che possano eventualmente supportare SSLv3.0 (tuttavia sconsigliabile) e TLS 1.1. Altri protocolli non sono ammessi.
Per come funziona SAML in realtà non abbiamo chiamate dirette tra IdP e SP (tranne che nel caso del logout IdP-initiated), quindi non c'è un flusso in cui possiamo inserire questa validazione e dobbiamo farla apposta.
Un'idea è quella di eseguire il controllo (su tutti gli endpoint degli SP configurati) ad ogni avvio del testenv. Questo coprirebbe lo scenario 1 descritto in #19.
Per lo scenario 2 (configurazione SP da interfaccia web) la validazione potrebbe avvenire all'atto della creazione di un nuovo SP, con un ulteriore tasto per forzare la rivalidazione.
Per lo scenario 3 (controllo dell'IdP di test via API da parte del portale di onboarding) idem ma via API anziché da interfaccia web.
Cosa ne pensi @umbros?
The text was updated successfully, but these errors were encountered: