Parametri

I parametri per la configurazione sono disponibili nell'Area Riservata, nella sezione per tecnici informatici: Single Sign On - parametri

Informazioni generali

Terminologia

• Single Sign On (o SSO): servizio che permette non solo un'autenticazione centralizzata, ma anche che la password venga richiesta una sola volta (questo aspetto sarà più chiaro più avanti)
• Service Provider (o SP): è il (tuo) servizio che necessita del SSO. Ad esempio, se hai un sito web che vuoi "mettere sotto Single Sign On", il sito web è chiamato Service Provider
• Identity Provider (o IDP): è il (nostro) servizio che effettua l'autenticazione (e non solo, come spiegato piu' avanti). L'utente che utilizza il tuo servizio verrà ad autenticarsi presso l'IDP
• Attributi: l'IDP non effettua solo l'autenticazione, ma fornisce all'SP anche alcune informazioni riguardanti l'utente; queste informazioni sono chiamate "Attributi". Queste informazioni vengono concordate fra te e noi.

Premesse

• Questa non vuole in alcun modo essere una trattazione esaustiva dell'argomento, ma fornire solo qualche spiegazione e qualche esempio pratico. Per una buona trattazione si rimanda alla documentazione ufficiale, i cui link sono disponibili alla sezione "Link utili"
• Negli esempi in questa pagina verrà considerata la configurazione probabilmente più diffusa, che vede Apache HTTP server come server web e "Shibboleth SP" come software di Serrvice provider

Come funziona il Single Sign On dal punto di vista dell'utente

• Premessa: IDP conosce i "metadati" dell'SP e l'SP conosce quelli dell'IDP; nei metadati ci sono le chiavi pubbliche rispettivamente dell'SP e dell'IDP. Queste chiavi pubbliche non hanno NULLA a che vedere con i certificati digitali utilizzati nelle rispettive interfacce web
• L'utente si collega con il browser ad un sito web (SP), che si avvale del servizio di SSO
• Quando deve autenticarsi (il quando viene stabilito da te, amministratore del sito web) il suo browser viene "rigirato" all'IDP, tramite un redirect. L'utente si trova quindi davanti la pagina di richiesta di autenticazione dell'IDP
• L'utente si autentica con successo (altrimenti viene ovviamente visualizzato un messaggio di errore)
• L'utente viene rispedito dall'IDP all'SP: in pratica, torna al sito web. Prima di rispedirlo indietro, pero', l'IDP manda all'SP tramite il browser (con un'operazione di POST) gli attributi dell'utente. Un esempio di attributi potrebbe essere: il numero di matricola, il nome, l'email, l'indirizzo di casa, se sia studente o dipendente o entrambi, ecc.ecc. Queste informazioni vengono concordate tra noi e te in fase di configurazione iniziale e possono essere ridiscusse in seguito. Gli attributi sono crittografati con il certificato digitale dell'SP e firmati digitalmente dall'IDP. Cio' significa che l'IDP è a conoscenza della chiave pubblica dell'SP e l'SP è a conoscenza della chiave pubblica dell'IDP. Questi certificati NON vanno confusi con i certificati utilizzati per il protocollo "https" utilizzati dal sito web e dall'IDP.
• L'SP riceve gli attributi, li decrittografa e verifica che la firma digitale sia dell'IDP, grazie alla chiave pubblica presente nei metadati (cfr. "Premesse"); quindi crea delle "environment variables" per il server web, che vengono quindi rese disponibili ai CGI, php, ecc.ecc. Quindi, nell'esempio del punto precedente, verranno rese disponibili all'applicativo del sito web delle variabili quali $_SERVER['shib_givenname'] per il cognome, oppure $_SERVER['shib_mail'] contenente tutte le email dell'utente, ecc.ecc.

Integrazione di un Service Provider con l'Identity Provider di Ateneo - passi

Premesse:

• esistono due Identity Provider, uno di produzione e uno di test. A meno che non sia sicuro della configurazione, ti consigliamo di iniziare con l'IdP di test e passare poi a quello di produzione. Gli step sono identici.
• esiste un Service Provider di test, grazie al quale effettuare delle verifiche sugli attributi prima di dover installare il suo SP; puoi trovare l'indirizzo del service provider di test alla sezione "Link utili"

1. [Tu] ci contatti e ci spieghi la tua idea. Insieme concorderemo gli attributi di cui hai bisogno. Avremo bisogno di un referente tecnico che seguirà il service provider (e gli aggiornamenti nel tempo).
2. [Noi] ti forniamo il link per i metadati dell'IDP (test e produzione) e il file attribute-map.xml (reperibile anche in questa pagina)
3. [Tu] Installi il service provider, lo configuri (lato shibboleth e lato web server) ed effettui un test, utilizzando il link per il login fornito in cima a questa pagina. In caso di difficoltà, oltre alle informazioni che stai leggendo, puoi far riferimento alla copiosa documentazione fornita dal sito ufficiale (vedi la sezione "Link utili"). Se ancora ci sono difficoltà puoi aprire un ticket al nostro helpdesk (link "CHIEDI@Helpdesk" in testa a questa pagina) e ci potrai chiedere cosa non ti sia chiaro. Al momento non forniamo supporto per server web diversi da Apache e software SP diverso da Shibboleth SP
4. [Noi] aggiungiamo i metadata del tuo SP: li recuperiamo in autonomia; se non fosse possibile, ce li spedisci per posta elettronica
5. [Noi] configuriamo il rilascio degli attirbuti che abbiamo concordato in precedenza
6. [Tu] effettui il test. Se ci sono problemi analizzi i log e se proprio non risolvi ci contatti tramite helpdesk. Se ci contatti dicendo semplicemente "non funziona", come puoi immaginare non possiamo fare molto, quindi circostanzia bene il problema, log di errore, screenshot della schermata che ti appare a video e tutto quanto possa essere utile per risolvere il problema
7. [Tu] mantieni il software aggiornato; ti consigliamo di iscriverti alla mailing list "Annoucements" di Shibboleth (link relativo alle mailing list nella sezione "Link utili")

Breve approfondimento per l'amministratore dell'SP

• Il service provider ha un server Apache installato. Tuttavia questo non è sufficiente per gestire le comunicazioni con l'IDP; ciò che svolge questo compito è un apposito software chiamato anch'esso, visto la sua funzione, SP; è un software che va quindi installato sul service provider e che sarà responsabile di "spedire" l'utente dall'IDP nel caso in cui questi non sia autenticato, di recepire i dati degli attributi provenienti dall'IDP e trasformarli in variabili di environment per il server web.
  Esiste più di una implementazione di questo software: quella da noi consigliata è quella chiamata "Shibboleth Service Provider"
• Il certificato digitale richiesto dal software di service provider (non il server web) è normalmente un self signed, con tempo di scadenza di molti anni; il motivo per il quale è bene che la scadenza si molto avanti nel tempo è che quando il certificato scade il tuo servizio non può più utilizzare il servizio di SSO, fino a nuovo certificato (che deve essere comunicato anche a noi, dal momento che causa una variazione dei metadati dell'SP, che devono quindi essere aggiornati nell'IDP)
• Ciò che a noi serve sapere del tuo SP sono i "metadati": si tratta di un file, generato automaticamente durante l'installazione del software di service provider, ma che ti consigliamo di riguardare e correggere, contenente informazioni quali: 
  • il tuo "entityID", l'identificativo UNIVOCO che utilizzeremo per identificarti, autenticare i tuoi utenti e darti i loro attributi
  • il certificato digitale del tuo SP
  • il link a cui l'IDP deve "rispedire" l'utente dopo l'autenticazione, con il POST contenente gli attributi
• I metadati dell'SP vengono di norma resi disponibili, all'indirizzo "https://tuoserver/Shibboleth.sso/Metadata": a meno che non ci siano problemi di firewall, i tuoi metadati li recuperiamo in autonomia, non ce li devi spedire. Controlla però:
  • che l'entityID sia univoco (che non abbia lo stesso nome di un altro SP che hai installato)
  • che il nome del server sia quello giusto
  • che sia presente il certificato digitale
  • (opzionale) che i vari servizi "AssertionConsumerService" siano quelli che ti servono (per capirlo devi leggere a fondo la documentazione)

• ciò che a te serve sono i metadati dell'IDP, reperibili nel link ad inizio pagina. Puoi configurare (CONSIGLIATO) il tuo software di service provider in modo che vada periodicamente a scaricarseli, in modo che sia sempre aggiornato
• ti servirà anche un file, chiamato "attribute-map.xml": è, come dice il nome, la mappatura di tutti gli attributi che rilasciamo. Gli attributi hanno un nome "scomodo", la mappatura li rende disponibili al tuo server web con un nome piu' comodo (ad esempio il tuo applicativo PHP può utilizzare l'attributo con la cittadinanza di un utente dipendente con la variabile di environment "shib_cittadinanzadip" anzichè "www.cca.unipd.it/sso/attributes/cittadinanzadip"). Non è obbligatorio, ma fortemente consigliato utilizzare questa mappatura: in caso di problemi diventa piu' semplice capirsi e si risparmia tempo per la risoluzione del caso.
• non è obbligatorio ma fortemente consigliato: tutte le pagine del sito che si trovino sotto Single Sign On dovrebbero utilizzare il protocollo https (quindi avrai probabilmente bisogno di un certificato digitale ufficiale)

Note sul logout

• esistono due tipi di logout: il logout locale ed il "Single Log Out".; nell'esempio di prima, un eventuale logout locale dal servizio di helpdesk manterrebbe attivo il servizio di webmail. Se provi a collegarti nuovamente con il servizio di helpdesk, pero', non ti verrà chiesta nessuna password, in virtù del fatto che sei ancora connesso al Single Sign On. Potresti quindi pensare che il logout locale non serva poi a molto; te lo confermiamo, non serve a molto; ciò che però serve è che tu sia a conoscenza di cosa succede dopo un logout locale, cioè che ci si può ricollegare senza password. Può comunque risultare utile in fase di test.
•  Il "Single LogOut"  riguarda la "disconnessione" dal SSO; cio' significa che questo logout ha effetto su TUTTI i servizi sotto Single Sign On di Ateneo a cui sei collegato. Un esempio: sei collegato al sito di helpdesk e a quello di webmail (con autenticazione SSO). Se effettui il logout dal servizio di helpdesk, vieni "scollegato" anche da quello di webmail; il logout locale, invece, riguarda il solo servizio sul quale effettui il logout il logout globale, o "Single LogOut" non è ufficialmente implementato su Shibboleth, ma noi abbiamo costruito una nostra implementazione, le informazioni sono ad inizio pagina

Link utili

• Sito ufficiale (documentazione e download): https://shibboleth.net/
• Wiki di Shibboleth: https://wiki.shibboleth.net
• Demo Shibboleth: https://www.switch.ch/aai/demo/
• Mailing list: https://shibboleth.net/community/lists.html
• Service Provider di test: https://shibsp.cca.unipd.it/secure/attributi.cgi
• Concetti di base: https://wiki.shibboleth.net/confluence/display/CONCEPT

Link utili nel service provider