Autenticazione e programmazione

Visual Studio 2010, il rinnovato ambiente di sviluppo di Microsoft, è disponibile da circa un mese. Tra le sue principali novità, ce n’è una che senz’altro vale la pena di essere trattata: l’autenticazione e la gestione dell’identità. Da questa release è infatti disponibile un nuovo componente, denominato Windows Identity Foundation , che si occupa di gestire per intero l’aspetto dell’identity all’interno delle applicazioni: un passo necessario a garantire maggiore indipendenza del codice da questioni relative all’accesso ai servizi, soprattutto in un’era in cui sempre più spesso le informazioni viaggiano su sistemi distribuiti o addirittura nella cloud.

Punto Informatico ha discusso di questi temi con Vittorio Bertocci , italiano trapiantato a Redmond che di fatto è l’evangelist per le questioni di identity per la piattaforma dotNET. Autore di tre libri sull’argomento, l’ultimo è in uscita, nel corso di un suo viaggio in Italia Bertocci ha accettato di rispondere ad alcune domande relative allo scenario complessivo della gestione dell’identità online (fattore quanto mai attuale, viste le recenti polemiche relative a Facebook e alla privacy), oltre ad offrirci alcuni spunti su cosa dovremo aspettarci per il prossimo futuro in questo campo.

Punto Informatico: Tanto per cominciare, una domanda che solo all’apparenza è semplice: perché parlare di identity quando si tratta di un ambiente di sviluppo?
Vittorio Bertocci: Identity è un argomento particolare. Abbiamo avuto tanti tentativi, più o meno riusciti, nella storia del software in cui sostanzialmente siamo riusciti a proteggere lo sviluppatore dal gestire direttamente alcuni dettagli o aspetti marginali dell’applicazione. Questo però non è avvenuto in questo ambito.

PI: Possiamo fare un esempio?
VB: Per esempio oggi non devi preoccuparti, se non in casi particolari, della dimensione del monitor su cui verrà presentata la tua applicazione. Quando ti occupi di autenticazione oggi, invece, devi ancora implementare le API dei servizi che vuoi usare: che si tratti di certificati, Active Directory ecc, devi conoscere le diverse tecnologie per poterle implementare. L’unico caso in cui non devi farlo è quando crei una forte dipendenza dalla tua infrastruttura: se sei nella tua intranet, tutti possono accedere ma solo perché sono sotto la supervisione del domain controller .

PI: Ed è uno scenario improbabile?
VB: Oggi è normale avere molte persone che collaborano alla tua attività: ci sono i consulenti, i reseller, i partner, i rivenditori, tutte entità che in qualche modo devi autenticare. Poi c’è la questione della salvaguardia degli asset, ovvero bisogna badare all’eventuale duplicazione dell’informazione per evitare che i dati manchino di coerenza. Se un impiegato lascia l’azienda, devi garantirti ad esempio di disabilitare i suoi account: ma se sei costretto a farlo più volte in più punti ti stai complicando la vita.

PI: Dunque ci sono buone ragioni per affrontare adesso il problema.
VB: La parola d’ordine è: razionalizzazione. Vorremmo che questo problema, come altri, non fosse un problema dello sviluppatore. Quando quest’ultimo pensa alle applicazioni, dovrebbe preoccuparsi di cosa l’applicazione dovrà fare o non dovrà fare, deve preoccuparsi dell’esperienza utente e non delle molte API da implementare. Con questo spirito, già dal 2006-2007 abbiamo guardato alla nostra offerta e alle proposte di partner e competitor: ci siamo resi conto che c’erano già gli standard necessari a lavorare coerentemente in questo ambito, in modo tale che invece di dover scrivere ogni volta il codice per creare i meccanismi di autenticazione, tu possa limitarti ad avviare una procedura formalizzata, ad alto livello.

PI: In altre parole?
VB: È il concetto di service orientation applicato alla identity. Si prendono le unità di business che possiedono le informazioni riguardo agli utenti, la cosiddetta “authority” in materia, e gli si offre la possibilità di esporre un’interfaccia – magari via browser – in cui mettere a disposizione gli strumenti necessari all’autenticazione. Come programmatore tu scrivi la tua applicazione, e quando hai bisogno di informazioni sull’identificazione ti diamo le API per ottenere queste informazioni, ma senza dover conoscere i dettagli di come vengono raccolte. È la base di quello che si chiama Windows Identity Foundation , che consente di fare “outsourcing” dell’autenticazione e semplifica la vita dello sviluppatore. PI: Utile, ad esempio, nel caso dell’autenticazione su diversi siti dello stesso network.
VB: Esatto, basta inserire un indirizzo dove trovare le informazioni nel codice, c’è un wizard che fa tutto con pochi clic. E la faccenda ha anche dei risvolti interessanti legati alle problematiche della liability , ovvero la responsabilità. In ogni caso, è assolutamente vero che questo approccio semplifica la gestione dell’identity su un network, e offre possibilità interessanti per gestire le informazioni disponibili su un utente su più di un sito: ovviamente, previo consenso.

PI: Un servizio che offre sempre dei vantaggi?
VB: Il risultato è che con l’interfaccia si può utilizzare lo stesso sistema di autenticazione in più applicazioni, e questo è assolutamente utile su Internet e più in generale quando l’accesso degli utenti avviene da più punti. In realtà, però, c’è una differenza sostanziale tra i “requisiti” per Internet e quelli per il business: nel mondo degli affari ci sono in ballo spesso questioni economiche, quindi c’è da tener in maggiore considerazione il problema dei ruoli – a seconda della tua mansione hai “poteri” diversi – e le informazioni che si possiedono sull’utente sono in qualche modo più importanti. Per fare un esempio, nel caso un utente abbia il potere di firma per un’azienda, l’account deve prevedere livelli di protezione e poteri conseguenti adeguati per salvaguardare la sicurezza e garantire la funzionalità.

PI: Su Internet è diverso?
VB: Quando ci si sposta su Internet ci si trova davanti almeno due tipi di scenario: alcuni utenti si preoccupano poco o nulla della privacy, gli interessa solo l’agilità. Altri sono molto preoccupati, invece, ed è l’approccio prevalente nelle strutture governative: a volte è anche una necessità, in alcuni casi siti anche della stessa proprietà non devono essere in grado di incrociare i dati per riconoscere gli utenti, così da garantirne la privacy.

PI: Esiste il modo di conciliare queste visioni?
VB: Diciamo che la tensione tra gli scenari di questo tipo sussiste. Su questi ultimi aspetti della gestione delle informazioni siamo comunque piuttosto avanti: esiste una tecnologia, chiamata U-Prove , che implementa un nuovo tipo di cifratura: un identity provider può fornire informazioni necessarie riguardo l’utente rispettando la privacy, in pratica si possono fornire documenti provenienti da entità riconosciuta senza doverne esaminare necessariamente l’interno.

PI: Un esempio per comprendere meglio?
VB: L’applicazione più semplice da immaginare è il voto a distanza. Posso inviare un documento che contiene la mia preferenza e segnalare “ho votato” al server: quest’ultimo è in grado di verificare se ho votato o meno, ma non è in grado di scoprire la mia preferenza. Lo scrutatore, invece, potrà accedere all’informazione sul mio voto senza conoscere la mia identità. Il sistema funziona bene, ma questo tipo di tecnologia richiede un impegno leggermente superiore a livello di infrastruttura.

PI: Occorre quindi tenere conto dei limiti delle attuali implementazioni in campo.
VB: Bisogna tenere conto anche della distanza tra le varie tecnologie in gioco: quando lavoro su Web devo essere consapevole dei limiti del browser e così via. Molte tecnologie di identificazione comuni – come OpenID, ma solo per capire di quali tecnologie stiamo parlando, non è il caso specifico – fanno riferimento a una URL per ottenere informazioni sull’utente. Quest’ultimo invece tende a identificarsi con l’email, non con un indirizzo, quindi meglio usare la posta elettronica.

PI: Non c’aveva già provato Microsoft, con MSN Passport?
VB: Il problema di MSN Passport è che viene controllato da una sola entità. In questo caso stiamo parlando di standard, nel caso di Open ID ci sono di mezzo Google e molte altre aziende, lo scopo è ottenere uno spazio comune dove interoperare e poi ciascuno crea la propria implementazione. Non c’è competizione: c’è e ci sarà un accordo sulla parte comune, e poi ciascuno svilupperà i propri servizi. Alla fine, però, tutto funzionerà con tutto. PI: Sembra interessante, ma sta procedendo tutto a meraviglia?
VB: Tutto sta evolvendo: OpenID deve svolgere un compito difficile, quando arrivi su una pagina deve capire chi sia il tuo identity provider , ma il problema è che in giro ci saranno moltissimi soggetti, anche solo nazionali, che saranno in grado di farlo. OpenID affronta il cosiddetto Nascar problem : se io, italiano, sono utente di un provider italiano, quando vado negli USA mi aspetto che il mio ID funzioni anche con servizi USA. Ma negli USA, probabilmente, non avranno mai sentito parlare del mio provider: le università, ad esempio, sarebbero degli ottimi fornitori di identità e autenticazione, ma ce ne sono migliaia al mondo.

PI: È stata trovata una soluzione a questa complessità?
VB: La soluzione potrebbe essere tenere una lista di potenziali servizi sulla tua macchina, in modo da evitare un sovraffollamento di marchi e loghi sulle pagine dei servizi. Ma, anche qui, occorre trovare un accordo tramite una discussione in modo da garantire la standardizzazione.

PI: Tutto questo dovrebbe semplificare la vita al programmatore?
VB: I problemi che saltano fuori in questo momento con l’implementazione a basso livello sono evidenti a tutti gli sviluppatori. Usando questo approccio si dovrebbe permettere di semplificare la vita allo sviluppatore finale, ma permettere anche al contempo all’esperto di sicurezza, all’architetto del sistema, di avere a disposizione gli strumenti per avere un’architettura scalabile, multipiattaforma, e che rispetta le regolamentazioni del caso.

PI: Una separazione dei compiti.
VB: Lo sviluppatore di interfacce utente non si deve occupare dell’autenticazione, ma ovviamente bisogna preordinare certe cose a monte. Si possono però in questo modo anche prevedere servizi particolari, che consentano l’integrazione federale di strutture dati differenti. Si possono gestire, tramite metadati, anche strumenti avanzati in grado di distinguere quale entità stia interrogando il sistema: è un’applicazione, un utente, un altro service provider? Di volta in volta si scelgono i protocolli migliori da usare, quali sono le informazioni giuste da fornire e quali invece non vanno fornite affatto. Senza contare che in questo modo si semplifica non poco la gestione dei certificati in scadenza, dei cambi di brand o dominio.

PI: Come si gestiscono in questo senso le esigenze e le istanze di sviluppatori locali, in questo caso italiani, rispetto a quelle della azienda che sta dall’altra parte del mondo?
VB: Lato cliente abbiamo un processo strutturato, che si è evoluto negli ultimi 15 anni, che coinvolge una serie di partner di tutto il mondo nello sviluppo delle applicazioni e nel test della beta, in modo tale da verificare che tutto funzioni anche al di fuori degli USA. Per quanto riguarda standard e regolamenti, siamo presenti nelle board dei vari comitati e siamo parte della discussione per l’elaborazione di questi protocolli. Forse in passato non avevamo dato il giusto peso al valore degli standard, ma oggi cerchiamo di tenere in maggiore considerazione questi aspetti.

PI: Stiamo arrivando su un terreno delicato, quello degli standard.
VB: Tra tutte le cose che facciamo, identity è senz’altro un tema rappresentativo: quando il processo di apertura su questi temi è iniziato, Kirk Cameron – il nostro architetto dell’identity – ha aperto un blog e ha invitato tutti gli interessati a discutere con lui della problematica, per cercare e trovare la soluzione assieme. La discussione è ancora disponibile e consultabile, e scorrendola si vedono prendere forma le “leggi dell’identity”: queste hanno permesso di coinvolgere tutta l’industria in un processo, e ora che la vision comincia a concretizzarsi si vedono i risultati.

PI: anche in questo caso, ci sono esempi?
VB: Ci sono in circolazione vari prodotti sviluppati da aziende diverse, ma che sono in grado di parlarsi attraverso piattaforme differenti. Ci sono esempi di ogni tipo di questa ritrovata interoperabilità: Stonehenge stock trader è uno di questi. Tutti i componenti del progetto sono scritti in modo tale da sfruttare ogni tecnologia coinvolta, in modo intercambiabile, e abbiamo potuto individuare i casi in cui lo standard era stato interpretato in modo differente da vendor differenti e ricavare una interpretazione unica dello standard. PI: Stiamo parlando sempre di aziende, ma è normale che siano loro a modellare questi strumenti?
VB: Personalmente credo sia importante che le aziende, ovvero le entità che meglio comprendono la tecnologia coinvolta e sanno cosa fare sul piano pratico, quando ne hanno la possibilità creino le tecnologie necessarie. Le policy ovviamente le stabilisce l’ente governativo, ma le aziende hanno il compito di lavorare sul mercato, ed è quest’ultimo a stabilire e imporre dei requisiti a tutti. Chi pensava a Twitter 3 anni fa? E chi pensava alle cartelle mediche elettroniche prima che si sviluppassero terminali mobile come quelli che ci sono in circolazione adesso?

PI: Quindi non c’è alcuna fuga in avanti dell’industria?
VB: Di solito quello che accade è che si mette in pratica il più classico dei modelli darwiniani: c’è interazione tra tutti i soggetti coinvolti, e si mettono assieme le richieste per cercare il compromesso migliore. Siamo in costante dialogo con tutti, ci sono momenti espliciti di sincronizzazione. È un ciclo continuo, ma non ci sono vendor indipendenti dai governi.

PI: Il vostro compito è quindi creare degli strumenti.
VB: Il movimento verso la cloud e il SaaS sta accelerando la corsa a risolvere i problemi dell’autenticazione e dell’identity. L’effetto immediato degli strumenti che abbiamo introdotto con Visual Studio 2010, e che sono retrocompatibili con il framework 3.5, è che ora ci sono tutti i tool necessari a gestire l’autenticazione in locale e in remoto.

PI: Restano ovviamente in piedi altre questioni.
VB: Resta ad esempio in piedi il problema della liability , ovvero come abbiamo detto della responsabilità. Noi pensiamo di aver contribuito risolvendo la questione identity, e stiamo imparando adesso a comprendere queste problematiche. Cerchiamo di preparare le soluzioni tecniche in anticipo affinché ci si trovi pronti ad affrontare le regolamentazioni o ad applicare le soluzioni quando saranno standardizzate.

a cura di Luca Annunziata