Guida passo passo per SP SPID

dlarizza · 22 Novembre 2017, 1:29pm

Salve a tutti,
siamo impegnati alla realizzazione di un Service Provider da installare presso la ns PA per permettere l’accesso del cittadino ai siti istituzionali.
Dopo svariati tentativi e diverse soluzioni…non abbiamo raggiunto lo scopo.

Usando shibboleth e testandolo con testshib e’ tutto ok…ma con i vari idp (poste ecc) di produzione non vuole avere nessuna confidenza.

Ultimamente ho provato anche il pacchetto di ansible usando delle macchine ubuntu…ma nulla di fatto non completo nemmeno la corretta installazione.

Parlando con altri miei colleghi di altre amministrazioni sento sempre le stesse lamentele riguardanti scarsa documentazione.

Mi chiedo…esiste o e’ possibile redigere…una documentazione passo passo…con tanto di “configurazioni tipo” funzionanti con gli idp piu popolari?

Grazie mille
Danilo

umbros · 22 Novembre 2017, 1:43pm

Ciao @dlarizza,
lunedì verrà rilasciata la configurazione Shibboleth, testshib non è un idp SPID quindi possono essereci delle differenze. Ti chiedo di utilizzare l’ambiente di test https://github.com/italia/spid-testenv.

Tienimi aggiornato delle difficoltà perchè è importante per noi andare a migliorare dove l’utente si blocca.

Grazie

Umberto Rosini
Agenzia per l’Italia Digitale

dlarizza · 22 Novembre 2017, 1:59pm

Perfetto,
diciamo che le difficoltà, installando il tutto a manina, si limitano proprio alle configurazioni.
I metadati erano sempre errati e quindi la comunicazione impossibili.

Diciamo che con le configurazioni di shibboleth dovremmo fare un passo avanti. Ipotizzate comunque di scrivere due linee guida anche per sistemi, sistemi operativi, applicativi…
Chi parte da zero potrebbe avere grosse difficoltà…
Io ci ho messo un bel po…e sono fermo ad un passo dalla fine

Attendo lunedi e poi ci aggiorniamo.

Grazie

dlarizza · 28 Novembre 2017, 7:51am

Buongiorno, nessuna news???

Grazie
Danilo

umbros · 3 Dicembre 2017, 10:26pm

Ciao Danilo,
siamo nel pieno di selezioni e sono stato coinvolto nelle commissioni ti chiedo, quindi, di pazientare ancora qualche giorno.

Grazie

Umberto Rosini
Agenzia per l’Italia Digitale

dagord · 9 Gennaio 2018, 12:46pm

Salve,
mi accodo alla richiesta.
Sto cercando di interfacciare un applicativo sviluppato in Plone con un IPD di test fornitoci dalla Regione, ma anch’io mi scontro con la configurazione di Shibboleth…
Ci sono novità?
Matteo

umbros · 9 Gennaio 2018, 5:10pm

Ciao @dagord ,
le configurazioni dell’SP sono disponibili qui:
https://github.com/italia/spid-sp-shibboleth (ovviamente apporta tutte le opportune modifiche).

Umberto Rosini
Agenzia per l’Italia Digitale

dagord · 9 Gennaio 2018, 5:54pm

Grazie @umbros!
Domani faccio tutti i test del caso.
Una domanda: come viene valorizzato il parametro IssueInstant? Ci pensa Shibboleth?

umbros · 9 Gennaio 2018, 6:06pm

Ciao,
si ci pensa Shibboleth. Fammi avere feedback e nel caso apri issue o pull request

Umberto Rosini
Agenzia per l’Italia Digitale

giafar · 9 Gennaio 2018, 6:43pm

Ciao @dagord,
mi permetto di suggerire di utilizzare la feature di Shibboleth che consiste nel refresh automatico dei metadata degli IDP ovvero quello di censirli all’interno di shibboleth2.xml tramite

<MetadataProvider type="XML" uri="<url per il download dei metadati>" backingFilePath="<nome del file che conterrà i metadati>" reloadInterval="<tempo in secondi di refresh"/>.

In questo modo shibboleth contatterà l’IDP per aggiornare ove necessario il file dei metadati ed in particolare i certificati di signing che potrebbero nel tempo cambiare: Infocert, ad esempio, scade l’11 gennaio 2019. I file saranno posizionati in /var/cache/shibboleth

L’elenco completo degli IDP e delle url dei metadati li trovi qui

giafar · 9 Gennaio 2018, 10:58pm

Ciao @dagord,
per quanto possa valere confermo il corretto funzionamento dell’ambiente di test messo a disposizione dal gruppo italia con ShibbolethSP: ho usato questo ambiente docker.
Mi permetto però di farti notare che il file dei metadati dell’IDP non è corretto in quanto l’entityID e gli endpoint dei servizi fanno riferimento ad idp.spid.gov e non a spid-testenv-identityserver e questo causa alcuni problemi:

Ovviamente vieni sparato su https://idp.spid.gov:9443 che non ha i metadati del tuo SP che hai creato tramite backoffice
Messa apposto la configurazione precedente la response che ti viene manadata a fronte della login genera un errore di sicurezza lato SP perché lo issuer della response, spid-testenv-identityserver, non è coerente che l’entityID dell’IDP che è idp.spid.gov
Fai attenzione che nel tuo shibboleth2.xml l’index dell’AssertionConsumerService in HTTP-POST sia 1 perché è qualla che viene assegnata tramite backoffice al SP creato dentro WSO2

A completa disposizione per altre info.

Leggi anche i commenti su questa Pull Request per informazioni ancora più dettagliate.

Buoni test

dagord · 10 Gennaio 2018, 8:56am

Ciao,
ho provato a riportare i miei parametri nel file di configurazione di Shibboleth ma continuo ad avere dei problemi.
Premetto che in questa fase sto utilizzando un identity provider di collaudo fornitormi da Regione Veneto.
Come ho configurato Shibboleth:

Ho sostituito tutti i riferimenti a con l’url pubblico del mio Service provider https://www.miosito.it
Ho definito un nuovo metadata provider in questo modo:

   <MetadataProvider type="XML" validate="true" file="gw/metadata" id="https://myid.collaudo.regione.veneto.it/gw/SSOProxy/SAML2"/>

Ho modificato l’attributo CredentialResolver inserendo i riferimenti ai miei file key e crt
Il path del mio metadata (esposto pubblicamente su https://www.miosito.it/metadata) è /etc/shibboleth/gw/metadata
Non mi è chiaro se l’attributo saml:Issuer vada configurato in qualche modo ma, in ogni caso, le modifiche sembrano non aver effetto

Chiaramente ho riavviato il daemon.
Ma ad ogni tentativo di login ottengo questo messaggio di “Metadata Exception”:
Unable to locate SAML 2.0 identity provider role for provider (https://www.miosito.it)

I log riportano lo stesso errore.

Il messaggio francamente mi sembra ambiguo e non so dove posso aver sbagliato.

giafar · 10 Gennaio 2018, 9:37am

Ciao,
puoi postare il tuo shibbolet2.xml ?

dagord · 10 Gennaio 2018, 10:48am

Eccolo.
Ho eliminato i commenti per ragioni di brevità.
Il mio metadata è esposto pubblicamente all’indirizzo https://www.miosito.it/metadata

Non ho configurato null’altro.
Potrebbe essere un problema di configurazione di Apache?

<ApplicationDefaults entityID="https://www.miosito.it"
    REMOTE_USER="eppn persistent-id targeted-id" signing="true"
    signingAlg="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" encryption="false"
    authnContextClassRef="https://www.spid.gov.it/SpidL2" authnContextComparison="exact"
    NameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">

    <Sessions lifetime="1800" timeout="3600" relayState="ss:mem" handlerURL="/Shibboleth.sso"
        checkAddress="false" handlerSSL="true" cookieProps="https">

        <!-- Login -->
        <SessionInitiator type="SAML2" Location="/Login" isDefault="true"
        entityID="https://www.miosito.it"
            outgoingBinding="urn:oasis:names:tc:SAML:profiles:SSO:request-init"
            isPassive="false" 
            signing="true">
	<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
            xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id..." Version="2.0" IssueInstant="2017-01-01T00:00:00Z" 
	    AttributeConsumingServiceIndex="0" ForceAuthn="true">
	    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" NameQualifier="https://url">https://url</saml:Issuer>
	</samlp:AuthnRequest>
    </SessionInitiator>            

        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="/SAML2/POST" index="0"/>

        <!-- Logout -->
        <LogoutInitiator type="Chaining" Location="/Logout">
            <LogoutInitiator type="SAML2"
                outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                signing="true"/>
            <LogoutInitiator type="Local" signing="true"/>
        </LogoutInitiator>
        
        <md:SingleLogoutService Location="/SLO/POST"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:SingleLogoutService Location="/SLO/Redirect"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
        
        <!-- Handler -->
        <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
        <Handler type="Session" Location="/Session" showAttributeValues="true"/>

    </Sessions>

    <MetadataProvider type="XML" validate="true" file="gw/metadata" id="https://myid.collaudo.regione.veneto.it/gw/SSOProxy/SAML2"/>

    <AttributeExtractor type="XML" validate="true" reloadChanges="true" path="attribute-map.xml"/>
    <AttributeResolver type="Query" subjectMatch="true"/>
    <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

    <CredentialResolver type="File" key="/opt/certificati/selfsigned.key" certificate="/opt/certificati/selfsigned.crt" use="signing"/>

</ApplicationDefaults>

<!-- Security policies -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

<!-- Protocols and binding -->
<ProtocolProvider type="XML" validate="true" reloadChanges="true" path="protocols.xml"/>

umbros · 10 Gennaio 2018, 12:00pm

Ciao,
@giafar il metadata idp non è errato è quello che funziona sull’idp online messo a disposizione e su cui stiamo facendo enhancement. https://idp.spid.gov.it quindi va modificato in base alle necessità per la versione docker.
Detto ciò Shibboleth è possibile modificarlo anche in base alle necessità. Una versione correttà è messa sul github. Qualsiasi contributo ben venuto.
Non si da supporto su ambienti di test differenti da quello rilasciato da AgID per SPID quindi @dagord ti chiederei di utilizzare l’ambiente di test che abbiamo rilasciato noi di AgID.

Resto a disposizione

Umberto Rosini
Agenzia per l’Italia Digitale

dagord · 10 Gennaio 2018, 12:44pm

Ciao,
capisco che non possiate fornire supporto sul caso di differenti IP.
Ho comunque risolto il problema: avevo equivocato la definizione di EntityID, specificando i parametri dell’SP al posto di quelli dell’IP e viceversa.
Sperando di fare cosa utile se riporto l’attuale configurazione funzionante (ho ancora problemi di interfacciamento ma pare siano imputabili all’IP stesso).

<ApplicationDefaults entityID="https://www.miosito.it"
    REMOTE_USER="eppn persistent-id targeted-id" signing="true"
    signingAlg="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" encryption="false"
    authnContextClassRef="https://www.spid.gov.it/SpidL2" authnContextComparison="exact"
    NameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">

    <Sessions lifetime="1800" timeout="3600" relayState="ss:mem" handlerURL="/Shibboleth.sso"
        checkAddress="false" handlerSSL="true" cookieProps="https">

        <!-- Login -->
        <SessionInitiator type="SAML2" Location="/Login" isDefault="true"
        entityID="https://myid.collaudo.regione.veneto.it/gw/metadata"
            outgoingBinding="urn:oasis:names:tc:SAML:profiles:SSO:request-init"
	id="collaudo"
            isPassive="false" 
            signing="true">
	<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
            xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id..." Version="2.0" IssueInstant="2017-01-01T00:00:00Z" 
	    AttributeConsumingServiceIndex="0" ForceAuthn="true">
	    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" NameQualifier="https://www.miosito.it">https://www.miosito.it</saml:Issuer>
	</samlp:AuthnRequest>
    </SessionInitiator>            

        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="/SAML2/POST" index="0"/>

        <!-- Logout -->
        <LogoutInitiator type="Chaining" Location="/Logout">
            <LogoutInitiator type="SAML2"
                outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                signing="true"/>
            <LogoutInitiator type="Local" signing="true"/>
        </LogoutInitiator>
        
        <md:SingleLogoutService Location="/SLO/POST"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:SingleLogoutService Location="/SLO/Redirect"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
        
        <!-- Handler -->
        <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
        <Handler type="Session" Location="/Session" showAttributeValues="true"/>

    </Sessions>

    <MetadataProvider type="XML" validate="true" uri="https://myid.collaudo.regione.veneto.it/gw/metadata" id="collaudo"/>

    <!-- Attributes -->
    <AttributeExtractor type="XML" validate="true" reloadChanges="true" path="attribute-map.xml"/>
    <AttributeResolver type="Query" subjectMatch="true"/>
    <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

    <!-- Assertion signing cert -->
    <CredentialResolver type="File" key="/opt/certificati/selfsigned.key" certificate="/opt/certificati/selfsigned.crt" use="signing"/>

</ApplicationDefaults>

<!-- Security policies -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

<!-- Protocols and binding -->
<ProtocolProvider type="XML" validate="true" reloadChanges="true" path="protocols.xml"/>

giafar · 10 Gennaio 2018, 1:25pm

Ciao @umbros,
scusa ma mi permetto di osservare che l’ambiente di test che ci avete cortesemente fornito presenta il problema evidenziato nel post ovvero che i metadata dell’identity provider, presenti nel backoffice, fanno riferimento a idp.spid.gov.it e quindi Shibbolet non è in grado di associarlo allo issuer spid-testenv-identityserver presente nella response ad autenticazione avvenuta: in merito a questo c’è una Pull Request.

Potresti, cortesemente, indicarmi come pubblicare i metadata del mio SP di test sull’IDP online https://idp.spid.gov.it ?

Grazie mille per il lavoro svolto sino ad ora.

umbros · 10 Gennaio 2018, 1:46pm

Ciao @giafar,
ti ho detto infatti che l’EntityID va modificato in base a dove viene installato il docker, quel metadata è da considerarsi un esempio.
Per caricare le informazioni dell’SP abbiamo superato la “consegna” del metadata (cosa che riporterò anche nel sistema di onboarding automatizzato) e viene messo a disposizione un modulo di caricamento e gestione metadata: https://idp.spid.gov.it:8080

Umberto Rosini
Agenzia per l’Italia Digitale

giusi61 · 23 Gennaio 2018, 9:59am

Buongiorno a tutti è la prima volta che accedo a questo forum con lo scopo di trovare risposte e aiuto per migliorare i servizi digitali della nostra amministrazione. Quest’anno abbiamo notificato tantissime cartelle di tributi locali con grande dispendio di risorse umane (messi notificatori) ed economiche (spese postali - benzina ecc.). Attraverso la digitalizzazione è possibile un recupero delle risorse ma da dove e come cominciare? Il primo problema che dobbiamo risolvere è la notifica, quindi, si pensava al sistema SPID e all’implementazione di alcuni servizi online personalizzati per l’ufficio tributi. Ciò che cerco di capire è se attraverso questo percorso sarà possibile raggiungere lo scopo, come poterlo intraprendere tenuto conto della poca conoscenza.

Alberto · 7 Maggio 2019, 7:00am

Buon giorno,
sto cercando di creare un ambiente di test per spid avendo italia/spid-testenv2 come server IdP (insdtallato partendo dal docker, non dai sorgenti di github) e apache/shibboleth come server SP.
Installazione di shibboleth effettuata dai repository opensuse per Centos 7 come indicato anche nel vostro how to e file di configurazione scaricati ed adattati partendo dal progetto github italia/spid-sp-shibboleth.
Il problema mio è che quando provo a fare la login, la pagina passa correttamente da quella dell’SP a quella dell’IdP, ma l’IdP risponde con il messaggio
“Dato mancante nella request: ‘SigAlg’”
Che cosa sto sbagliando?
Grazie per l’attenzione e per il lavoro che fate!