[AuthnRequest] Issuer NameQualifier

[alranel]

Tre segnalazioni:

1. Nell'esempio di AuthnRequest il tag <saml:Issuer> è valorizzato con un entityID non in formato URI, quindi credo che sia in contraddizione con quanto previsto dalle stesse Regole Tecniche:

spid-regole-tecniche/src/code-samples/authnrequest.xml

Lines 13 to 17 in b0759ed

	<saml:Issuer
	NameQualifier="http://spid.serviceprovider.it"
	Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
	spid-sp
	</saml:Issuer>

2. Il documento saml-core-2.0-os.pdf indica che in caso di urn:oasis:names:tc:SAML:2.0:nameid-format:entity:

The NameQualifier, SPNameQualifier, and SPProvidedID attributes MUST be omitted.

Eppure nelle Regole Tecniche è previsto l'obbligo di includere l'attributo NameQualifier. Questa disposizione sembra contraddire le specifiche tecniche di SAML, ed infatti comporta la spiacevole necessità di patchare le implementazioni esistenti (cfr. italia/spid-sp-simplesamlphp#2). Qualora non sia possibile eliminare questa difformità (a mio avviso la soluzione preferibile), sarebbe quantomeno opportuno documentarla in modo esplicito.

3. Non è chiaro quale valore vada inserito nell'attributo NameQualifier secondo le regole tecniche, che recitano:

qualifica il dominio a cui afferisce tale valore (URI riconducibile al Service Provider stesso)

Nell'esempio riportato nelle Regole Tecniche stesse, il valore di tale attributo è una URI (coincidente con l'entityID) e non un dominio. La semantica di tale attributo non è desumibile dalle specifiche di SAML poiché le stesse recitano:

The NameQualifier and SPNameQualifier attributes SHOULD be omitted unless the identifier's type definition explicitly defines their use and semantics.

e come si vedeva al punto 2, in questo caso l'attributo non è previsto.

[peppelinux]

Nel mio SP pysaml2 le richieste Authn presentano come Issuer il seguente

<ns1:Issuer 
  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
  http://sp1.testunical.it:8000/saml2/metadata/
</ns1:Issuer>

L'EntityID è in formato URI e risulta corretto ma manca purtroppo l'attributo NameQualifier.
La validazione con spid-testenv2 fallisce qui. Ho patchato l'oggetto XML per superare questo ostacolo ma consultando le specifiche tecniche OASIS parrebbe che NameQualifier non sia richiesto ne tantomeno indispensabile. L'esempio di seguito riportato è stato estratto da sstc-saml-tech-overview-2.0:

<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="1">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Anch'io riterrei opportuno rimuovere questo obbligo come già proposto da @alranel

update: Ho letto comunque l'avviso riguardante questo aspetto nelle specifiche stabili.

[peppelinux]

risolto qui

spid-regole-tecniche/code-samples/authnrequest.xml

Line 13 in 6f459d1

http://spid.serviceprovider.it

[mauromol]

Scusate, aiutatemi a capire: questo "progetto" GitHub, con le sue segnalazioni, può in qualche modo far arrivare il feedback sulle specifiche tecniche a chi le specifiche le emana e le "promuove"?
Sto studiando il tutto ed anche io mi sono incappato in questa assurdità del NameQualifier obbligatorio. Peraltro anche il Format dovrebbe essere facoltativo negli elementi Issuer, perché, da specifica SAML, è sottinteso che sia urn:oasis:names:tc:SAML:2.0:nameid-format:entity quando non specificato.

Questa issue è marcata come chiusa, per cui volevo capire cosa si intenda per "chiusa": c'è la speranza che le regole tecniche ufficiali di SPID vengano corrette? Oppure significa solamente che le regole consolidate scritte qui su GitHub sono state corrette in modo da aderire alla specifica ufficiale (ma senza alcuna velleità di correggerla)?

Ringrazio in anticipo.

[peppelinux]

Ciao @mauromol,
Innanzitutto grazie per il tuo intervento, la forza delle tue parole suscita in me un grande interesse.
Idealmente tutti i progetti pubblicati su developers italia nascono con una logica community driven, possiamo ritenere questo il luogo ideale per condividere e accogliere tutti i feedback di natura tecnica.

Sulla tua ultima domanda sento di doverti rispondere con onestà intellettuale.
La issue in oggetto poneva la problematica del formato del valore text di ed è stata risolta dando la giusta interpretazione delle specifiche ufficiali di SPID.

La correzione alla quale ti riferisci non è purtroppo strettamente di competenza di questo progetto, quello che ci hai descritto corrisponde a quanto definito all'interno dalle specifiche ufficiali AgID e loro successive integrazioni.

spid-regole-tecniche vuole solo unificare le specifiche e i suoi avvisi in un'unico documento, interattivo e facilmente consultabile.

Ad oggi la validazione del sistema di onboarding di AgID richiede questi attributi, come le Regole Tecniche alla pag. 9 esplicitano.
I tuoi interventi sono molto interessanti, sentiti libero di condividere il tuo pensiero

[peppelinux]

Credo che sia necessario lasciare aperta questa Issue come riferimento per tutte le specifiche SPID che dovrebbero essere riallineate con SAML2 core.

Grazie @mauromol per il tuo intervento che mi ha permesso di rivalutare questo

[mauromol]

Grazie @peppelinux per la cortesia, la franchezza e la chiarezza. Anzi, chiedo scusa se le mie domande possono sembrare ingenue, ma ti assicuro che dopo aver letto più di 50 documenti tra specifiche SAML, specifiche tecniche SPID, avvisi di rettifica/integrazione, linee guida, altri documenti interpretativi ed almeno 4 siti web "ufficiali" su SPID (tra cui quello su Developers Italia, comprensivo di vari repository GitHub), mettere ogni tassello al posto giusto non è facile. Ti dirò di più, se posso dare un suggerimento cercherei di chiarire meglio (fin dalla home dedicata a SPID su Developers Italia) che le risorse messe a disposizione della community non sono da intendersi come normative, ma solo come supporto informale che cerca di essere dare aiuto integrativo per gli sviluppatori. Se, infatti, da un lato, vedendo la pagina dedicata a SPID su Developers Italia linkata direttamente dal sito ufficiale di SPID, speravo che finalmente avessero messo la community al centro nella definizione e gestione di standard così importanti per lo sviluppo del Paese, dall'altro ho capito (solo dopo un paio di interventi qui su GitHub) che purtroppo in realtà queste risorse trattasi solo di un best effort che cerca di seguire quanto diramato ufficialmente con i soliti modi in po' barocchi e spesso confusionari tipici di questi standard governativi.
Non fraintendermi, la mia non vuole essere una critica distruttiva, ma anzi vorrebbe essere costruttiva, nella speranza che le cose possano cambiare, perché scivoloni come questo (segnalato qui nel 2017... e siamo nel 2021!) e quello di #20 avrebbero potuto essere risolti da anni se ci fosse un dialogo attivo.

Detto questo, se sei a conoscenza di un canale tramite il quale si possa segnalare ad AGID il problema, ti sarei grato se me lo segnalassi, anche se mi sento un po' presuntuoso a chiederlo perché immagino che se esistesse l'avreste già sfruttato voi alcuni anni fa...

[peppelinux]

Grazie @mauromol il tuo contributo è veramente importante,
stamattina abbiamo aggiornato la pagina dedicata alla piattaforma SPID su developers italia, tuttavia ritengo ancora che sia opportuno integrare con parte dei tuoi consigli, a presto

[peppelinux]

Per completezza, saml-core-2.0-os.pdf

[mauromol]

E per completare ulteriormente, nella stessa specifica, circa l'opzionalità del Format per l'Issuer: