Salve,
Stiamo effettuando dei test sull’accesso tramite identità professionali e giuridiche, da linee guida (spid avviso n 18) risulta necessario inserire nell’authentication request la seguente parte: <samlp:Extensions xmlns:spid=“https://spid.gov.it/saml-extensions”> spid:PurposePF</spid:Purpose> </samlp:Extensions>, il sistema ci risponde con un errore sulla posizione di tale elemento all’interno della request; qualcuno ha a disposizione un’esempio di request corretta con tale elemento o sa qual è il giusto posizionamento?
Cosa intendi per “sistema”?
Se non sbaglio, il tag extension deve essere figlio diretto della radice <AuthnRequest>.
Non mi pare vi siano vincoli sull’ordine, ma , se avete possibilità, per questioni di leggibilità io lo inserirei come ultimo figlio.
Ciao,
grazie per la risposta.
Stavamo effettuando dei test tramite il validator SPID SAML Check.
Abbiamo risolto il problema ponendo il tag <samlp:Extensions> contenente <spid:Purpose> come figlio diretto di <AuthnRequest> posizionandolo immediatamente dopo il tag <saml:Issuer>.
Ci chiedevamo inoltre se:
nella Response esista un attributo relativo al tipo di identità che sta effettuando l’accesso (ID Persona Giuridica oppure ID uso professionale
Persona Giuridica etc)
è davvero necessario diversificare la procedura di autenticazione tramite spid per le diverse tipologie di identità SPID?
In merito alla seconda domanda, puoi combinare le richieste in base allo schema definito nella tabella a pag. 2 del citato Avviso SPID n°18 v2.
Ad esempio, puoi avere un unico servizio che accetta identità persona fisica uso professionale e persona giuridica uso professionale (Purpose P).
In merito alla prima, nel caso di purpose che accettano più di una tipologia di identità, credo tu lo possa inferire dalla valorizzazione o mancata valorizzazione di alcuni attributi.
Facendo riferimento alla citata tabella:
Cod. Fiscale persona fisica —> Identità tipo 1
Cod. Fiscale persona fisica + partita iva —> Identità tipo 3
Cod. Fiscale persona giuridica ----> Identità tipo 2
Cod. Fiscale persona giuridica + Cod. Fiscale persona fisica ----> Identità tipo 4
Salve a tutti.
Qualcuno è riuscito a implementare, fino in fondo, l’autenticazione con gli SPID di tipo professionale?
Noi abbiamo implementato la request secondo quanto indicato (aggiunta del TAG “Purpose”) ma otteniamo da Aruba, unico IdP con cui abbiamo uno SPID 4 e ancor prima di poter inserire le credenziali di accesso, l’errore seguente:
“Autenticazione SPID fallita: L’accesso al sito è limitato alle identità di tipo PERSONA_GIURIDICA_USO_PROFESSIONALE. Per maggiori informazioni ti invitiamo a consultare l’assistenza aprendo un ticket su assistenza.aruba.it”.
Altri IdP sembrano invece ignorare il TAG passato e tutto funziona perfettamente non passando il valore “Purpose”.
Non ho capito bene quale valore di purpose passi (secondo le definizioni della tabella dell’Avviso SPID n°18), nè quando rilevi un problema (se dopo l’invio dell’AuthnRequest o dopo la challenge), nè che tipo di identità stai cercando di usare.
Ciao Antonio Giovanni, lo stesso errore lo ottengo con ognuna delle possibili occorrenze indicate nell’avviso 18 v2
[Description(“3;4”)] => P
[Description(“2;4”)] => LP
[Description(“4”)] => PG
[Description(“3”)] => PF
[Description(“2;3;4”)] => PX
Formalmente lo XML risulta valido con tutti i validatori a cui lo abbiamo passato.
Il tag è così fatto (il namespace è dichiarato in testa alla request):
Noi abbiamo risolto.
Aruba aveva sicuramente un problema sui suoi sistemi cha ha risolto e ora non abbiamo nessun problema a passare le credenziali di uno SPID tipo 2 (business).
Lato nostro avevamo un problema nelle dichiarazioni e, in particolare, nella dichiarazione del namespace “spid”.
Per avere tutto a posto:
il tag Purpose deve essere passato come avevo scritto:
Salve,
scusate se riesumo il thread ma ho un dubbio riguardo alla questione Persona Fisica/Giuridica :
La mia azienda sta facendo richiesta per diventare SOGGETTO AGGREGATORE e avrebbe la necessità di consentire l’accesso tramite SPID sia a normali cittadini (Persona Fisica) sia ad associazioni (Persona Giuridica ad uso Professionale).
Nel documento citato non mi sembra ci sia un valore dell’attributo “Purpose” che lo consenta.
Non riesco a capire come fare ad implementare questa eventualità, potreste darmi qualche consiglio per favore?
Ciao Giorgio,
come avevo scritto nella request dovrete specificare il TAG “Purpose”.
Se assente la richiesta è per avere, di default, i tipi 1 e 3 dello SPID (da non confondere con il livello).
A esempio:
Ciao Stefano,
graziemille per la risposta, avevo letto del tag “Purpose” ma, come ho scritto nel post, non ho capito come andrebbe valorizzato poiché mi servirebbe la combinazione Persona Fisica e Persona Giuridica Professionale che mi sembra non essere indicata nella tabella dei possibili valori.
Buonasera Giorgio,
Come hai correttamente evidenziato , non esiste un Purpose che coinvolga contemporaneamente sia il tipo 1 (Persona fisica) che il tipo 4 (Persona Giuridica uso Professionale).
Quello che puoi fare è prevedere 2 accessi distinti (ossia due pagine distinte ciascuna col proprio spid button oppure una pagina con 2 spid button distinti) rispettivamente per Persona fisica e per Persona Giuridica.
Grazie mille anton Giovanni,
Facendo come mi hai suggerito basterebbe fare solo una distinzione “applicativa” diversificando il parametro “purpose” nelle Saml request giusto?
Oppure dovrò anche avere dei metadata diversi in cui richiedo dati diversi a seconda della persona fisica (solo anagrafica) o giuridica (anche dati aggiuntivi come partita iva e ragione sociale)?
Ciao Giorgio,
potrai fare come ti ha giustamente suggerito Antonio Giovanni (due o più pulsanti di accesso a SPID) oppure, modalità che abbiamo preferito, fare in modo che la scelta del tipo di SPID sia indicata dall’utente prima di procedere (con un menu a tendina, una list box, etc.).
A presto.
SAML (e quindi SPID) permettono di indicare, all’interno di un metadata, più insiemi di dati da richiedere ad un Identity Provider (tag AttributeConsumingService).
Quindi, ad esempio, potresti definire all’interno del tuo metadata un tag AttributeConsumingService con indice = 0 contenente le tipologie di dati da richiedere per persona fisica, ed un tag AttributeConsumingService con indice = 1 contenente le tipologie di dati da richiedere per persona giuridica
Buongiorno Antonio Giovanni e Stefano,
grazie mille per le indicazioni. Vediamo se riusciamo ad implementare qualcosa come da vostri consigli.
Ho solo un’altra domanda, però più di carattere “amministrativo” :
Stando a questo documento dei corrispettivi, richiedendo due insiemi di dati separati (dal tag AttributeConsumingService, come da consiglio di Antonio Giovanni), a livello di tariffario, si rientrerebbe nella categoria “Autenticazione” per le Persone Fisiche (ovviamente chiedendo solo i dati anagrafici) e nella categoria “Registrazione” per le Persone Giuridiche (chiedendo anche partita iva, ragione sociale ecc), giusto?
Il documento citato si applica solo ai Service Provider Privati.
Gli Aggregatori di Service Provider Pubblici sono visti solo come “intermediari operativi” degli Enti pubblici, e quindi operano alla stregua dei loro clienti, ovvero gratuitamente.
Gli Aggregatori di Service Provider Privati non mi risultano essere stati ancora attivati. Qualora un giorno fossero attivati, andrebbe chiarito se operano con gli stessi corrispettivi dei Service Provider Privati, o con corrispettivi diversi.
Grazie mille Antonio Giovanni,
sei stato davvero gentilissimo però ho bisogno di farti altre due domande a questo punto :
I costi che normalmente spetterebbero al Service Provider, in caso di Soggetto Aggregatore, verrebbero “demandati” all’Ente aggregato? Cioè all’ente arriverebbero le fatture da parte degli idp? O non ci sono costi per nessuno?
Nel caso in cui i costi spettassero all’ente, varierebbero in base agli attributi richiesti?