Funzionamento di SEAM

In questa sezione verrà fornita una descrizione generale del sistema di autenticazione SEAM. Per una descrizione più dettagliata, vedere "Funzionamento del sistema di autenticazione".

Dal punto di vista dell'utente, dopo l'avvio della sessione SEAM è quasi sempre invisibile. I comandi come rsh o ftp operano essenzialmente in modo normale. L'inizializzazione di una sessione SEAM comporta generalmente un semplice login con l'inserimento di una password Kerberos.

Il sistema SEAM è imperniato sul concetto di ticket. Un ticket è un insieme di informazioni elettroniche che fungono da identificativo per un utente o un servizio, ad esempio per il servizio NFS. Allo stesso modo in cui una patente identifica il guidatore e indica il tipo di autorizzazione che possiede, un ticket identifica l'utente e i suoi privilegi di accesso alla rete. Quando si esegue una transazione basata su SEAM -- ad esempio, un rlogin su un altro sistema -- si invia in modo trasparente una richiesta di un ticket a un Key Distribution Center, o KDC, il quale accede a un database per autenticare l'identità dell'utente. Il KDC restituisce un ticket che assegna all'utente l'autorizzazione di accedere all'altro sistema. "In modo trasparente" significa che non è necessario richiedere il ticket esplicitamente; la richiesta viene inviata automaticamente come parte del comando rlogin. Poiché solo il client autenticato può ottenere un ticket per un servizio specifico, un altro client non potrà usare il comando rlogin con un'identità fittizia.

Ai ticket sono associati alcuni attributi. Ad esempio, un ticket può essere inoltrabile (cioè può essere usato su un altro sistema senza un nuovo processo di autenticazione), oppure postdatato (non valido fino a una data specificata). Il modo in cui i ticket vengono usati -- ad esempio, quali utenti sono autorizzati a ottenere quali tipi di ticket -- viene determinato dai criteri stabiliti durante l'installazione o l'amministrazione di SEAM.

In questo documento verranno usati spesso i termini credenziali e ticket. Nel mondo di Kerberos, questi termini sono spesso utilizzati in modo intercambiabile. Tecnicamente, tuttavia, una credenziale è un ticket più la chiave della sessione. Questa differenza viene spiegata in modo più dettagliato in "Accesso a un servizio con SEAM".

Le sezioni seguenti illustrano brevemente il processo di autenticazione di SEAM.

Autenticazione iniziale: il TGT (Ticket-Granting Ticket)

L'autenticazione Kerberos si svolge in due fasi: un'autenticazione iniziale che permette tutte le autenticazioni successive, e le autenticazioni successive.

La Figura 1-1, illustra lo svolgimento dell'autenticazione iniziale:

Figura 1-1 Autenticazione iniziale per le sessioni SEAM

1. Un client (un utente o un servizio, ad esempio NFS) inizia una sessione SEAM richiedendo un ticket-granting ticket (TGT) al Key Distribution Center. Questa operazione si svolge in genere automaticamente al momento del login.

   Il TGT è necessario per ottenere altri ticket per servizi specifici. Come analogia, si può pensare al TGT come a un passaporto. Come un passaporto, infatti, il TGT identifica l'utente e gli permette di ottenere vari "visti" -- in questo caso, i "visti" (ticket) non servono per accedere a paesi esteri ma per utilizzare servizi di rete o sistemi remoti. Come i passaporti e i visti, il TGT e gli altri ticket hanno una durata limitata. La differenza consiste nel fatto che i comandi basati su Kerberos rilevano la presenza di un passaporto e ottengono i visti automaticamente per l'utente -- che quindi non deve eseguire le transazioni di richiesta direttamente.

2. Il KDC crea un TGT e lo restituisce, in forma cifrata, al client. Il client decifra il TGT utilizzando la sua password.

3. In possesso di un TGT valido, il client può ora richiedere altri ticket per tutti i tipi di operazioni di rete, come rlogin o telnet, per tutta la durata del TGT. Tale durata è normalmente di alcune ore. Ogni volta che il client esegue un'operazione di rete di un nuovo tipo, di fatto esso richiede un ticket per quell'operazione al KDC.

Autenticazioni successive

Dopo che il client ha ricevuto l'autenticazione iniziale, tutte le autenticazioni successive seguono il modello illustrato nella Figura 1-2:

Figura 1-2 Acquisizione dell'accesso a un servizio

1. Il client richiede un ticket per un determinato servizio (ad esempio, per eseguire un rlogin su un altro sistema) al KDC, inviando al KDC il suo TGT come prova della sua identità.

2. Il KDC invia al client il ticket per il servizio specifico.

   Ad esempio, si supponga che l'utente mario esegua il comando rlogin sul server torino. Essendo già stato autenticato (cioè possedendo già un TGT), egli ottiene in modo automatico e trasparente un ticket come parte del comando rlogin. Questo gli permetterà di eseguire il comando rlogin su torino tutte le volte necessarie per tutta la durata del ticket. Se mario dovesse eseguire rlogin sul sistema milano, egli otterrà un altro ticket, come al punto 1.

3. Il client invia il ticket al server.

4. Il server concede l'accesso al client.

Esaminando questa procedura, si può notare che il server non sembra mai comunicare con il KDC. In realtà questa comunicazione avviene; il server infatti si registra presso il KDC esattamente come il primo client. Questo passaggio è tuttavia stato omesso per ragioni di semplicità.

I comandi basati su SEAM

Quali sono i comandi basati su SEAM (o su Kerberos) che un utente come mario può utilizzare? Sono i seguenti:

• ftp

• rcp

• rlogin

• rsh

• telnet

Queste applicazioni sono uguali alle applicazioni Solaris con lo stesso nome, tranne per il fatto che utilizzano i nomi principali Kerberos per autenticare le transazioni, usando perciò una procedura di sicurezza basata su Kerberos. (Per informazioni sui nomi principali, vedere "Nomi principali".)

Questi comandi sono descritti in modo più dettagliato in "Comandi di SEAM".

Nomi principali

In SEAM, un client viene identificato per il suo nome principale. Un nome principale è un'identità unica a cui il KDC può assegnare i ticket. Un nome principale può corrispondere a un utente, ad esempio mario, o a un servizio, ad esempio nfs o telnet.

Per convenzione, un nome principale è diviso in tre parti: il nome primario, l'istanza e il settore. Ad esempio, un tipico nome principale di SEAM può essere mario/admin@EURO.SPA.IT, dove:

• mario è il nome primario, che può essere il nome di un utente, come in questo caso, o il nome di un servizio, come nfs. Come nome primario si può anche utilizzare la parola host, per indicare che si tratta del nome principale di un servizio configurato per fornire vari servizi di rete (ftp, rcp, rlogin, ecc.).

• admin è l'istanza. L'istanza è opzionale nel caso dei nomi principali degli utenti, mentre è obbligatoria per i nomi principali dei servizi. Ad esempio: se l'utente mario opera a volte come amministratore di sistema, egli può usare il nome principale mario/admin per distinguersi dalla sua identità normale. Allo stesso modo, se mario ha un account su due host differenti, egli può usare due nomi principali con istanze differenti (ad esempio, mario/milano.spa.it e mario/torino.spa.it). Si noti che SEAM considererà mario e mario/admin come due nomi principali completamente differenti.

  Nel caso del nome principale di un servizio, l'istanza corrisponde al nome host pienamente qualificato. Un esempio di tale istanza può essere sistemone.euro.spa.it, e quindi la combinazione nome primario/istanza può essere, ad esempio, ftp/sistemone.euro.spa.it oppure host/sistemone.euro.spa.it.

• EURO.SPA.IT è il settore SEAM. I settori sono descritti nella sezione "Settori".

I seguenti sono possibili nomi principali validi:

• mario

• mario/admin

• mario/admin@EURO.SPA.IT

• ftp/host.euro.spa.it@EURO.SPA.IT

• host/euro.spa.it@EURO.SPA.IT

Settori

Un settore è una rete logica, come un dominio, che definisce un gruppo di sistemi residenti sotto lo stesso KDC master (vedere sotto). La Figura 1-3, mostra in che modo i settori possono essere correlati l'uno all'altro. Alcuni settori sono gerarchici (uno è un sovrainsieme dell'altro). Altri sono "non gerarchici", e in questi casi occorre definire la mappatura tra i due settori. Una caratteristica di SEAM è quella di permettere l'autenticazione tra settori diversi; a tale scopo, l'unica condizione è che ogni settore abbia una voce corrispondente al nome principale dell'altro settore nel proprio KDC.

Figura 1-3 Settori

Settori e server

Ogni settore deve includere un server che mantenga la copia master del database dei nomi principali. Questo sarà il server master del KDC. Inoltre, ogni settore deve contenere almeno un server slave del KDC, contenente una copia del database dei nomi principali. Sia il server master che il server slave del KDC possono creare i ticket da usare per l'autenticazione.

Il settore può anche includere due altri tipi di server SEAM: i server di applicazioni di rete SEAM, che forniscono l'accesso alle applicazioni basate su Kerberos (come ftp, telnet e rsh); e i server NFS, che forniscono i servizi NFS usando l'autenticazione Kerberos.

La Figura 1-4, mostra il possibile contenuto di un ipotetico settore.

Figura 1-4 Esempio di settore