LDAP

Il Lightweight Directory Access Protocol (LDAP) è, come suggerisce il nome stesso, un protocollo standard documentato nell’RFC 2251 per accedere a servizi di directory. Una directory è un database specializzato ottimizzato per la lettura e per la ricerca dei dati attraverso filtri sofisticati, in cui il dato è formato da un attributo e relativa descrizione (ad esempio “email=rossi@azienda.it”). Le directory, intese come database, non supportano transazioni complicate o azioni di rollback che si trovano nei classici RDBMS, di solito ottimizzati per le transazioni e gli aggiornamenti complessi. Gli aggiornamenti riguardanti i repository LDAP sono tipicamente rari, in quanto i dati sono semi-statici, semplici e non richiedono transazioni; invece il database è ottimizzato per dare risposte veloci a molte ricerche contemporanee. Molti dei directory server in commercio sono in grado di replicare il loro database per aumentarne l’affidabilità, la disponibilità quindi ridurre il tempo di risposta scalando orizzontalmente. Continua a leggere

Microsoft Active Directory

Nella mia esperienza di consulente presso fornitori di servizi, ho trovato differenti sistemi ottenuti per il Single Sign-On, quasi esclusivamente relativi ai soli servizi Web. Molti di essi si basano su un agente che si installa su un Web server e un “policy manager” che è in grado di autenticare/autorizzare l’utente ad una specifica risorsa. La tecnica impiegata è efficiente e raggiunge lo scopo per il Single Sign-On su sistemi Web, ma cosa succede se vogliamo autenticarci ad una risorsa non-Web, ad esempio collegarci via SSH ad un sistema Unix? Dovremmo ricordare un’ulteriore utenza e password. Questo non è sufficiente, in quanto la tecnica utilizzata deve coprire l’autenticazione utente a 360 gradi.

Secondo il mio modesto avviso, il produttore che è riuscito a effettuare un vero e proprio “Single Sign-On” è Microsoft: attraverso Active Directory, ovvero il nuovo modello di dominio introdotto da Windows 2000, è in grado di effettuare un’autenticazione su tutte le risorse di rete (condivisione file/stampanti, siti Web, ecc.) semplicemente facendo una “join” al dominio. Continua a leggere

Autenticazione web con Kerberos

Una delle cose sorprendenti dell’integrazione realizzata da Microsoft è relativa all’autenticazione degli utenti che hanno fatto log-on al dominio Active Directory sugli applicativi Web. Attraverso Internet Information Server (IIS) e il Web browser Microsoft Internet Explorer, l’utente viene riconosciuto trasparentemente, realizzando così un vero e proprio Single Sign-On. La tecnologia usata per effettuare un login dell’utente attraverso il Web è SPNEGO, già descritto nel paragrafo SPNEGO e l’autenticazione Web. Grazie allo sforzo della comunità OpenSource, è possibile utilizzare SPENGO anche su Unix, sia come client che come server Web. In questo capitolo spiegheremo come sia possibile realizzare con Apache l’autenticazione attraverso SPNEGO e Mozilla come client di autenticazione, oltre a vedere più da vicino l’utilizzo di Microsoft Internet Explorer. Continua a leggere

Posta elettronica e Kerberos

L’ultimo passo della nostra dimostrazione è relativo alla posta elettronica: anche in questo caso dobbiamo essere in grado di collegarci con il server di posta elettronica senza dover immettere le credenziali utente. Nel modello Microsoft il mail server Exchange usa un protocollo proprietario incapsulato su NetBIOS ed utilizza un sistema di autenticazione differente, che si basa sempre sul framework di SPNEGO. Il nostro scopo è quello di usare tecnologia Open, basata su standard quali SMTP e IMAP, ma in particolare si è deciso di focalizzarsi sull’autenticazione relativa ad IMAP. È possibile abilitare l’autenticazione GSSAPI anche per alcuni server SMTP, però a causa della scarsa disponibilità di client che supportano questo tipo di autenticazione, si è deciso di implementare la policy relativa all’invio di posta tramite il controllo degli IP address sorgenti. La mancanza di client, soprattutto in ambiente Windows, ha creato numerosi problemi durante la creazione del laboratorio. Esistono infatti numerosi client Unix e MacOS X, ma pochi sono quelli per Windows, probabilmente perchè alcuni sviluppatori Windows considerano Kerberos un qualcosa di troppo “nuovo” e ancora poco conosciuto, mentre altri lo considerano “troppo vecchio”, ignorando che l’intera architettura di Active Directory è basata proprio sul “vecchio” Kerberos. Continua a leggere

Infrastruttura Single-Signon Unix

Una volta definito l’ambiente in cui verrà sviluppato il modello, si è proceduto alla scelta dei programmi da integrare: la scelta è ricaduta su programmi OpenSource, in quanto più facilmente reperibili ed eventualmente modificabili. È possibile realizzare la stessa infrastruttura con programmi supportati, ma bisogna verificare con il produttore se le funzionalità siano disponibili, ad esempio se l’LDAP server supporta Kerberos come password back-end.

Preparazione del DNS

Kerberos richiede che vi siano alcune entry nel DNS che puntino ai servizi erogati, anche se pochi programmi sembrano cercare queste entry. È bene verificare che il reverse look-up di ciascun server sia garantito: alcuni problemi legati al kerberos sono relativi al fatto di non riuscire a risolvere in modo corretto i nomi. Per quanto riguarda il laboratorio, questo è il DNS relativo alla parte kerberos: Continua a leggere

1 2 3 4