menu di navigazione del network

Spid-php diversi SP, un solo ente e pubblicazione metadato

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.

Grazie mille

Buongiorno @Saverio,

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.

Grazie di tutto e buon lavoro.

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.

Michele D’Amico

Gent.mo,
Le siamo grati per la risposta tempestiva. Avremo modo di fornire dettagli a valle delle attività di integrazione.

A presto @damikael e grazie di tutto.

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.

Grazie mille

Salve @Saverio,
non è possibile, l’attributo index su SingleLogoutService non è previsto dallo standard SAML.

Capisco.
Quindi in ogni punto di accesso specificherò il relativo SingleLogoutService.
Nel metadata complessivo invece li elencherò tutti?

<md:SingleLogoutService
Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
Location=“https://url1 ”/>
</>
<md:SingleLogoutService
Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
Location=“https://url2”/>
</>

Grazie mille.

sì, è esatto.

Michele

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?

Buongiorno @Saverio,

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.

Cordiali saluti,
Michele

@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):

<samlp:LogoutRequest xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”
xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”
ID="_0ebebdabcbf0020b1252288fc05d8511634d211c83"
Version=“2.0”
IssueInstant=“2020-06-11T10:51:23Z”
Destination=“https://idptest.spid.gov.it/slo
>
<saml:Issuer NameQualifier=“https://www.regione.sicilia.it
Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity”
>https://www.regione.sicilia.it</saml:Issuer>
<saml:NameID NameQualifier=“https://idptest.spid.gov.it
Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:transient”
>https://idptest.spid.gov.it</saml:NameID>
samlp:SessionIndexid_c84deeb0bb9403b49c5fca68a7b161d718b4e230</samlp:SessionIndex>
</samlp:LogoutRequest>

con la Response seguente

<samlp:LogoutResponse xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”
Version=“2.0”
InResponseTo="_0ebebdabcbf0020b1252288fc05d8511634d211c83"
IssueInstant=“2020-06-11T10:51:23Z”
Destination=“https://si-vvi.regione.sicilia.it/spid/module.php/saml/sp/saml2-logout.php/default-sp
ID=“id_033ceb7af8927a505dbaa64446d52d9fffa70dd4”
>
<saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”
xmlns:xs=“http://www.w3.org/2001/XMLSchema
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance
NameQualifier=“something”
Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity”
>https://idptest.spid.gov.it</saml:Issuer>
<ds:Signature xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”>
ds:SignedInfo
<ds:CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” />
<ds:SignatureMethod Algorithm=“http://www.w3.org/2001/04/xmldsig-more#rsa-sha256” />
<ds:Reference URI="#id_033ceb7af8927a505dbaa64446d52d9fffa70dd4">
ds:Transforms
<ds:Transform Algorithm=“http://www.w3.org/2000/09/xmldsig#enveloped-signature” />
<ds:Transform Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” />
</ds:Transforms>
<ds:DigestMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#sha256” />
ds:DigestValueULhCdek0ig07wZUkJLvJGretGJ5nFXvLnJgzO6l/sSk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
ds:SignatureValue</ds:SignatureValue>
ds:KeyInfo
ds:X509Data
ds:X509Certificate
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
samlp:Status
<samlp:StatusCode Value=“urn:oasis:names:tc:SAML:2.0:status:Success” />
</samlp:Status>
</samlp:LogoutResponse>

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?

Grazie mille

Buonasera @Saverio,

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.

Cordiali saluti,
Michele D’Amico