AREA TELECOMUNICAZIONI
Servizi » Autenticazione » CMRA Server

Risorse correlate

CMRA Server

CMRA è l’acronimo di Centralized Multiple Re-Authentication.

A prima vista i termini Centralizzato e Multiple sembrano la premessa ad un ossimoro, eppure questo è esattamente il compito del CMRA Server: è un server Centralizzato che raccoglie le autenticazioni degli utenti, e quindi le convalida presso altre fonti, da cui derivano sia "Multiple" che la "Ri-Autenticazione".

È bene focalizzare fin da subito il concetto: CMRA non è un server di autenticazione, nel senso che non gestisce una propria base di utenti.
Si tratta piuttosto di un hub, un punto centrale in cui tutte le autenticazioni possono convergere per essere convalidate dopo il confronto delle credenziali presso la sorgente di autenticazione reale.

Sulla rete ci sono infinite fornti di autenticazione, ed ogni utente dispone di più e più identità digitali che possono essere autenticate presso il fornitore di servizi a cui l’identità fa capo:

Questa molteplicità di fonti di autenticazione mal si coniuga con il ruolo di un autenticatore centralizzato, il quale tipicamente si propone come punto unico di autenticazione ma contro una propria lista di utenti, o al più contro una singola fonte di autenticazione esterna.

Lo scopo del CMRA è propio quello di permettere una autenticazione (in senso stretto) avvalendosi di fonti multiple e predefinite che l’organizzazione considera dei fornitori accreditati ed affidabili di autenticazione.
Tutto ciò che esula dall’autenticazione in senso stretto –ovvero il solo riconoscimento dell’identità utente– non compete al CMRA. Permessi, diritti e quant’altro sono una peculiarità di ogni singola applicazione (tipicamente web application, ma non solo), ed infatti uno stesso utente con la medesima autenticazione potrà avere diritti diversissimi dipendentemente dall’applicazione che utilizzerà.

Architettura di ri-autenticazione

I Realm

In termine Realm viene spesso associato ai contesti di autenticazione, ed il CMRA non fa eccezione.

Un Realm è un regno a sé stante, nel nostro caso si tratta di una delle sorgenti di ri-autenticazione prima citate.
Nel CMRA potremo trovare ad esempio il Realm "gmail.com", così definito:

Questa definizione, che ora dettaglieremo meglio, nel progetto pilota di CMRA viene riprodotta nel file /etc/CMRA/realms.conf come:

[gmail.com]
method=smtp
ssl=1
server=smtp.gmail.com
userappendrealm=1

Successive implementazioni di CMRA potranno variare la sintassi o la natura stessa di questa configurazione, ad esempio migrandola in un database relazionale per facilitarne l’accesso concorrente in lettura/scrittura.
La lettura di questa sezione del file, comunque, ci suggerisce quanto occorre sapere per definire il Realm.

Le credenziali per l’autenticazione

La conoscenza del Realm è ovviamente un passo indispensabile per la riautenticazione delle credenziali, quindi possiamo dire che al fine di autenticare un utente abbiamo bisogno di una tripla di informazioni:

  1. Realm
  2. Nome utente
  3. Password

Non sfuggirà l’analogia con Windows, dove la tripla Dominio/Utente/Password da sempre determina l’autenticazione.
Eppure, come nel caso di Microsoft, ci troviamo a confrontarci con un dato di fatto: le autenticazioni sono tipicamente composte da una coppia di credenziali, Utente/Password, e non da una tripla.
Questo stesso problema si è presentato anche ad altri autenticatori multi-contesto, come i server di posta SMTP o POP3.

La decisione più comune è stata quella di comporre Utente e Contesto nella forma Utente@Contesto, come fa anche Microsoft con nomeutente@nomedominio.

Stante l’inutilità di nuovi formalismi isomorfi a soluzioni note, il CMRA accetta la tripla Realm/Utente/Password anche nella forma di coppia Utente@Realm/Password.

Flusso di autenticazione: case study di Gmail riautenticato dall’interfaccia LDAP

La prima interfaccia pubblica di cui il CMRA è stato dotato, oltre a quella lato codice, è quella di un Server LDAP.

Dal momento che il CMRA non dispone di propri utenti, e quindi non ha informazioni vere e proprie da fornire, il server LDAP di front-end accetta solo dei bind LDAP, ovvero autentica l’utente usando CMRA come back-end, e nulla più.

La sintassi con cui un utente gmail si autentica via LDAP è del tipo:

È possibile che alcuni server/servizi, segnatamente Microsoft, richiedano delle entry "dc" per lo schema LDAP.
Non ci sono problemi, il front-end LDAP del CMRA accetta anche forme utente come:

Qualunque sia la forma scelta, ad esempio aggiungendo ",dc=Multiautenticatore" o ",dc=CMRA,dc=mydomain,dc=com", il front-end LDAP di CMRA si limiterà a tener conto del valore utente che segue "cn=", e che precede qualunque eventuale ",".

Acquisita la coppia user@realm e password, il front-end LDAP passa le credenziali al back-end (il CMRA vero e proprio):

  1. Il CMRA riceve una richiesta di autenticazione di una coppia di valori, e tenta quindi di recuperare il Realm dal nome utente.
  2. Il nome utente viene separato per "@", ed otteniamo così la tripla user, realm e password
  3. Vengono acquisiti i parametri di definizione del realm "gmail.com", sopra descritti
  4. Al nome utente, come da parametro "userappendrealm", viene nuovamente appeso il "@gmail.com" necessario all’autenticazione.
  5. Secondo i parametri del realm, viene invocato il metodo del CMRA "SMTP su SSL"
  6. Il CMRA tenta di aprire una connessione con il server specificato, in caso di fallimento tornerà un Errore 503 (il front-end LDAP segnalerà il fallimento)
  7. Aperta la connessione viene tentata l’autenticazione SMTP, in caso di fallimento torna un Errore 500 (il front-end LDAP segnalerà il fallimento)
  8. In caso di autenticazione riuscita non viene tornato alcun errore al front-end, che darà risposta affermativa.

Sebbene il server LDAP, almeno in questa prima release pilota, presenti solo ed esclusivamente la risposta successo/fallimento, il CMRA dispone di molteplici codici di Errore (corredati di descrizione, che può anche riportare cause del server remoto).
Questi codici differenziano la causa dell’eventuale fallimento, e nella futura implementazione si propongono anche di riportare eventuali "warning" (ad esempio utenti autenticati, ma al di fuori delle fasce orarie previste).

Il Server

Il Server pilota del CMRA è una macchina virtuale Vmware, realizzata con Vmware Fusion e compatibile con tutte le recenti versioni di Vmware, compresa la versione free di Vmware server per Linux.
È stata realizzata utilizzando una netistall di base di Debian Linux stable ("Etch", kernel 2.6.18-6-686), a cui sono stati di seguito aggiunte le componenti di sistema necessarie (apache2, openssl, perl, curl, ecc.).
Sono stati altresì aggiunti i moduli Perl necessari, sia tramite "apt-get" che tramite il meccanismo del CPAN.

La macchina è stata infine chiusa ad interventi esterni tramite il firewall del kernel di Linux, configurato tramite iptables.

Il CMRA

Il CMRA è stato realizzato con Perl (versione 5.8.8, in dotazione alla ditribuzione stable).

Il pilota avvale direttamente dei seguenti moduli:

strict
warnings
Net::LDAP
Mail::POP3Client
Net::SMTP::SSL
Net::SMTP
Config::INI::Simple

Questi moduli utilizzano in cascata molte altre risorse, sia moduli Perl (ad esempio Authen::SASL, IO::Socket, IO::Socket::INET, IO::Socket::SSL, Net::SSLeay, Net::POP3, Net::Config) che componenti di sistema (ad esempio openssl).

Il CMRA stesso è un modulo Perl, CMRA.pm

I file di configurazione del modulo si trovano in /etc/CMRA.

Il Server LDAP

Il Server LDAP è stato realizzato avvalendosi dei moduli Perl Net::LDAP::Server per il protocollo LDAP, e Net::Server per la creazione in fork di un demone Perl permanentemente attivo e pronto ad accettare fino a 100 connessioni contemporanee.
Il numero "100" è attualmente scolpito nel pilota, ma niente vieta di innalzarlo sensibilmente una volta a regime.
Connessioni contemporanee eccedenti le 100 rimarranno appese, senza causare errori irreversibili.

Il server LDAP per il front-end è stato realizzato espressamente per il CMRA da Alessandro Ranellucci, autore del modulo Perl Net::LDAP::Server distribuito dal CPAN.

Nel Server CMRA il server LDAP di front-end è stato reso un demone; viene avviato al runlevel 2 e stoppato ai runlevel 0, 1 e 6.

Altre informazioni riguardanti il server LDAP di CMRA:

Credits

^ Top