Salve,
Stiamo implementando più service provider per lo stesso ente, ho letto varie discussioni sul forum che mi hanno portato alla seguente soluzione.
Le varie implementazioni sfrutteranno la libreria spid-php (https://github.com/italia/spid-php) installata sui vari server (dislocati in varie parti del territorio).
Ogni installazione avrà il suo default-sp valorizzato opportunamente, ma con l’accortezza che tutte manterranno lo stesso entityID (quello relativo all’ente), e di conseguenza ogni installazione non può essere utilizzata per la pubblicazione del metadato, poichè ne conterrebbe una quotaparte relativa all’ AttributeConsumingService del Service Provider dell’installazione (varierà di conseguenza il valore dell’ AttributeConsumingService Index).
Mi rimane da chiarire se posso utilizzare un certificato unico per la cifratura in tutti i SP ed eventualmente che caratteristiche debba avere, in particolare il dn può essere genericamente riferito all’ente?
Infine si pone il problema della pubblicazione del metadato complessivo per l’ente.
Mi sembra di capire possa essere effettuata su un url separato dalle varie installazioni, ma chiaramente riconducibile all’Ente.
E mi chiedo se esista un tool utile per la pubblicazione/creazione del metadato.
Spero di essere stato chiaro e di avere iterpretato correttamente quanto letto sul forum.
la soluzione è fattibile, a patto di generare, come dicevi tu stesso, un unico metadata contenente i diversi SingleLogout, AssertionConsumerService e AttributeConsumingService di tutte le diverse installazioni.
Puoi costruire il metadata unendo le informazioni dei metadata delle diverse installazioni e firmandolo con un unico certificato.
Il certificato può essere un self signed riferito genericamente all’ente.
Infine, il metadata dovrà essere pubblicato su un dominio riconducibile all’ente.
Cordiali saluti,
Michele D’Amico
Collaboratore Agenzia per l’Italia Digitale
Salve @damikael, il thread è alquanto interessante. Al momento, tuttavia, non ci sono chiari una serie di aspetti.
Vorremmo comprendere ad esempio come il metadata unico e generale, composto ad hoc, possa essere richiamato da una installazione secondaria (singolo applicativo) di spid-php, per completare il processo di autenticazione, facendo riferimento quindi al metadata remoto e non a quello locale, generato di default dalla singola installazione.
Se possibile gradiremmo ricevere indicazioni su come integrare e sfruttare all’interno della libreria spid-php legata alla singola applicazione, il metadata unico e remoto per far si che il processo di dialogo e autenticazione con gli IDP possa essere gestito a livello di singolo applicativo.
A tale riguardo e qualora questa ultima fattispecie non sia demandabile al singolo applicativo, vorremmo comprendere se è necessario utilizzare e/o fare affidamento sun un unico ambiente di orchestrazione, nel quale naturalmente è definito e trova luogo il metadata regionale composito.
Salve @Massimiliano_Perri,
le installazioni dislocate di spid-php possono essere configurate singolarmente con l’attenzione di mantenere per tutte le installazioni:
lo stesso EntityID
lo stesso certificato e chiave privata
Tali informazioni sono configurabili, anche dopo aver eseguito l’installazione, in:
/spid-php/vendor/simplesamlphp/simplesamlphp/config/authsources.php
Il certificato e la chiave privata (privatekey e certificate), devono chiaramente essere condivisi su tutte le installazioni.
Dovrebbe essere sufficiente questo.
Se avete modo di sperimentare fatemi sapere l’esito.
Buongiorno @damikael. Mi servirebbe un ulteriore precisazione sull’installazione che non sono riuscito a trovare nella documentazione.
Gli AssertionConsumerService e AttributeConsumingService ho visto che sono diversificabili mediante il parametro index.
Tuttavia mi chiedo se è possibile procedere nella stessa maniera per il parametro SingleLogoutService nella maniera seguente:
<md:SingleLogoutService
index=“0”
Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
Location=“https://url1”/>
</>
<md:SingleLogoutService
index=“1”
Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
Location=“https://url2”/>
</>
dove chiaramente l’index sarà relativo alla singola installazione e comune con i parametri AssertionConsumerService e AttributeConsumingService.
Buongiorno @damikael,
ho effettuato dei test su SingleLogoutService.
Dopo il messaggio di LogoutRequest inviato da qualsiasi servizio stand-alone, l’idP (sto utilizzando https://idp.spid.gov.it/) utilizza sempre la “Location” del primo SingleLogoutService tra quelli specificati (uno per ogni installazione) nel metadata complessivo e non la “Location” del SingleLogoutService che ha inviato la LogoutRequest.
Come si può ovviare a tale inconveniente?
il meccanismo di SingleLogout permette la disconnessione da tutti i SP che partecipano alla sessione, ovvero i cui AssertionConsumerService sono inseriti nello stesso metadata.
Il processo prevede che, alla ricezione di una LogoutRequest da parte di un SP, l’IdP invii a sua volta LogoutRequest, in ordine, a tutte le location di Logout presenti nel metadata.
Ognuna di queste, deve rispondere con una LogoutResponse all’IdP.
Al termine di tutte le LogoutRequest, inviate dall’IdP, e relative risposte, l’IdP deve rispondere al SP che ha iniziato il processo di Logout con una LogoutResponse finale.
Pertanto, se un determinato SP non implementa bene il protocollo, rispondendo con una LogoutResponse all’IdP nel momento in cui riceve da questo una LogoutRequest, il processo resta bloccato su tale SP.
Occorre, quindi, verificare che il processo venga eseguito in maniera corretta.
In alternativa è consigliabile utilizzare il binding SOAP, con il quale, invece, il processo non dovrebbe rimanere bloccato.
@damikael
Ti premetto che stiamo usando la libreria presente su https://github.com/italia/spid-php.
Ho fatto le necessarie verifiche ed il primo SP a prescindere dal fatto che sia stato lui o meno ad iniziare il processo di Logout risponde alla seguente Request dell’IdP (successiva alla richiesta di logout):
In pratica con Status “Success”.
Mi aspetto a questo punto forse che debba dare uno status diverso a seconda del fatto che sia stato lui ad iniziare il processo di logout?
dal momento che il primo SP fa parte dello stesso metadata, pur non essendo stato lui ad iniziare il processo, è corretto che esegua il logout della sessione individuale e restituisca Status success all’IdP.
Salve @damikael,
avrei una domanda riguardo la pubblicazione dei metadati di un SP dove dici Infine, il metadata dovrà essere pubblicato su un dominio riconducibile all’ente
Si intende che il dominio DNS deve avere come proprietario (registrant) l’Ente o non ha nulla a
che vedere con ciò ? Può essere, ad esempio, enteXXX.mioservizio.it o deve essere .enteXXX.it ?
Ovvero se fornisco un servizio SP ad un ente devo utilizzare un dominio di proprietà dell’ente
per la pubblicazione dei metadati ?
Salve @nicola.tommasini ,
il dominio deve essere di proprietà dell’ente che stipula la convenzione con AgID. Nel caso di soggetto aggregatore, ad esempio, il metadata dell’aggregato può essere esposto su dominio di proprietà del soggetto aggregatore.