Invalid Response - anomalia AttributeConsumingService

[sweeperpm]

Buongiorno,
stiamo riscontrando un'anomalia con la nuova versione v1.1.0 del docker, non riscontrata nella versione precedente (0.4.0).
Utilizzando l'IdP Poste funziona correttamente, mentre provando con Infocert abbiamo il seguente errore:

Abbiamo verificato nel dettaglio e l'IdP non ritorna l'attributo digitalAddress, quindi non c'è il match con quanto definito nel metadata:
<md:AttributeConsumingService index="1"> <md:ServiceName xml:lang="it">Cittadino</md:ServiceName> <md:RequestedAttribute Name="spidCode"/> <md:RequestedAttribute Name="name"/> <md:RequestedAttribute Name="familyName"/> <md:RequestedAttribute Name="placeOfBirth"/> <md:RequestedAttribute Name="dateOfBirth"/> <md:RequestedAttribute Name="gender"/> <md:RequestedAttribute Name="fiscalNumber"/> <md:RequestedAttribute Name="email"/> <md:RequestedAttribute Name="idCard"/> <md:RequestedAttribute Name="mobilePhone"/> <md:RequestedAttribute Name="address"/> <md:RequestedAttribute Name="digitalAddress"/> </md:AttributeConsumingService>

Stesso discorso con l'IdP di test (Destination="https://idp.spid.gov.it/samlsso").

Abbiamo settato correttamente gli ACS in docker-bootstrap.sh, metadata pubblico e attr-check.xml quindi non riusciamo capire dove possa essere l'anomalia.
Abbiamo letto anche la issue #16 , ma era relativa alla versione 1.0.0 e risolveva per il test, ma non dovrebbe verificarsi in produzione.

Potete darci indicazioni?

Grazie per l'assistenza.

[sweeperpm]

@psmiraglia Buongiorno,
ha avuto modo di valutare la mia richiesta di assistenza?
Ho provato anche con IDP di Test, usando il workaround spiegato nella issue 16, ma abbiamo lo stesso problema, ovvero non torna il digitalAddress.

Grazie.

[psmiraglia]

Salve @scubla88, il problema sta nel fatto che il container si aspetta nella risposta (in questo caso) l'attributo digitalAddress ma l'identity provider selezionato non lo include. Questo fa fallire i test sugli attributi implementati da Shibboleth come indicato qui.

Purtroppo alcuni identity provider hanno interpretato male le specifiche e non tutti gestiscono allo stesso modo il ritorno di attributi non valorizzati. In particolare, alcuni identity provider includono nella risposta un elemento <saml:Attribue> con figlio <saml:AttributeValue> self-closed senza valore

<saml:Attribute Name="digitalAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" />
</saml:Attribute>

altri invece includono nella risposta solo gli elementi <saml:Attribue> valorizzati. Questa e' una questione in corso di discussione e per maggiorni dettagli puo' contattare spid.tech@agid.gov.it.

[sweeperpm]

Buongiorno @psmiraglia , ti ringrazio per la risposta.
Se dovessimo aggiornare il metadata togliendo l'attributo digitalAddress è sufficiente?
Oppure dobbiamo comunicare la variazione del metadata tramite issue su github (progetto spid)?

Grazie.

[psmiraglia]

Buongiorno @psmiraglia , ti ringrazio per la risposta.
Se dovessimo aggiornare il metadata togliendo l'attributo digitalAddress è sufficiente?

In linea di massima, osservando il principio del minimum disclosure, dovreste richiedere solo e solamente gli attributi di cui avete realmente bisogno. Se digitalAddress non serve, allora il fatto di rimuoverlo potrebbe essere un valido workaround.

Oppure dobbiamo comunicare la variazione del metadata tramite issue su github (progetto spid)?

In generale, ogni variazione che implica un feedback da parte degli identity provider va sempre comunicata via issue. La modifica degli AttributeConsumingService rientra in questa categoria.

[sweeperpm]

@psmiraglia Grazie per le indicazioni.
Al momento solo con Poste funziona correttamente, mentre gli altri che siamo riusciti a testare (Infocert e Test) hanno questo errore.
Sapete dirci quali altri IdP riscontrano lo stesso problema per digitalAddress?

[psmiraglia]

Sapete dirci quali altri IdP riscontrano lo stesso problema per digitalAddress?

Per queste informazioni dovete contattare spid.tech@agid.gov.it

[sweeperpm]

@psmiraglia grazie, provvediamo a segnalare il problema.