Service Provider non configurato

[italia]

Service Provider non configurato

[alranel]

Secondo me sarebbe bene unificarli, soprattutto perché per poter scrivere degli unit test ci servirà una unica funzione validate_authnrequest() (nome di fantasia) che poi al suo interno può essere implementata anche in modo articolato usando varie strategie di validazione, ma che all'esterno dovrebbe restituire gli errori in un modo unitario. Partendo da questo presupposto puoi tranquillamente mostrarli con un solo template

[fmarco]

@alexrj questo bug è già gestito in nella PR #31 :)

[alranel]

@fmarco ho testato con il branch feature/issue-3-validazione-login (PR #31) ma ancora non va: non mi mostra nessun errore nella tabella errori.
Questa cosa deve far parte della validazione del tag <Issuer>.

[fmarco]

@alexrj partendo sempre dal branch feature/issue-3-validazione-login, dovresti vedere una tabella relativa all'errore("entity id pippo non registrato etc.").
Domanda: attualmente, sempre per via del flusso pysaml2, alcuni controlli vengono effettuati in seguito al parsing del messaggio e vengono generati errori mostrati in una schermata leggermente diversa. Conviene unificarli, per quanto possibile? Oppure validiamo prima la struttura generale del messaggio e poi ritorniamo eventuali errori più specifici in momenti diversi?

[alranel]

Ho appena provato con master inviando un Issuer non corrispondente all'entityID del metadata SP e viene accettato senza errori, visualizzo il form di login.

[fmarco]

@alexrj potresti allegarmi authnrequest e vers. di python?

[alranel]

AuthnRequest:

<saml2p:AuthnRequest Version="2.0" AssertionConsumerServiceIndex="0" ID="8388a090e3cc852d3764349b267fa569" AttributeConsumingServiceIndex="1" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" IssueInstant="2018-07-10T15:08:34Z" Destination="http://localhost:8088/sso" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" NameQualifier="https://localhost/xxxxxx">https://localhost/xxxxxx</saml2:Issuer><saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"></saml2p:NameIDPolicy><saml2p:RequestedAuthnContext Comparison="minimum"><saml2:AuthnContextClassRef>https://www.spid.gov.it/SpidL1</saml2:AuthnContextClassRef></saml2p:RequestedAuthnContext></saml2p:AuthnRequest>

Estratto dal metadata SP:

<md:EntityDescriptor 
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"  
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  
    entityID="https://localhost/"  
    ID="_681a637-6cd4-434f-92c3-4fed720b2ad8">

Python 2.7.10

[fmarco]

@alexrj questo errore è stato gestito in uno dei commit recenti, va però articolato meglio e spostato in nella tabella, giusto? (mi confermi intanto che vedi la schermata di errore generica contenente il messaggio "destinazione messaggio errata" ?)

[alranel]

Al momento esce questo:

[fmarco]

@alexrj pushato un fix, riprova pure

[fmarco]

@alexrj hai avuto modo di riprovare?

[alranel]

Confermo che ora appare la seguente schermata di errore:

[alranel]

Tuttavia c'è un problema.

Se mando una AuthnRequest che contiene un Issuer sconosciuto, e chiedo un AttributeConsumingService ottengo questo errore:

Evidentemente non riuscendo a trovare il Service Provider compone una lista vuota di valori attesi e quindi questa validazione fallisce. Però questo messaggio di errore è molto fuorviante. La validazione dovrebbe andare in ordine di priorità e cominciare dall'Issuer perché molte delle validazioni successive dipendono da esso.

[fmarco]

@alexrj pushato fix e test su master

[alranel]

Confermo