ProviderName su AuthnRequest: "item not allowed"

[mauromol]

Scusate l'ennesimo sfogo...

Dopo aver passato tutti i test dello SPID Validator, provo l'ambiente di test e mi vedo rifiutare una richiesta di autenticazione in quanto la mia AuthRequest contiene l'attributo ProviderName.......

Scusate lo sfogo, ma è proprio necessario rendere vietato tutto ciò che è opzionale in SAML 2.0? Non c'è alcuna traccia nelle specifiche SPID che dicano che l'elemento ProviderName non debba essere specificato (se me lo sono perso, chiedo scusa). Persino il Validator, che in alcuni casi manifesta persino un eccesso di zelo (vedi la questione degli attribute value vuoti, a me tanto cara), lo accetta... Ma laddove non ti stronca il validator, lo fa l'ambiente di test!!

Da una parte o dall'altra, credo sarebbe perlomeno corretto allineare i due sistemi (così come l'errore segnalato in #220 per l'attributo isDefault dell'AttributeConsumingService).

[peppelinux]

Ciao Mauro, accolgo serenamente il tuo sfogo, capisco benissimo.

spid-testenv2 verrà riscritto from scratch (vedi issue) e insieme a spid-saml-check condividerà il validatore di base, spid-sp-test.

Puoi usare direttamente spid-sp-test per un controllo veloce. La procedura di collaudo ad oggi viene condotta da AgID mediante spid-saml-check

Mi trovi su slack developers Italia per eventuali confronti

[mauromol]

Grazie Giuseppe, spero che il rinnovo degli strumenti di test possa essere l'occasione anche per una riflessione approfondita su quanto dovrebbero spingersi i vincoli di validazione che vengono imposti. Alcuni credo davvero che non portino alcun valore aggiunto (vedi questo che impedisce di indicare il ProviderName nella AuthnRequest, ad esempio, ma ce ne sarebbero numerosi altri...) e fanno solo impazzire gli implementers. Lo dico più che altro per chi verrà "dopo di me"...

[AntonioGiovanniSchiavone]

Scusa @mauromol, mi sapresti indicare il passaggio delle Regole Tecniche SPID / Avvisi SPID dove è citato l'attributo ProviderName?

[mauromol]

@AntonioGiovanniSchiavone è proprio questo il fatto, non lo vedo citato da alcuna parte! Nelle specifiche SAML 2.0 l'attributo è opzionale:

ProviderName [Optional]
Specifies the human-readable name of the requester for use by the presenter's user agent or the identity provider.

In sostanza l'Identity Provider potrebbe usare quel campo per indicare, all'atto dell'autenticazione, per conto di quale Service Provider si sta eseguendo la richiesta. Ed infatti la libreria SAML che uso io di default mette su quel campo l'OrganizationDisplayName indicato nei metadati dell'SP, se presente.
Posso capire che l'attributo possa al più essere ignorato, non essendone normato l'uso da parte delle specifiche SPID, ma perché vietarlo?

[AntonioGiovanniSchiavone]

@AntonioGiovanniSchiavone è proprio questo il fatto, non lo vedo citato da alcuna parte! Nelle specifiche SAML 2.0 l'attributo è opzionale:

ProviderName [Optional]
Specifies the human-readable name of the requester for use by the presenter's user agent or the identity provider.

In sostanza l'Identity Provider potrebbe usare quel campo per indicare, all'atto dell'autenticazione, per conto di quale Service Provider si sta eseguendo la richiesta. Ed infatti la libreria SAML che uso io di default mette su quel campo l'OrganizationDisplayName indicato nei metadati dell'SP, se presente.
Posso capire che l'attributo possa al più essere ignorato, non essendone normato l'uso da parte delle specifiche SPID, ma perché vietarlo?

Nelle Regole Tecniche SPID in relazione alla Asserzioni si afferma che:

L’asserzione prodotta dall’Identity Provider deve essere conforme allo standard SAML v2.0 (cfr.
[SAML-Core]) e rispettare le condizioni di seguito indicate.
L’asserzione deve avere le seguenti caratteristiche:

E di seguito la lista degli elementi/attributi che devono formare un'Assertion.
Anche per le AuthnRequest e i metadata si usa una formulazione simile.
L'idea generale è che in SPID sia ammessa solo e soltanto quella porzione di SAML esplicitamente citata dalle Regole Tecniche e dagli Avvisi SPID. Tutto ciò che non è riportato, è escluso d'ufficio.

[mauromol]

Personalmente non mi trovo molto d'accordo con questa interpretazione, anche se chiaramente le regole tecniche non le ho scritte io, quindi non ho la presunzione di avere ragione.
In generale, tuttavia, il fatto che una cosa debba essere presente (es.: "l'asserzione deve avere le seguenti caratteristiche"), non significa che un'altra cosa non menzionata ed opzionale nello standard a cui si lo stesso SPID dice di essere conforme (SAML 2.0) allora debba essere vietata. Tanto più che questo attributo ProviderName è puramente informativo e non ha alcun impatto sulle modalità con cui l'autenticazione viene portata a termine.
Nei documenti di specifica internazionali si distingue appunto tra MUST e MUST NOT e MAY o MAY NOT. Altri attributi che sono vietati da SPID (es.: l'attributo IsPassive dell'AuthRequest o l'elemento Advice dell'Assertion) sono esplicitamente indicati come tali.