4.2. Struttura del database

4.2.1. Contenuto del database

Nella struttura che abbiamo adottato, per isolare l'albero con i nostri dati da quelli di eventuali altre virtual organizations come la nostra, i dati relativi al nostro sistema saranno interamente collocati al di sotto dell'oggetto dc=infra, dc=org, o=Anarchy (questa è una nomenclatura standard).

Il database comprende varie tipologie differenti di utenze e di altri oggetti, memorizzati in rami differenti dell'albero LDAP collocati al di sotto di dc=infra, dc=org, o=Anarchy:

• ou=Admins: questo albero contiene gli amministratori delle macchine, cioe' gli utenti che hanno un accesso in ssh. NOTA: i compiti amministrativi che non comportano l'uso della shell (per esempio il pannello di amministrazione via web) sono autenticati su degli altri oggetti identici a questi ma con password diversa, collocati sotto l'albero ou=People. Questo vale a dire che l'accesso tramite SSH è separato da tutti gli altri per quanto riguarda l'autenticazione.

• ou=People: sono tutti gli utenti email, ftp. etc .. questi costituiscono la parte "virtuale" del db LDAP.

• ou=Operators: contiene gli utenti "di sistema" per far manipolare parti del database ldap al software senza dover necessariamente avere tutti i privilegi del manager LDAP. E' l'utente prevalentemente utilizzato dai demoni che accedono al database.

• ou=Domains: contiene un oggetto per ciascun dominio virtuale gestito dalla struttura. Postfix, ad esempio, legge questo sottoalbero per determinare se un dominio è locale oppure no (nella costruzione delle tabelle di transport).

4.2.2. Utenze virtuali

Intendiamo qui di seguito "utente" nel significato di "contatto", concetto che introduciamo per poter raggruppare i servizi che fanno capo ad un'unica entità, sia persona che organizzazione o altro, scelta in modo da agevolare l'amministrazione dei servizi.

Ciascun utente è rappresentato nel database da un oggetto identificato dalla chiave uid. Possiamo scegliere per questi oggetti la nomenclatura che preferiamo: nel nostro caso facciamo l'esempio di nominare gli utenti con il loro indirizzo email principale (es: uid=phasa@dominio.org) Volendo raggruppare i servizi relativi ad esempio ad un'organizzazione intera, anziché un singolo utente, potremmo scegliere di creare un oggetto con un nome di dominio uid=organizzazione.it o qualunque altra cosa ci sembri significativa (una volta scelto uno schema).

A ciascuno di questi oggetti possono essere associati diversi servizi, che saranno oggetti collocati al di sotto dell'oggetto "utente". Il tipo di questi oggetti corrisponderà al tipo di servizio. Per esempio queste sono alcune strutture possibili:

* un singolo utente con casella di posta

  ou=People
  \-- uid=utente@dominio.org                    shadowAccount
      \-- mail=utente@dominio.org               virtualMailUser

* utente con casella di posta e sito web (e dunque account ftp)

  ou=People
  \-- uid=utente@dominio.org                    shadowAccount              
      +-- mail=utente@dominio.org               virtualMailUser
      +-- alias=sitoutente                      subSite
      \-- ftpname=utente                        ftpAccount

* organizzazione con piu' account, sito web e dominio proprio

  ou=People
  \-- uid=organiz.org                           shadowAccount
      +-- mail=utente1@organiz.org              virtualMailUser
      +-- mail=utente2@organiz.org              virtualMailUser
      +-- cn=www.organiz.org                    virtualHost
      \-- ftpname=organiz                       ftpAccount

4.2.3. Autenticazione

Nella struttura sopra descritta ciascun servizio che necessita autenticazione la effettua direttamente sull'oggetto "figlio" del tipo relativo. Dunque le credenziali di autenticazione presenti nell'oggetto shadowAccount che identifica l'utente, benché presenti perché richieste dallo schema, non sono mai utilizzate direttamente.

Tramite opportuni filtri di query dunque si fa in modo che per esempio il demone IMAP effettui l'autenticazione degli utenti su un oggetto di tipo virtualMailUser, con la sua propria password. Questo meccanismo permette, volendolo, di avere password differenziate per i vari servizi. La possibilità di fare ciò rientra nelle policy che vanno imposte attraverso gli strumenti di amministrazione, in quanto LDAP, al contrario di un database relazionale, non ha dei meccanismi propri per specificare, appunto, particolari relazioni tra oggetti diversi (tranne quella gerarchica): per questo è impossibile (o estremamente contorto) specificare in LDAP concetti come il fatto che un oggetto debba avere la stessa password di quello che lo contiene; questo fatto porta naturalmente ad una certa ridondanza dei dati presenti nello schema (non elevata, però).

Vedremo ora a grandi linee come sono configurati i vari servizi (relativamente all'autenticazione sul database LDAP). Per ogni servizio sono specificati quali sono i files di configurazione relativi all'autenticazione, e qual è il tipo di query effettuata - costituita da una base che limita la ricerca e una query (detta anche filtro) che cerca un oggetto specifico:

Nota: tutte le query sopra descritte confrontano la password fornita con quella memorizzata nell'attributo userPassword. Anche su questo è il caso di precisare una cosa che può risultare utile: le password possono venir memorizzate nel database LDAP codificate in modi differenti, contraddistinti da un prefisso posto prima della password tra parentesi graffe, ad esempio

	  {crypt}dlkj8h23dU9j1