Buonasera,
ho letto il documento del 20/04/2016 relativo alla gestione delle sessioni e del Single Logout:
qualcuno ha implementato il meccanismo di logout?
E’ obbligatorio in caso di autenticazione di livello 1? (SpidL1)?
Ho l’impressione che molti enti richiedano il livello 2 solo per non dover gestire i meccanismi di logout.
Ho provato ad entrare nel sito dell’ ACI (richiede SpidL1), ma la mia impressione è che la sessione del sito sia gestita autonomamente.
Grazie
Ciao @Valerio_Mozzambani,
il single logout è da implementarsi solo per servizi di livello 1 SPID in quanto da livello 2 in su non è applicato il single sign on.
Riguardo la sessione c’è una sessione applicativa e una SPID.
Ho effettuato un check su ACI e sembra che stacchi solo la sessione locale (applicativa) e non quella SPID.
Segnalo la cosa.
Grazie della segnalazione
Umberto Rosini
Agenzia per l’Italia Digitale
Grazie!
Quindi se richiedo un’autenticazione con livello SpidL2, poi posso far lavorare gli utenti in una sessione locale?
(ad esempio come fa INPS e gli altri servizi che ho testato)
Corretto,
riguardo SAML è da impostarsi AuthForce = true nel caso di livello SPiD > 1.
Ciao
Umberto Rosini
Agenzia per l’Italia Digitale
Salve @umbros,
mi servirebbe un chiarimento sulla gestione della sessione di Lv1.
Nel caso di più applicativi erogati da un particolare ente, ogni qualvolta l’utente accede ad uno dei servizi dovrebbe loggarsi o al limite scegliere l’IDP desiderato e in caso fosse già loggato su quest’ultimo autorizzare il passaggio dei dati da IDP al SP.
Corretto ?
Se ciò fosse vero, dal punto di vista dell’esperienza utente c’è un modo per evitare tale comportamento (mi riferisco al fatto di dover ribalzare sui singoli IDP al cambio di applicativo) ?
Posso essere i singoli applicativi aggregati in quanto verso il cittadino si comportano come un unico servizio ?
Grazie
Ciao @francesco_fornasiero,
Corretto, diverse è la logica portal per cui all’interno di un unico sistema convivono più applicativi (modello INPS).
Si confermo.
Umberto Rosini
Agenzia per l’Italia Digitale
Corretto, diverse è la logica portal per cui all’interno di un unico sistema convivono più applicativi (modello INPS).
Graizie @umbros, ma ciò significa che può essere implementato un qualche meccanismo di mantenimento della sessione ?
Mi rieferisco al fatto che per aggregare gli applicativi, questi han bisogno di condividere il profilo utente.
Ciao @francesco_fornasiero,
ci sono due tipologie di sessioni: quella locale (applicativa) e quella spid. Lo sviluppo “portal” di un sistema di servizi prevede che i servizi stessi condividano la stessa sessione come si trattasse di un unico servizio. Resta fermo che, ad esempio per operazioni dispositive, si possa di nuovo richiedere l’autenticazione Spid. Ovviamente valgono tutte le raccomandazioni di sicurezza per evitare, ad esempio, un rischio di Session Hijacking.
Umberto Rosini
Agenzia per l’Italia Digitale
Qualcuno ha già implementato la gestione del logut dalla sessione globale in Java (io sto usando tomcat su liferay)?
Mi riferisco al caso più complesso, quello in cui l’utente fa logout dall’IDP o un logout globale da un SP di terze parti e viene notificata al mio SP la richiesta di logout.
Come avete implementato tale meccanismo?
Sto provando un approccio in cui, al momento dell’inserimento dello user nella sessione (durante il login), associo l’id session SPID alla sessione locale e al momento della chiamata del logout faccio scadere la sessione corrispondente all’id notificato;
qualcuno ha già provato questa strada o esiste un sistema più semplice?
Grazie
ciao @Valerio_Mozzambani,
in alcuni casi ho avuto il tuo stesso problema, e l’ho risolto “circa” come dicevi tu.
Sono inanzitutto passato a una backend stateless quindi senza necessità della sessione applicativa e l’iterazione fra “frontend” e “backend” è basato su “token”.
Quando arriva la richista di logout il “token” viene invalidato quindi a tutte le richieste future il backend restituirà “token expired”.
Detto questo dipende molto da quale canale esponi per fare il logout? SOAP? HTTP Redirect? HTTP POST?
In generale il mio consiglio è quello di non farti un’implementazione custom ma di usare librerie che gestiscono in automatico per te l’iterazione fra il tuo applicativo e l’idp SPID.
In particolare mi vengono in mente come soluzioni:
Metti davanti alla tua applicazione mod_shib (shibboleth sp)
oppure
Sempre rimanendo in tema java integra nel tuo applicativo pac4j
Ho usato entrambi e metodo con successo e la tematica da te richiesta è già gestita.
Grazie @cata86,
sto cercando di implementare un sistema generico per liferay, quindi deve gestire anche le sessioni.
Ho visto che esiste già un’implementazione molto simile per CAS che si comporta più o meno come avevo descritto.
Ciao @umbros,
sto proseguendo con l’implementazione delle sessioni e del single logout, ma non riesco ad inviare la richiesta di logout all’IDP (PosteId nel mio caso):
ricevo sempre un html contentente il messaggio “Formato richiesta non corretto - Contattare il gestore del servizio”
Questa è un esempio di richiesta:
<saml2p:LogoutRequest xmlns:saml2p=“urn:oasis:names:tc:SAML:2.0:protocol” Destination=“https://posteid.poste.it/jod-fs/sloservicepost” ID="_f303fba1-11b9-4b1b-b6b2-7dc5cf557003" IssueInstant=“2018-01-24T16:36:10.775Z” Version=“2.0”>
<saml2:Issuer xmlns:saml2=“urn:oasis:names:tc:SAML:2.0:assertion” Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity” NameQualifier=“SPEntityID”>SPEntityID</saml2: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="#_f303fba1-11b9-4b1b-b6b2-7dc5cf557003">
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/2000/09/xmldsig#sha1”/>
ds:DigestValueMsWzfdvQpNAVs1RZ4bzAdCJ5VPk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
ds:SignatureValue…firma…</ds:SignatureValue>
ds:KeyInfo
ds:X509Data
ds:X509Certificate…certificato…</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:NameID xmlns:saml2=“urn:oasis:names:tc:SAML:2.0:assertion” Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:transient” NameQualifier=“SPEntityID”>spEntityId</saml2:NameID>
saml2p:SessionIndexclHnaQvl895GNas9EfMemsW2MlFXjq4Q79LwO3QzeKNeIi1qR3cUsw==</saml2p:SessionIndex>
</saml2p:LogoutRequest>
La invio con una POST all’ url “https://posteid.poste.it/jod-fs/sloservicepost” come parametro SAMLRequest=base64_della_richiesta
Inoltre nella chiamata POST inserisco i seguenti header:
conn.setRequestProperty(“User-Agent”, “Mozilla/5.0”);
conn.setRequestProperty(“Content-Type”, “application/x-www-form-urlencoded”);
conn.setRequestProperty(“Content-Length”, String.valueOf(urlParameters.getBytes(“UTF-8”).length));
conn.setRequestProperty(“Accept-Language”, “t-IT,it;q=0.9,en-US;q=0.8,en;q=0.7”);
Mi manca qualcosa? (qualche parametro, la compressione?)
L’errore mi fa pensare più ad un problema nella chiamata piuttosto che nell’xml della richiesta.
Mi sembra che stai utilizzando sha1 che è deprecato.
Umberto Rosini
Agenzia per l’Italia Digitale
Ok, provo a controllare, ma non credo sia quello il problema perché le richieste di login le firmo esattamente allo stesso modo (l’algoritmo che uso come SignatureMethod è sha256, quello in sha1 è solo il ds:DigestMethod che non so come levare, ma non credo sia obbligatorio)
<saml2:Issuer xmlns:saml2=“urn:oasis:names:tc:SAML:2.0:assertion” Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity” NameQualifier=“SPEntityID”>SPEntityID</saml2:Issuer>
L’issuer è corretto? Sono da telefonino e sto cercando di capire l’asserzione 
Umberto Rosini
Agenzia per l’Italia Digitale
Ho provato a valorizzare l’issuer sia con il l’entityID del SP che con quello dell’ IDP;
la documentazione dice di valorizzarlo con l’entity a cui è inviata la richiesta anche se secondo me dovrebbe andarci l’entity che sta inviando la richiesta (per questo ho provato anche questa soluzione).
In realtà il meccanismo del logout ha anche altri punti che non mi sono chiari:
-edit- Confermo che non è il digest la causa del rifiuto: l’ho impostato a SHA-256.
I miei sospetti si orientano sul campo NameID che, da quanto capisco dalla documentazione, deve specificare “il soggetto a cui si riferisce l’evento di autenticazione”:
Ok, ho risolto: avevo abagliato a scrivere il form input ‘SAMLRequest’, impostavo il NameID sbagliato (non prendevo quello restituito nella response al momento dell’autenticazione) e sbagliavo il meccanismo:
cercavo di fare un POST direttamente dall’applicazione e non dallo UserAgent (questo spiega perché sono previsti sia i metodi POST che redirect).
Ciao.
Approfitto di questo thread “fresco fresco” sul logout di spid per sottoporvi una questione.
A pagina 7 del Regolamento Tecnico si legge:
“…
nell’ elemento <logoutRequest> devono essere presenti i seguenti elementi:
l’elemento <Issuer> attualizzato come l’attributo entityID riportato nel corrispondente metadata, a indicare l’identificatore univoco dell’entità (gestore delle identità o fornitori di servizi) emittente. L’elemento deve riportare gli attributi:
Format fissato al valore “urn:oasis:names:tc:SAML:2.0:nameid-format:entity”;
NameQualifier che qualifica il dominio a cui afferisce tale valore (URI riconducibile alla stessa entità emittente);
…”
Quindi il tag Issuer dovrebbe essere una cosa del tipo:
<saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion” Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity” NameQualifier=“SERVICE_PROVIDER_WWW”>SERVICE_PROVIDER_WWW</saml:Issuer>
Purtroppo questo viola le specifiche SAML2.0 https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
8.3.6 Entity Identifier
URI: urn:oasis:names:tc:SAML:2.0:nameid-format:entity
Indicates that the content of the element is the identifier of an entity that provides SAML-based services (such as a SAML authority, requester, or responder) or is a participant in SAML profiles (such as a service provider supporting the browser SSO profile). Such an identifier can be used in the <Issuer> element to identify the issuer of a SAML request, response, or assertion, or within the <NameID> element to make assertions about system entities that can issue SAML requests, responses, and assertions. It can also be used in other elements and attributes whose purpose is to identify a system entity in various protocol exchanges. The syntax of such an identifier is a URI of not more than 1024 characters in length. It is RECOMMENDED that a system entity use a URL containing its own domain name to identify itself.
The NameQualifier, SPNameQualifier, and SPProvidedID attributes MUST be omitted.
Quindi, dato che per il tag Issuer il valore del Format = “urn:oasis:names:tc:SAML:2.0:nameid-format:entity” è il default, per cui può essere omesso
e che il NameQualifier DEVE essere omesso, il tag issuer corretto è:
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">SERVICE_PROVIDER_WWW</saml:Issuer>
Il tutto ci è stato confermato da Scott Cantor, referente della community Shibboleth, nonché autore dello standard saml2.0 a cui abbiamo posto il quesito specifico.
Shibboleth SP non riesce a generare questo tipo di asserzioni SAML (in quanto errate), per cui il logout (globale) conforme alle specifiche agid non è di fatto implementabile con questo software e alcuni IDP sono molto restrittivi in questo controllo delle logoutrequest.
Saluti
Marcello Marangio
InnovaPuglia S.p.A.
Se ti può essere utile, da quello che ho capito, il campo va valorizzato con :
<saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion” Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity” NameQualifier=“SERVICE_PROVIDER_ENTITY_ID”>SERVICE_PROVIDER_ENTITY_ID</saml:Issuer>
SERVICE_PROVIDER_ENTITY_ID nel caso dell’implementazione SPID ha il formato di un url
Le richieste costruite in qusto modo vengono interpretate correttamente (almeno nel caso di PosteID, altre prove non le ho ancora fatte)
grazie per la risposta.
si per il login non ci sono problemi: shibboleth si riesce a pilotare.
Il problema si pone nel logout, che in shibboleth non è modificabile.
saluti
M