Closed francescm closed 3 years ago
E' sempre Shibboleth SP che fa l'enforcing, ma dovendolo fare al livello di Location
, lo fa tramite direttiva Apache piuttosto che da configurazione.
In alternativa credo si possa fare anche da configurazione tramite il Request Mapper, ma su httpd la scelta preferita è la direttiva sul web server (cosa che invece non si può fare su IIS ad esempio)
Con qualcosa del genere:
<RequestMapper type="Native">
<RequestMap>
<Host name="domain.ext">
<Path name="/highsecurity" authnContextClassRef="https://www.spid.gov.it/SpidL2" />
</Host>
</RequestMap>
</RequestMapper>
Fixed by #33
da quel che ho capito da: https://wiki.shibboleth.net/confluence/display/SP3/Requiring+Multi-Factor+Authentication non è shibboleth-sp che fa l’enforcing del livello di sicurezza, ma il web server. shibboleth-sp produce una richiesta che richiede un certo livello di sicurezza (e di solito questo è sufficiente) ma per ripararsi dal caso descritto nel test 94 bisogna anche modificare il virtual host apache2 che verifichi la risposta:
Ora abbiamo due problemi: 1) questa impostazione è per una certa Location per tutta la suite di test. Se ci sono test che producono una risposta con
<saml:AuthnContextClassRef>https://www.spid.gov.it/SpidL1</saml:AuthnContextClassRef>
riceveranno un bel 401; 2) sembra che spid_sp_test abbia una logica invertita per il test 94: [94] Elemento AuthContextClassRef impostato su https://www.spid.gov.it/SpidL1. Risultato atteso: fare attenzione al livello richiesto sulla request.: [http status_code: 401] probabilmente il test “fare attenzione ...” fa pensare che l’esito debba essere un 200 invece di un 401. (edited)