Nel precedente articolo, dedicato all'autenticazione di base HTTP, avevamo visto come fosse possibile creare in maniera molto semplice e rapida un'area riservata memorizzando le credenziali dei nostri utenti in file di testo.
Avevamo però sottolineato alcuni limiti della soluzione proposta, in particolare la trasmissione di username e password in chiaro e l'inefficienza del sistema di gestione degli utenti e dei gruppi. In queste pagine vedremo come ovviare a tali inconvenienti introducendo prima l'autenticazione HTTP Digest e poi metodi alternativi per la conservazione delle credenziali.
Mod_auth_digest e l'autenticazione MD5 digest
Questo modulo di Apache si propone come sostituto più sicuro di mod_auth_basic in quanto evita il passaggio di credenziali in chiaro, senza peraltro complicare le direttive di configurazione. La Digest Authentication è sostanzialmente un'applicazione dell'algoritmo di hash MD5, unita ad alcuni accorgimenti volti a prevenire l'utilizzo della crittoanalisi per forzare le credenziali. A scanso di equivoci è bene chiarire che il suo scopo è rimpiazzare la deficitaria autenticazione di base HTTP, ma non risulta assolutamente paragonabile ai protocolli di autenticazione "forte".
Per confrontare l'utilizzo di mod_auth_digest con l'utilizzo di mod_auth_basic vediamo un esempio del tutto analogo a quello mostrato nel precedente articolo. Vogliamo consentire solo ad alcuni utenti l'accesso alla directory amministrazione del nostro sito. Ricordo che le direttive mostrate possono riferirsi ad un contenitore <Directory> o ad un file .htaccess posizionato nella directory che vogliamo proteggere.
AuthName Amministratori AuthType Digest AuthDigestDomain /amministrazione/ AuthDigestProvider file AuthUserFile /percorso_del_file/password Require valid-user
AuthName: nel precedente articolo ci eravamo riferiti a questa direttiva per impostare la dicitura della finestra di dialogo che il browser presenta al momento del login. Il significato è in realtà più ampio ovvero consente di specificare il realm (traducibile all'incirca come reame) ovvero l'ambito d'azione della protezione. Risulta importante, come vedremo, nella definizione degli utenti autorizzati all'accesso.
AuthType: indica il tipo di autenticazione in questo caso anziché Basic, specifichiamo Digest.
AuthDigestDomain: la documentazione ufficiale consiglia caldamente l'utilizzo di questa direttiva, anche se non strettamente necessaria, per ragioni legate alle prestazioni del web server. Consente di specificare una o più URI che sono protette mediante i medesimi username e password, in altri termini che fanno parte del medesimo realm. Si parla in generale di URI perchè possiamo specificare una risorsa sia come relativa, vedasi esempio, sia come assoluta indicando protocollo, host, etc. come in http://www.miosito.it/segreta/. Ricordo che risulteranno automaticamente protette anche le sottodirectory dell'URI specificata.
AuthDigestProvider: svolge il medesimo compito di AuthBasicProvider comunicando ad Apache che utilizzeremo dei file di testo per memorizzare le credenziali.
AuthUserFile: specifica il percorso ed il nome del file di testo utilizzato per raccogliere i nomi degli utenti e le relative password. È sempre meglio che il file si trovi all'esterno della DocumentRoot per non essere in alcun modo accessibile dal web. In tal caso lo dobbiamo individuare con il suo percorso assoluto.
Require: come già detto prevede le opzioni valid-user, user e group. Nel nostro caso con valid-user richiediamo che l'utente sia definito nel file delle credenziali. Rimando al precedente articolo per le altre opzioni previste dalla direttiva.
È immediato verificare che le modifiche rispetto alla configurazione utilizzata con mod_auth_basic sono minime. A questo punto non ci resta che definire gli utenti a cui vogliamo concedere l'accesso.
La gestione degli utenti
Per amministrare il file destinato a memorizzare le credenziali dei nostri utenti possiamo ricorrere all'utility da riga di comando htdigest. Essa svolge il medesimo compito di htpasswd nel caso della basic authentication. Iniziamo generando il file delle password:
$ htdigest -c /percorso_del_file/password Amministratori ermanno Adding user ermanno in realm Amministratori New password: Re-type new password:
L'opzione -c permette la creazione del file, che chiameremo banalmente password, nel caso fosse già esistente viene sovrascritto. Il primo argomento passato al comando è il percorso e nome del file, il secondo il realm che abbiamo definito con AuthName e l'ultimo lo username del primo utente che vogliamo inserire. In risposta al comando dovremo digitare una password e ripeterla per conferma.
Per aggiungere i successivi utenti omettiamo l'opzione -c:
$ htdigest /percorso_del_file/password Amministratori francesco
Il contenuto del file password sarà simile a questo:
ermanno:Amministratori:39b1e76d0c19a02170e6683918260bf0 francesco:Amministratori:6554b1f92820cff54fce672d307249b7
dove si individuano, separati dai due punti, il nome utente, il realm e la password cifrata.
Per quanto riguarda la suddivisione in gruppi il file risulta identico a quello utilizzato per l'autenticazione di base ovvero nome del gruppo seguito da due punti ed elenco degli utenti separati da spazi:
superadmin: ermanno admin teo
Anche le direttive da utilizzare sono analoghe:
AuthDigestGroupFile /percorso_del_file/nome_file_gruppi Require group superadmin
A questo punto risulta naturale chiedersi: perché utilizzare ancora l'autenticazione di base e non passare definitivamente all'autenticazione digest? La risposta è semplice il supporto dei browser. Mentre possiamo considerare universale la prima, la seconda richiede l'utilizzo dei navigatori più diffusi e moderni.
Dobbiamo limitarci alle situazioni in cui possiamo prevedere con quali browser (e quali versioni) si presenteranno i nostri visitatori. Tanto per dare un'idea del problema le versioni di Internet Explorer 5 e 6, pur supportando nominalmente l'autenticazione digest, presentano un inconveniente con le query string nelle richieste GET. Per questo in Apache 2.0.51 è stata introdotta la seguente direttiva correttiva:
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
Dalla versione 7 del navigatore di Microsoft questo trucco non è più necessario né crea problemi l'utilizzo della direttiva per garantire la retrocompatibilità. In conclusione per quanto questo sistema di autenticazione risulti promettente spesso saremo costretti ad accontentarci del più debole e collaudato sistema di base.
La seconda parte dell'articolo, dedicata ai file Dbm, sarà pubblicata il prossimo venerdì, 7 maggio.
Memorizzare le credenziali su file Dbm
Parte seconda: salvataggio delle credenziali su file dbm
Soffermiamoci ora su un elemento debole che caratterizza tutti gli esempi sin qui riportati sia di basic che digest authentication: l'utilizzo di file di testo per memorizzare le credenziali. Tale scelta, qualora il numero di utenti sia rilevante, penalizza la velocità di risposta del server web sino a comprometterne seriamente le prestazioni.
Per migliorare la rapidità d'accesso alle credenziali dell'utente dobbiamo optare per sistemi alternativi. Apache ci supporta con alcuni moduli come mod_authn_dbm, mod_authn_dbd o mod_authnz_ldap sviluppati all'interno del progetto. Il primo utilizza file DBM, il secondo consente di effettuare una ricerca in tabelle di database, il terzo si appoggia ad una directory ldap. Possiamo anche ricorrere a moduli scritti da terze parti come mod_auth_mysql che permette di interrogare un database MySQL.
Prenderemo in esame, come esemplificativo, mod_authn_dbm, mentre chi fosse interessato a mod_auth_mysql può consultare due precedenti articoli della sezione server: Aree riservate con Apache e MySQL e Autenticazione con Apache e MySQL: alcune configurazioni avanzate.
L'acronimo DBM sta per Data Base Management ed un file dbm è un file binario contenente coppie chiave/valore. I tempi di accesso sono normalmente inferiori a quelli di un database relazionale, per non parlare ovviamente dei file di testo. La scelta di passare a questo tipo di memorizzazione dovrebbe essere intrapresa quando gli utenti raggiungono il centinaio.
Dal punto di vista delle configurazioni dovremo semplicemente indicare il diverso tipo di provider e la posizione del file dbm:
AuthBasicProvider dbm AuthDBMUserFile /percorso_del_file_dbm/password
Se utilizziamo l'autenticazione digest sostituiamo nell'esempio precedente la prima direttiva con:
AuthDigestProvider dbm
Ecco un esempio completo dove si nota che le modifiche apportate sono veramente poche:
AuthName Amministratori AuthType Basic AuthBasicProvider dbm AuthDBMUserFile /percorso_del_file_dbm/password Require valid-user
Il programma Htdbm
Per la basic authentication Apache ci fornisce un programma, htdbm, che ci agevola nella gestione dei file dbm. Nelle versioni recenti ha sostituito il precedente dbmmanage, avvicinandosi maggiormente come sintassi ad htpasswd e htdigest.
$ htdbm -c /percorso_del_file_dbm/password ermanno Enter password : Re-type password : Database /percorso_del_file_dbm/password created.
Al solito l'opzione -c determina la creazione del file mentre va' omessa nell'aggiungere i successivi utenti. In quest'ultimo caso se l'utente esiste già il comando avrà l'effetto di modificarlo.
Per eliminare un utente dal database:
$ htdbm -x /percorso_del_file_dbm/password ermanno
Per elencare gli utenti presenti in database:
$ htdbm -l /percorso_del_file_dbm/password
Il programma htdbm supporta vari formati oltre a quello di default: SDBM, GDBM, NDBM, DB. In questo caso sarà necessario usare l'opzione -T <tipo di file> per specificarlo. In maniera analoga Apache dovrà essere istruito sul formato adottato mediante la direttiva AuthDBMType, ad esempio:
AuthDBMType DB
Ricordo che i file utilizzabili dipendono dalle opzioni di compilazione, verificate dunque che Apache sia in grado di gestire la vostra scelta.
Per la sintassi completa di htdbm digitate htdbm -h o man htdbm se desiderate anche ulteriori informazioni sul programma.
Siamo giunti a conclusione anche di questo secondo articolo dedicato ai sistemi di autenticazione e controllo degli accessi disponibili con il Web Server Apache. La trattazione, lungi dall'essere esaurita (e difficilmente esauribile), proseguirà con le prossime pubblicazioni.