Abbiamo attivato il nostro primo servizio online con autenticazione SPID.
Per l’autenticazione al servizio occorre il Livello 2.
Con nostra sorpresa abbiamo constatato che con alcuni IdP, terminata la fase di autenticazione con successo, non restituiscono i metadati richiesti dal servizio. In particolare gli IdP che presentano il problema sono: SielteID, TIMid, SpidItalia.
Da un’analisi dei log dell’applicazione è emerso che nella struttura dati della risposta compaiono i nomi dei metadati ma non i valori dei metadati stessi, tranne quelli di gestione della interazione tra SP e IdP.
Il tipo di protocollo utilizzato è POST.
Chiedo se questo è un comportamento normale, vale a dire se gli IdP possono anche non valorizzare gli attributi a seconda del tipo di protocollo utilizzato oppure se è previsto che, indipendentemente dal protocollo (POST piuttosto che Redirect), gli IdP debbano spedire i valori dei metadati.
Ciao @Rossano_Guidetti,
parli per Comune di Carpi?
Il servizio è in fase di verifica e se ci sono problemi ve li comunichiamo. Non c’è nessun comportamento differente in base al binding, quindi verifichiamo la cosa.
Da una analisi più approfondita è emerso che gli IdP restituiscono i metadati ma poi Shibboleth non trovava il mapping.
Infatti nella Assertion di risposta, gli IdP che presentavano il problema aggiungono l’attributo NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:basic” mentre gli IdP che non presentavano il problema non aggiungono tale attributo.
E’ stato sufficiente configurare Shibboleth, file attribute-map.xml, mappando 2 volte i medesimi attributi di SPID, una volta senza l’attributo NameFormat e un’altra aggiungendo l’attributo NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:basic”.