Ho trovato qualche post simile ma niente di immediatamente calzante.
Supponiamo che un’amministrazione intenda realizzare un portale unico di accesso ai servizi online che offre., con l’idea di far autenticare una volta sola l’utente tramite SPID (credo si dica “single sign on”) e poi farlo passare senza ulteriori autenticazioni da un servizio all’altro (anche servizi che girano su sistemi diversi).
Immagino che serva un qualcosa che funga da “intermediario” fra i servizi offerti e gli identity provider, qualcosa che gli IDP vedano come un SP e che i singoli servizi vedano invece come un IDP.
Ora, esistono delle indicazioni su come i singoli servizi debbano interloquire con l’“intermediario” per garantire la correttezza dell’identificazione dell’utente?
Ci sono indicazioni su quali protocolli usare? Altri accorgimenti?
Oppure il sistema intermediario non serve nemmeno?
L’argomento del SingleSigneOn è delicato e in gran parte già regolamentato sia dal punto di vista tecnico, a a partire dalle specifiche SAML per arrivare alle specifiche tecniche di SPID.
Ti consiglio di dare una letta o chiedere a qualcuno che il tema lo conosce bene.
Ti fabbio un breve riassunto:
il SSO si può fare solo con credenziali L1 , il che per servizi della PA , a mio avviso , non serve pressoché a nulla
a mio avviso l’unica soluzione è “integrare” vari servizi in un unico portale
Grazie mille, approfitto della gentilezza. Per “integrare vari servizi in un unico portale” intendi organizzare graficamente i punti di accesso ai servizi e poi ogni singolo servizio si gestisce l’autenticazione tramite SPID?
Ciao, mi interessa molto, perché anche noi abbiamo il problema di diversi servizi che affiancano e si integrano con un sito web principale: certo poter fare login su tutti i servizi con SPID è già un grandioso risultato, ma ci stiamo chiedendo se non si possa pensare a un approccio che consenta a un cittadino di fare login una sola volta.
Noi stavamo pensando a un token JWT che si riceve dopo il primo login del cittadino, si archivia nel local storage del suo browser e si usa all’interno delle singole applicazioni per identificare l’utente e evitargli un ulteriore login. Il JWT è firmato e può essere verificato da ogni applicazione che lo riceve.
Cercando implementazioni di questo tipo, ho trovato questo: https://github.com/Aralink/ssojwt
che offre un esempio di implementazione pratica.
Qualcun altro ha già esplorato/escluso questa strada a priori?
Salve a tutti,
provo a rispondere
“L’autenticazione avviene sempre da una interazione tra un IDP ed un SP”, da cui deriva
“Un SP non può attestare l’avvenuta identificazione per un altro SP”
Altro scenario è quello descritto nell’avviso 6 di agid "Un nodo cluster è un sistema che mette a disposizione un insieme di servizi diversi. Il criterio di aggregazione di questi servizi può ad esempio essere basato sulla strutturazione interna dell’ente, esempio servizi erogati dallo stesso dipartimento oppure sulla responsabilità della gestione operativa dei servizi, esempio - nel caso di enti che si avvalgono di diversi fornitori – servizi erogati da uno stesso fornitore. La caratteristica di un nodo cluster è quella di avere un’infrastruttura condivisa per la gestione dei profili utente e per la gestione degli accessi, che operi come gateway unico verso i sistemi di autenticazione e di certificazione esterni. "
Riguardo all’ipotesi di utilizzare cookies o similari a lunga permanenza occorre fare attenzione ad alcuni rischi:
chi ottiene accesso al browser può impersonificare l’utente che ha effettuato login al “primo accesso”
in caso che l’identità sia revocata od invalidata non pare possibile revocare o invalidare automaticamente il token.
Personalmente sconsiglio questo approccio a meno di una attenta valutazione dei rischi in caso di perdita o furto del dispositivo o del token utilizzato.
Un saluto.
Luca Bonuccelli
Team per la Trasformazione Digitale
Salve, scrivo da un piccole Ente Ordine professionale per chiedere disperatamente aiuto. Abbiamo messo on line da inizio anno il nuovo portale web seguendo il layout AGID.
Volevamo permettere l’accreditamento ai nostri servizi tramite SPID ma, ad oggi nonostante numerosi solleciti a partire dallo scorso novembre a d AGID, tutto tace.
La nostra sw house sta tentando di divenire aggregatrice. Ha inviato il trattato per la verifica ma da allora nessuna risposta.
Ho provato a mia volta a scrivere senza ricevere riscontri.
Infine anche il tentativo presso Lombardia Informatica fino ad oggi non ha dato riscontro.
Ho personalmente sperimentato una soluzione basata su JWT, che trovo molto più semplice ed altrettanto efficace di SAML (anzi, direi più flessibile); si complementa bene con strumenti di autorizzazione di tipo RBAC.
Come unico appunto, suggerisco caldamente di NON utilizzare il localStorage/sessionStorage del browser, è una falla di sicurezza. Altrettanto dicasi per i cookie, la cosa migliore secondo me è quella di trasportare il token - per ogni richiesta autenticata - entro l’header “Authorization Bearer”. Per proteggersi dalla possibilità di intercettazione e replay della richiesta, consiglio l’utilizzo di due strategie congiunte:
gestire una sliding expiration del token, il che comporta l’onere, per l’Identity Provider, si esporre un servizio di rigenerazione del token stesso all’approssimarsi della scadenza
usare sempre la cifratura (https) sul canale di comunicazione
Una ulteriore considerazione riguardo: “Un SP non può attestare l’avvenuta identificazione per un altro SP”. In realtà sì, è possibile farlo; se due domini sono federati, è tecnicamente possibile utilizzare entro un dominio le credenziali ottenute dall’altro dominio. La federazione dovrebbe prevedere sia accorgimenti tecnici (utilizzo di un canale cifrato e autenticato mediante certificati digitali, da entrambi i lati), sia da un “contratto” scritto, a tutela delle parti.
