Successfully reported this slideshow.

AAI Locale

395 views

Published on

Proposta per un modello comune in ambito locale

  • Be the first to comment

  • Be the first to like this

AAI Locale

  1. 1. AAIProposta per un modello comune in ambito locale E. M. V. Fasanelli F. M. Taurino G. Tortone CCR Roma – 12/12/2006
  2. 2. Agenda L’AAI dal punto di vista dei servizi di base Un sguardo d’insieme sulla situazione attuale Il modello proposto Conclusioni
  3. 3. I servizi di base Posta elettronica Stampa Accesso remoto e per ospiti Mailing List Applicazioni e siti Web Windows
  4. 4. Posta elettronica (SMTP) I mail exchanger hanno bisogno di Lista delle reti autorizzate al relay Elenco dei domini per cui possono gestire la posta Lista degli alias e dei maildrop degli utenti Tipicamente sono almeno due ed e’ necessario tenere sincronizzati i loro “database”
  5. 5. Posta elettronica (IMAP) I server di accesso alle caselle email hanno bisogno di Lista degli utenti Eventuali autorizzazioni di accesso a folder condivisi Possono essere collegati a server di autenticazioni centralizzati oppure avere un elenco di utenti e password locale (es. Cyrus)
  6. 6. Stampa (CUPS) Possibilità di avere code private e/o di gruppo e di richiedere l’autenticazione degli utenti che inviano le stampe Browsing delle stampanti via IPP e/o Samba Possibilita’ di “pubblicare” le stampanti (es: configurazione, tipi di formati disponibili, location) su un “directory server”
  7. 7. Accesso remoto La gestione dell’accesso in modalità interattiva può essere complessa Nel caso più semplice (Server Linux con accesso via ssh) sono necessari Elenco username/password Tcp-wrapper per autorizzazione di ip/domini Opt: limits.conf, time.conf (limiti e orari) Tipicamente e’ necessario modificare altri file per gli accessi in grafica
  8. 8. Accesso per ospiti o VPN Questi sistemi possono operare utilizzando server centrali di autenticazione oppure avere elenchi di utenti locali alle macchine La gestione degli ospiti può essere complessa (creazione account, scadenze)
  9. 9. Mailing list Diversi indirizzi (a volte migliaia) per ogni lista Permessi di accesso e utilizzo Gestione archivi via web Tipicamente svincolati dai sistemi di autenticazione centrali (oppure non integrabili – es: Majordomo) La creazione di un utente sui server comporta l’aggiunta di una entry sul server di gestione delle liste
  10. 10. Applicazioni e siti web Autenticazione utenti con file in formato specifico per il server web - htpasswd Autorizzazione all’accesso a folder impostati con il meccanismo “htaccess” Non integrabile con sistemi standard Proliferazione di file htpasswd e htaccess su siti complessi
  11. 11. Windows Autenticazione e autorizzazioni vengono gestiti da Active Directory Non integrabili –direttamente– con sistemi Linux/Unix Tipicamente in ambienti multipiattaforma avremo almeno due “database” degli utenti
  12. 12. Identity management - 1 La gestione delle informazioni relative agli individui (e a macchine e servizi) Account sui sistemi Account per le applicazioni Indirizzi (email, telefono, indirizzo fisico) Iscrizione a “servizi”
  13. 13. Identity management - 2 Queste informazioni sono contenute in diversi “database”, in formati differenti e di solito con sistemi NON compatibili fra loro E’ difficile tenere sincronizzate le informazioni relative a una persona su tutti questi sistemi Es: trasferimento di una persona Quanti e quali “database” vanno modificati? Cosa succede se tralascio uno degli archivi?
  14. 14. La situazione odierna - 1
  15. 15. La situazione odierna - 2
  16. 16. E se le sedi sono due…
  17. 17. Soluzioni parziali - 1 NIS (Yellow Pages) Non gerarchico “database” semplice (tabelle di due colonne) Server di tipo Master/Slave Criptazione delle sole password Utilizzo non efficiente su WAN Intrinsecamente non sicuro SOLO per Linux/Unix Alcuni problemi risolti con NIS+ Non vengono sviluppati attivamente
  18. 18. Soluzioni parziali - 2 Kerberos Non gerarchico – multi realm Database criptato Server di tipo Master/Slave Criptazione anche del traffico Utilizzabile su WAN Indipendente dalla piattaforma SOLO per autenticazione e autorizzazione
  19. 19. Soluzioni parziali - 3 LDAP Gerarchico Database “liberamente” modificabili Server di tipo Multi-Master/Slave/Replica Criptazione anche del traffico Utilizzabile su WAN Indipendente dalla piattaforma Anche per autenticazione e autorizzazione
  20. 20. Il modello AAI proposto LDAP + backend Kerberos5 Intrinsecamente gerarchico Calza “a pennello” sulla struttura INFN… Sicuro (db user/pass – traffico) Standard aperti e multipiattaforma Compatibile con le AI sicure esistenti K5 è opzionale (ma raccomandato) PKI e certificati X.509 Il DS per i servizi comuni
  21. 21. AAI per l’INFN C=IT, O=INFN C=IT, O=INFN, L=NapoliC=IT, O=INFN, L=Lecce DS DS DS
  22. 22. Vantaggi Singole istanze dei “dati” Consolidamento delle informazioni presenti in diversi database di sistemi e applicazioni Gestione centralizzata (anche su architettura distribuita), uniforme e sicura Sincronizzazione efficiente Riduzione dei costi E dei tempi… Possibilità di modificare lo schema per applicazioni particolari
  23. 23. NOTE SUI DS
  24. 24. Cosa e’ un Directory ServiceUn Directory Service è un servizio informativoche consente un accesso uniforme ai dati,organizzati secondo un preciso schema.I DS costituiscono fonte di informazione nonsolo per le persone ma anche per leapplicazioni.Esistono DS specializzati come il DNS e diutilizzo piu’ generale come LDAP.
  25. 25. DS e DatabaseUn DS e’ un DB ottimizzato per la letturae per la ricerca delle informazioni su daticon aggiornamenti rari, con un protocolloche permette l’accesso via rete.Sono inoltre previsti meccanismi direplicazione e distribuzione dei dati tra variDircetory Server
  26. 26. X.500 DS standard del CCITT Revisioni importanti nel 1993 e nel 1997 (altre negli anni successivi) Directory Access Protocol per l’accesso via rete (opera su tutta la pila OSI) Introduce le linee guida per i successivi DS
  27. 27. LDAPLightweight Directory Access ProtocolNato per sopperire alla “pesantezza” di X.500Opera su TCP/IPVasta diffusioneModello informativo basato sulle entita’Entita’ composte da attributi che hanno uno opiù valoriGli attributi hanno una sintassi che determina iltipo (ASCII, binario) e il loro comportamento
  28. 28. Entità e ACL Entita’ organizzate in struttura gerarchica secondo il modello di X.500 Entita’ univocamente individuate da un Distinguished Name (DN) e, fissata una base, da un Relative Distinguished Name (RDN) LDAP fornisce metodi di accesso alle informazioni (ACLs), di autenticazione, di replicazione e di distribuzione dei dati
  29. 29. DIB e DIT Le informazioni in un DS sono archiviate in un Directory Information Base (entita’ con relativi attributi) Le informazioni nel DIB sono organizzate in una stuttura ad albero : Directory Information Tree
  30. 30. IndirizzamentoLa foglia di questo albero e’ cosi’indirizzata:DN : “CN=Bslug, OU=UCSC, OU=SantaCruz, O=CA, C=US”RDN : “CN=Bslug”
  31. 31. Accesso via rete Il protocollo di accesso è basato su TCP/IP (X.500 è basato su OSI) Definisce le operazioni di: ricerca, modifica, inserimento, autenticazione ecc.. Operazione principale : ricerca Es Quali sono le OU in California? Quali OU hanno un fax? Esiste un indirizzo di posta per l’utente “Rossi” nelle O con sede in CAN ?
  32. 32. Utilizzi reali di LDAP Sendmail + LDAP per la gestione dello userdb e delle mailing lists Client di posta per laddressbook Apache + Modulo di autenticazione LDAP Windows 2000 Active Directory (Backend LDAP per l’ autenticazione degli utenti) Sistema di autenticazione al momento su alcune piattaforme Unix (PAM per Solaris e Linux)
  33. 33. Struttura delle informazioni dn:cn=Francesco Maria Taurino, ou=NA, o=INFN, c=ITPrimary Key cn: Francesco Maria Taurino sn: Taurino objectclass: personMailing Lists interests: computing interests: php activity: calcolo mailacceptinggeneralid:Francesco.Taurino mailacceptinggeneralid:Taurino Mailing Info maildrop:taurino@imap-qz.na.infn.it mailname:Francesco.Taurino@na.infn.it mail:Francesco.Taurino@na.infn.it Personal Info telephoneNumber:+39+081+676290 postalAddress:Via Cintia, Comp. Univ. M. S. Angelo username:taurino expires:NEVER Account Info fullUsername:taurino@matrix.na.infn.it uid:501 gid:501
  34. 34. SicurezzaLe varie implementazioni dei server prevedonodiversi meccanismi di accesso ai dati e diautenticazione.L’autenticazione in genere è basata su ACLs epermette diversi livelli e modalità di accesso aidati del DIT.Per la lettura e la modifica alle informazioni si puòusare Kerberos o SSL.
  35. 35. Vantaggi dei DS Singola istanza dei dati relativi agli utenti Gestione centralizzata (anche su architettura distribuita) e uniforme Applicazioni commerciali e pubbliche in continuo aumento Possibilità di modificare lo schema per applicazioni particolari
  36. 36. …e svantaggi Relativa lentezza degli update e dell’accesso tramite wrappers (Finger, whois) I DS in genere non sono transaction based, l’accesso concorrente in scrittura, può essere un problema (ma lo e’ sempre meno…) Gestione inizialmente complicata: necessita dell’acquisizione di conoscenze aggiuntive (ma e’ sempre piu’ semplice…)

×