LDAP e la disperazione

Ho maturato, grazie anche ai commenti di Enrico, lo stato dell’arte rispetto a LDAP su sistemi liberi.

Problema: in azienda abbiamo svariati repository SVN/GIT con rispettivi project tracker, per i singoli progetti (interni, dei clienti, di spippolamento generico, etc). Come gestire nel modo più comodo autenticazione e autorizzazione ai rispettivi progetti da parte di utenti di varia provenienza (utenti interni, clienti, collaborati,etc) ?

Per “modo più comodo” si intende:

  • Evitare la duplicazione delle informazioni di autenticazione
  • Gestire gli accessi ai singoli progetti
  • Delegare la gestione degli accessi ai singoli progetti
  • Permettere agli utenti di gestire i propri account, inclusa la partecipazione ai singoli progetti

Trac può funzionare tranquillamente con autenticazione HTTP, SVN/GIT pure.. perfetto, mi dico, usiamo i vari moduli di autenticazione forniti da Apache, web server che attualmente fa da frontend.

I dati? Beh, la risposta viene spontanea: LDAP!

LDAP, LDAP.. si, ma veramente è la soluzione?

Esistono moduli Apache per autenticare utenti e gruppi su LDAP, quindi una soluzione possibile è:

  1. OU separate per le varie tipologie di utenti (interni, collaboratori, clienti)
  2. OU per i “progetti”, contenente oggetti di tipo gruppo
  3. Utenti associati a questi gruppi
  4. Scope di ricerca utenti sub a partire dalla root

In lingua Apache, la cosa si traduce in qualcosa del tipo:

<Location /progetto-x>
                AuthName "Tracker Progetto X"
                AuthType Basic
                AuthBasicProvider ldap
                AuthLDAPURL ldap://127.0.0.1/dc=myroot,dc=com
                AuthLDAPGroupAttributeIsDN off
                AuthLDAPGroupAttribute memberUid
                require ldap-group cn=progetto-x,ou=Projects,dc=myroot,dc=com
</Location>

(omessi i dettagli su trac e la configurazione base di authz-ldap)

In questo modo, l’autenticazione utente permette di cercare nelle varie OU dove questi si trovano, es. ou=collaborati,dc=myroot,dc=com, e i gruppi invece nella OU dei progetti.

Dal punto di vista della gestione, quando viene creato un pogetto, si crea il gruppo, si inseriscono gli utenti nel gruppo (crearli prima, se necessario), creare trac e svn (anche tramite hook, ma questa é un’altra storia).

Fino a qui, la cosa funziona.

Dove sono i problemi?

  1. Se il server LDAP principale non e’ esposto sulla rete, o si trova su una macchina diversa, dalla quale riceviamo una replica in sola lettura, non abbiamo un modo facile e comodo (anche dal punto di vista di una UI) per permettere gli utenti di gestire i propri account. Possiamo cambiare la password, ma gestire l’appartenenza ad un progetto? Lasciare la scrittura sul gruppo tramite una ACL significa che gli utenti possono aggiungere anche altri al gruppo.
  2. Delegare la gestione del gruppo a qualcuno, significa, se si utilizza l’implementazione LDAP server slapd, di creare una o piu’ acl per ogni gruppo. Se l’albero e’ replicato da un server centrale, auguri…

Se avete altri punti a sfavore, commentate, che li aggiungo…

Soluzioni?

Ho pensato un pò a possibili soluzioni a questo problema. Esiste un modo per cui:

  1. Ho un database di autenticazione verso il quale posso autenticare tramite un web server e
  2. Gli utenti possono gestire i propri dati (password, autenticazione, etc) e
  3. Posso delegare la gestione di uno o più gruppi/progetti a una o più persone e
  4. Avere possibilità di stabilire criteri di accesso ai progetti per ogni singolo progetto?

Una soluzione possibile è implementare un applicativo web o simili per la gestione dei dati su database e le operazioni di cui sopra, e utilizzando gli appositi moduli di autenticazione, configurare opportunamente il web server.

Ma esiste qualcosa che possa evitare questo sforzo, visto che c’è anche altro da fare?

Una soluzione che ho individuato, e realizzato con pochissimo sforzo, e che, apparentemente risolve gran parte di questi problemi, è utilizzare Mailman.

Se riesco ad autenticare HTTP contro il database di iscrizioni di una specifica lista Mailman, ottengo:

  1. Delega di gestione: mailman permette di associare ad una lista uno o più amministratori, che possono aggiungere(iscrivere)/togliere(deiscrivere) utenti, e stabilire anche i criteri di accesso (conferma, conferma e autorizzazione, etc)
  2. Gli utenti possono gestirsi in proprio i dati personali: cambio password, appartenenza o meno ad un progetto, tutto autonomamente
  3. Ho già una lista con tutti i partecipanti al progetto dove inviare ticket e commits :)
  4. Da quando mailman ha l’opzione “cambia la password e mettila uguale a tutte le liste a cui sono iscritto” risolve anche il problema di avere N password, una per progetto.
  5. Avere come username l’indirizzo email dell’utente è comodo per Trac, soprattutto quando si aprono ticket: abbiamo l’indirizzo del mittente a cui inviare notifiche sui ticket che sono stati aperti

Se vedete altri vantaggi, fatemi sapere, che aggiorno…

Come si realizza?

Tramite mod_python è possibile scrivere un handler per gestire, in Apache, il processo di autenticazione. Un semplice script Python che riceve utente e password e restituisce lo stato di autenticazione (OK o HTTP_UNAUTHORIZED). Visto che Mailman è pure scritto in Python, la cosa diventa semplice.

Risultato in Apache:

<Location /progetto-x>
                AuthName "Tracker Progetto X"
                AuthType Basic
                PythonPath "sys.path+['/path/a/script/di/auth/']"
                PythonAuthenHandler mailmanauth
                PythonOption MailmanList lista-progetto-x
                AuthUserFile /dev/null
                AuthBasicAuthoritative Off
                require valid-user
</Location>

Voilà. Gli iscritto alla mailing list lista-progetto-x possono accedere. Da ripetere per ogni progetto e repository di progetto SVN.

Troppo faticoso? Usare mod_macro può aiutare:

<Macro MailmanProject $name $list>
        <Location /svn/$name>
                AuthName "SVN for project $name"
                AuthType Basic
                PythonPath "sys.path+['/path/to/script/']"
                PythonAuthenHandler mailmanauth
                PythonOption MailmanList $list
                AuthUserFile /dev/null
                AuthBasicAuthoritative Off
                require valid-user
        </Location>
        <Location /$name>
                AuthName "Tracker for project $name"
                AuthType Basic
                PythonPath "sys.path+['/path/to/script/']"
                PythonAuthenHandler mailmanauth
                PythonOption MailmanList $list
                AuthUserFile /dev/null
                AuthBasicAuthoritative Off
                require valid-user
        </Location>
</Macro>

E per ogni progetto:

Use MailmanProject progetto-x lista-progetto-x

nel VirtualHost relativo.

Se poi aggiungere un bell’hook alla creazione della lista, per creare repository svn, environment per trac, il gioco è fatto:

# newlist progetto-y

e poi, è tutto in mano al gestore della mailing list.

Altre soluzioni sono benvenute :)

Pages:
  1. Bello! era un problema che mi ero gia’ trovato davanti, l’autenticazione di piu trac senza dover replicare i dati di autorizzazione..

    D.

Leave a Comment