Continuiamo l’esplorazione di metodi di autenticazione alternativi al semplice login con user e password. Questa volta vediamo come OpenID possa essere combinato con il protocollo XMPP, cioè il protocollo utilizzato per Jabber e GTalk.

Il protocollo XMPP di base fornisce semplicemente un servizio che permette di sapere se un utente è online (la così detta presence), e di inviare/ricevere messaggi tra utenti, gli elementi base di ogni instant messenger come ICQ, MSN Messenger e tuti gli altri.

La base del protocollo è molto semplice e su di essa è possibile costruire servizi più avanzati aggiungendo dei “mattoncini” detti XMPP Extension focalizzati su problemi particolari.

Integrare OpenID con XMPP significa quindi solo implementare il mattoncino apposito, ovvero la proposta di Autenticazione XMPP per HTTP.

Supponiamo di esserci registrati presso un Relaying Party che supporti questo protocollo, come ad esempio The South African XMPP Federation OpenID Server. Al momento in cui effettuiamo il login, verrà generata una chiave unica, e il nostro relaying party ci contatterà via instant messenger chiedendoci di autenticarlo, e mostrandoci la chiave che abbiamo scelto per dimostrare che si tratta effettivamente di lui.

Se cerchiamo di effettuare il login su un sito abilitato ad openid, come ZoomR, saremo rediretti sul nostro relaying party, ma a questo punto non si pone il problema del phishing?

No, e qui sta il bello, perché non avremo nessuna password sul relaying party! Esso si limita a conoscere il nostro contatto, e il phishing diviene del tutto inefficace, perché non c’è nessuna password o informazione riservata che passi tra noi ed il relaying party.

Insomma, il protocollo sembrerebbe un’ottima idea, l’unico problema è che richiede l’interazione di tecnologie differenti, e potenzialmente di differenti programmi.

È A questo punto che fa comodo conoscere qualcuno che abbia scritto un client Jabber/gtalk come estensione per firefox. e suggerirgli che esiste questa possibile integrazione di openid con XMPP.. Poco dopo, vi trovate con questa estensione openid per firefox e flock che implementa la specifica di cui parlavamo prima.

Installando l’estensione, il login sul relaying party diviene quindi

• visita sito
• clicca il bottone per generare una chiave e poi il bottone “login”
• si apre una finestrella “autenticare X.com con la chiave ‘abcdefg’ ?”
• cliccare ok, se la chiave corrisponde

Semplicissimo, sicuro e veloce. L’unico relaying party a fornire questo servizio al momento è il già nominato South African XMPP Federation OpenID Server, che sembra funzionare bene (ma ha qualche tentennamento con Google Talk), e fornisce le funzionalità standard per essere utilizzato come delegate, cioè permettendo di usare un proprio dominio come url openid.

Il phishing è un tipo di attacco informatico nel quale l’attaccante finge di essere un sito web usato normalmente dall’utente, gli chiede di effettuare il login ed in questo modo entra in possesso dei suoi dati (generalmente username e password). Ovviamente però il phisher deve convincervi a visitare un sito che sia la copia più o meno identica di un sito reale, nel quale voi realmente avete un account.

Questo tipo di attacco è reso particolarmente insidioso laddove ci sia di mezzo un’autenticazione tramite OpenID, uno username e una password; ad esempio:

• Il phisher vuole accedere il vostro account su esempio.com, dove è possibile accedere tramite OpenID
• il phisher mette in piedi inutile.com, dove si può effettuare login con OpenID, e vi invita a farlo

Ora, tenendo a mente che quando effettuate un login con OpenID è il sito stesso che vi reindirizza verso il vostro Relaying Party:

• inutile.com scopre che avete un account su myopenid.com, e vi reindirizza su falso-myopenid.com, presentandovi una schermata che è identica a quella del vero sito
• a questo punto voi inserite i dati e il gioco è fatto

Questo può sembrare un grosso problema, specifico, di OpenID, e molti ne hanno già parlato ma la situazione non è così drammatica.

OpenID non impone il sistema di autenticazione (sia quella debole, con coppia login:password che quella forte), per cui non è “colpa sua” se esiste un (già riconosciuto) problema in questi sistemi di login.

Non solo, alcuni servizi, offrono un meccanismo antiphishing simile a quello che adotta Yahoo!. Il meccanismo è molto semplice; come essere sicuri che il sito a cui si accede sia quello che conosciamo? Si fa in modo che il sito ci dica una cosa che noi gli abbiamo già detto e che solo noi, presumibilmente, conosciamo. Nel caso di Yahoo! si tratta di una piccola immagine composta da tre parole e da uno sfondo colorato, ma può trattarsi di un’immagine o quant’altro.

IdProxy, un servizio che permette di effettuare login su siti OpenID utilizzando i dati di un account Yahoo!, e al momento dell’effettuato login mostra all’utente un mostriciattolo da lui scelto in precedenza. Se il mostro non è presente, l’utente può correre ai ripari andando sul vero sito ed aggiornando i propri dati.

Anche MyOpenid ha lanciato un paio di mesi fa un sistema analogo, quindi le speranze per un futuro più sicuro ci sono tutte.

Fino a poco fa credevo che la corsa di molti siti a trasformare i loro account in identità OpenID fosse poco utile e quasi un problema, perché poteva creare confusione agli utenti, che non sapevano che fare con tutte queste identità. Oggi invece mi sono ricreduto e sono passato esattamente all’opinione opposta. Il motivo di questo cambiamento è che ho iniziato a pensare meglio a come potrebbe essere descritto OpenID ad un utente non tecnico, magari poco pratico dell’internet. La conclusione a cui sono arrivato è che spiegare al pubblico come usare (non come funziona) OpenID è uno dei maggiori problemi per la sua adozione.

Con la diffusione di OpenID il classico “fai login o registrati” diventa: “scrivi qui il tuo OpenID, se non ce l’hai, registrati su quest’altro sito e poi torna qui ad usare il mio”. Messa così non è molto chiara, quindi spesso dovrà essere accompagnata da una breve spiegazione di cos’è OpenID, che per quanto breve e chiara, è sempre della roba da leggere e nessuno legge le istruzioni, lo sappiamo tutti. E se non legge le istruzioni non si iscriverà al nostro nuovo sito, perché non sa cosa scrivere in quel campo con l’icona arancione.

Questo problema è però praticamente risolto se l’utente ha già una (o più) identità fornite da altri servizi a cui è iscritto, perché gli si può dire più semplicemente che il sito riconosce gli indirizzi di Wordpress, quelli di AOL o quelli Microsoft, magari con qualche esempio esplicito, ed è fatta. La maggior parte degli utenti avrà già un account in qualcuno di quei servizi e non dovrà crearsi un’identità OpenID solo per accedere al nuovo sito che vuol provare.

Se poi tutti questi servizi che fanno anche da provider di identità, istruiscono anche gli utenti su come inserire nelle loro pagine la delegazione dell’identità, la faccenda si semplificherà ancora, trasformando quella che ciascuno considera la propria pagina personale nell’identità da usare.

La caratteristica fondamentale di OpenID è il fatto che il sistema sia completamente distribuito, e questo fa sì che ogni identity provider possa gestire autonomamente l’autenticazione, limitandosi a comunicare ai Relying Party (consumer) se il login ha avuto successo (tramite il redirect alla loro pagine di “benvenuto”).

Molti identity provider al momento si limitano al classico sistema di autenticazione tramite utente e password ma questo non è affatto l’unico sistema di riconoscimento e certo non è il migliore.

Prooveme.com e certifi.ca rappresentano due nuove entrate nella scena dei fornitori di identità permettendo agli utenti di utilizzare un sistema di autenticazione basato su crittografia forte e certificati SSL/X.509. Insieme ad altri sistemi come le smart card, gli OTP (one time password) o i riconoscimenti biometrici in questi casi si parla di autenticazione forte.

Utilizzando un certificato l’autenticazione verrà effettuata senza che ci sia passaggio di informazioni in chiaro e senza dover mai digitare password. D’altro canto, per effettuare l’autenticazione sarà necessario che il certificato sia presente su ogni piattaforma utilizzata per l’accesso, il che rende praticamente impossibile autenticarsi da terminali pubblici. È però possibile che questo problema venga affrontato a breve, magari permettendo un fallback insicuro, sebbene questo sconfigga in parte l’intento della tecnologia.

Tra prooveme e certifi.ca esiste una differenza importante: il primo prevede una registrazione e genera un certificato crittografico al volo che viene automaticamente importato nel vostro browser; questo a patto che tale browser non sia Internet Explorer, il quale non risulta ancora supportato in quanto cronicamente insicuro.

Certifi.ca al contrario non prevede alcuna forma di login: l’unico modo per accedere è essere già in possesso di un certificato, motivo per cui nella homepage viene mostrata una lista di possibili fornitori di certificati (tra cui thawte che ne rilascia gratuitamente). Ciò permette però di avere un livello di flessibilità maggiore, in quanto si può decidere di utilizzare Certification Authority specifiche per le proprie esigenze, nonché di decidere quanto debba essere forte il sistema crittografico, usando ad esempio chiavi RSA a 512 o 2048 bit.

In nome dell’interoperabilità, il certificato di prooveme funzionerà comunque anche con certifi.ca :)

Infine, entrambi i provider offrono la possibilità di essere usati come delegate, permettendo di utilizzare il proprio blog o sito web come identità elettronica.

Mentre stavo valutando di scrivere un bell’articolo che parlasse delle pratiche da utilizzare nell’integrazione dell’autenticazione OpenID sui nostri siti, ecco che sul wiki del sito ufficiale esce proprio un documento dal titolo Best practices for Relying Party.

Il documento è proprio un elenco di “pratiche” da adottare al momento dell’implementazione di OpenID sul proprio sito, che attiveranno le funzionalità relative. Queste funzionalità sono divise tra “Basic” (se non ce l’hai non puoi neanche dire di supportare OpenID), “Would Be Nice” (sarebbe carino trovarle), “Brilliant” (sono quelle, diciamo, un po’ più avanzate. Se ci sono è meglio, altrimenti pazienza).

Sarei partito diretto verso la traduzione, ma credo sia ancora troppo presto visto che si dichiara apertamente che quel documento è un work in progress.

This page lists some best practices for Relying Parties. This may one day become a quality review document for assessing the completeness of relying party implementations. For now, it’s just a work in progress.

Terrò sicuramente d’occhio quella pagina, nei prossimi giorni.

Approfitto dell’occasione per sottolineare che, con l’arrivo delle specifiche 2.0, andrà in pensione il termine Consumer, che in OpenID 1.x stava a denotare il client (ovvero, per estensione, il sito) che si connetteva all’identity provider (IdP). Adesso il termine da usare sarà, appunto, Relying Party. (“consumer” probabilmente continuerà ad essere usato all’interno delle librerie).

Infine, ancora sul tema divulgazione, vi segnalo un diagramma e la video spiegazione dello stesso dal titolo “OpenID Protocol”; direi abbastanza auto esplicativo, no?

Approfitto dell’occasione per mettere a disposizione una mia presentazione (one one), usata al barcamp di Torino qualche mese fa. C’è anche, volendo, la versione su slideshare.

Non è un granché, e sicuramente dovrei aggiornarla ma presto su questo sito prepareremo degli articoletti introduttivi più precisi e dettagliati.

phpbb-openid è un MOD di phpbb che permette l’autenticazione tramite OpenID a tutti i forum che usano questa piattaforma.

È appena stato annunciato un aggiornamento che implementa una delle innovazioni rese possibili da OpenID suggerite qualche giorno fa da Simon Willison.

Questa nuova versione riconosce gli OpenID che fanno capo ad AOL e:

• Se trova un utente con quell’account AIM già registrato, vi associa quell’OpenID, quindi l’utente potrà usare indifferentemente il suo account precedente o il nuovo OpenID
• Se non trova un utente con quello username AIM, ne crea uno nuovo e prepara già popolati i campi del suo account di instant messenger e quello del sito web

Gli sviluppatori hanno già assicurato il supporto per MSN/Live Mesenger quando Microsoft implementerà OpenID.

Oramai non passa giorno senza che qualche milione di utenti ignari si vedano racapitare un OpenID, spesso senza neanche sapere cosa sia.

Oggi è toccato a Wordpress.com, una delle piattaforme di blogging più diffuse, che ha annunciato il supporto a OpenID, trasformando tutti i suoi blog in identità valide.

Purtroppo Wordpress.com al momento funziona solo come ID provider, cioè è possibile usare l’URL del proprio blog come identità, ma non è possibile usare altre identità per autenticarsi su Wordpress.com.