Docs Italia beta

Documenti pubblici, digitali.

4. Interoperabilità con SPID

Lo schema di identificazione Entra con CIE pur avendo molte analogie con lo schema di identificazione SPID, differisce da quest'ultimo su alcuni aspetti che riguardano:

  • la predisposizione dei metadata
  • alcuni aspetti del protocollo di comunicazione SAML.

4.1. Metadata

In riferimento ai metadata, diversamente da quanto previsto per SPID, lo schema Entra con CIE prevede un unico modello di metadata indipendentemente dal ruolo che il soggetto svolge nell'ambito dello schema SPID. In particolare i due elementi nei quali si hanno maggiori impatti sono:

  • l'elemento <AttributeConsumingService> che contiene il set di attributi richiesti in fase di autenticazione prevede, attualmente, solo e soltanto gli attributi relativi al Minimum Dataset eIDAS o suoi sottoinsiemi;
  • l'elemento <ServiceName> può contenere un UUID v.4 dell'attribute set richiedibile dal SP, comprensivo dell'attributo xmlns:lang, valorizzato con una stringa vuota;
  • l'elemento <md:Organization> che contiene i dati del Service Provider in veste di persona giuridica;
  • gli elementi <ContactPerson> che dovranno contenere le informazioni di censimento e contatto del Service Provider e dell'eventuale partner tecnologico (cfr. Federazione).

I dati identificativi del Service Provider e del partner tecnologico devono coincidere con quelli inseriti in fase di richiesta di adesione. Per maggiori dettagli consultare il capitolo Federazione.

4.2. Protocolli di comunicazione

I protocolli di comunicazione previsti da entrambi gli schemi (Entra con CIE e SPID) sono basati sullo standard SAML versione 2.0 e, dunque, ereditano da esso le principali specifiche tecniche. Tuttavia, nella modalità specifica secondo la quale gli schemi di identificazione sono declinati è possibile individuare alcune lievi differenze che possono avere un impatto sull'implementazione da parte del Service Provider.

Nella costruzione della richiesta di autenticazione <AuthnRequest> è necessario valorizzare l'attributo Destination coerentemente con l'attributo Location presente nel tag SingleSignOnService riportato nel metadata dell'IdP e relativo al particolare binding utilizzato in fase di richiesta (cfr. Protocolli di comunicazione e Modalitá di trasmissione dei messaggi per ulteriori dettagli).

Per quanto riguarda il parsing e la verifica dei messaggi di response, il Service Provider deve tenere conto che, diversamente da quanto previsto da SPID,

  • l'attributo Format dell'elemento <samlp:Issuer> non è presente;
  • gli attributi inviati in risposta alla richiesta di autenticazione comprendono sempre almeno il Minimum Dataset eIDAS e non è previsto l'invio dello spidCode.