Le regole tecniche SPID non sono compliant con la specifica SAML2

Buongiorno,
vorrei sapere che azioni intendete intraprendere per rendere le specifiche SPID davvero compliant con lo standard SAML2. In particolare, come già documentato su github all’URL https://github.com/italia/spid-regole-tecniche/issues/15 , le specifiche SPID prevedono dei vincoli sul messaggio AuthnRequest esplicitamente vietati dallo standard, il che rende impossibile interfacciare gli strumenti esistenti basati su SAML2.

Riepilogo in breve i riferimenti alla specifica violati:

  • Nel tag Issuer, l’attributo Format non è obbligatorio. Se omesso, va inteso di default valorizzato a “urn:oasis:names:tc:SAML:2.0:nameid-format:entity” (cfr. saml-core-2.0-os.pdf, §2.2.5, line 526-527);
  • Nel tag Issuer, l’attributo NameQualifier è esplicitamente vietato se l’attributo Format è valorizzato a “urn:oasis:names:tc:SAML:2.0:nameid-format:entity” (cfr. saml-core-2.0-os.pdf, §8.3.6, line 3317.

Problemi analoghi si hanno anche nel parsing della risposta, ove il tag Issuer restituito viene valorizzato da SPID riportando attributi esplicitamente vietati dalla specifica e i parser si rifiutano di accettarli.

Il fatto che le regole tecniche documentino l’anomalia non aiuta. L’obiettivo di usare un protocollo aperto è anche di non dover continuamente spendere tempo e soldi a customizzare prodotti che funzionerebbero benissimo rivolgendosi a componenti già disponibili su internet o addirittura già in uso presso le amministrazioni.

Grazie e buona giornata a tutti

1 Mi Piace

Ciao ho vissuto anche io i tuoi stessi dubbi e difficoltá. Ho sviluppato i seguenti esempi per metadata, authn_request e single logout, utilizzando pysaml2, li trovi qui:

Nello specifico cosa usi come Saml2 SP? Shibboleth, pysaml2, phpsimplesaml o altro?

Anche io sarei convenuto su una migliore flessibilitá di interfacciamento in SAML2

Il progetto di integrazione SPID qui da noi è stato assegnato a un consulente (via consip) che ci ha installato uno strato SP customizzato da lui su base OpenAM. L’idea in sé è corretta: OpenAM fa da SP e incorpora anche le auth precedenti che abbiamo (LDAP o database). Purtroppo abbiamo un miliardo di problemi con questa implementazione custom che dobbiamo affrontare… ad esempio dà per scontato che tutti gli utenti registrati fuori da SPID abbiano un codice fiscale, e quindi non sappiamo come gestire le persone fisiche estere. Il risultato è che abbiamo un portale SPID funzionante, ma non abbiamo mai collegato nessun servizio :slight_smile:

In questi giorni di ferie diffuse sto valutando una serie di prodotti di AM open source (LemonLdap, Shibboleth, Gluu, KeyCloak) che permettano di federare SAML con LDAP ma purtroppo mi sto scontrando con le deviazioni dallo standard introdotte da SPID. Se ci sono problemi nel software non posso aprire ticket sui sistemi upstream perché SPID non è compliant SAML, e se decido di forkare i progetti open e modificarli, poi devo prendermi l’onere di mantenere il codice custom ad ogni release, soprattutto in caso di advisory di sicurezza. OpenAM è closed source dal 2016 e in tre anni non è nata una vera e propria community open. Da qualsiasi punto di vista la si affronti, il rischio non è basso.

Al momento non ho una soluzione certa. Quello che sto provando a fare è questo:

  • OpenAM come SP non standard collegato a SPID, tramite le customizzazioni;
  • Configuro OpenAM come IDP SAML2 (standard) che federa l’SP SPID e una DC LDAP per gli utenti extra-SPID;
  • Modifica delle applicazioni per autenticare verso OpenAM agendo da SP SAML2 (standard).

In questo modo se mai un domani SPID tornerà ad essere compliant con lo standard potremo droppare le customizzazioni del consulente senza modificare tutta l’architettura.

Comunque sono molto sconfortato e non so se alla fine riuscirò a implementare questo giro. Il mio timore è che le customizzazioni apportate dal consulente vadano a impattare anche l’IDP esposto dalla piattaforma OpenAM, costringendoci a customizzare anche gli SP usati dalle applicazioni. Non sarebbe drammatico se le applicazioni fossero omogenee, ma qui ne abbiamo a dozzine tutti in linguaggi e risalenti a epoche diverse. SAML è l’unico strato che più o meno si riesce a integrare ovunque.

Speravo che qui sul forum qualcuno avesse già dovuto affrontare questa esigenza, ma per il momento ho trovato customizzazioni per singoli SP, come quella che proponi per django (ps: grazie!).

Incrociamo le dita per il futuro…

forse qui ci vorrebbe un aiutino di @umbros :grinning: