1 / 18

Dael Maselli

Oracle Collaboration Suite - INFN -. Dael Maselli. v2 - 2007.03.16. Esigenze nell’implementazione della suite di collaborazione di Oracle nell’infrastruttura IT dell’Istituto Nazionale di Fisica Nucleare. Esigenze INFN.

valentine-mcfarland
Télécharger la présentation

Dael Maselli

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Oracle Collaboration Suite - INFN - Dael Maselli v2 - 2007.03.16 Esigenze nell’implementazione della suite di collaborazione di Oracle nell’infrastruttura IT dell’Istituto Nazionale di Fisica Nucleare

  2. Esigenze INFN • L’Istituto Nazionale di Fisica Nucleare (INFN) sta considerando di adottare Oracle Collaboration Suite (OCS) come strumento di collaborazione ufficiale per la propria comunita’ scientifica • Esistono tuttavia alcune esigenze imprescindibili che verranno descritte di seguito insieme all’infrastruttura IT dell’INFN • Alcuni dei seguenti requisiti potrebbero essere derogabili, di conseguenza e’ necessario considerare in ogni caso tutti i punti di questo documento

  3. INFN Internet Directory • L’infrastruttura di directory INFN e’ basata su LDAP nelle sue implementazioni standard come OpenLDAP o Fedora / RedHat / Netscape Directory Server con canali sicuri SSL/TLS. • Esiste un server per ogni sede con suffix “L=<NomeSede>, O=INFN, C=IT” • Esiste un server centrale che gestisce il suffix “O=INFN, C=IT” che e’ in grado di rispondere (tramite chaining) alle richieste per i sub-suffix delle sedi. • OCS si servira’ di quest’ultimo server centrale per l’accesso alle informazioni degli utenti.

  4. INFN Authentication • L’infrastruttura di autenticazione dell’INFN e’ basata su MIT Kerberos5 • Esiste un server Kerberos5 per ogni sede che gestisca un realm <NomeSede>.INFN.IT • Esiste inoltre un server centrale che gestisce un realm INFN.IT • Tra i realm sono definite relazioni gerarchiche di trust bidirezionali e transitive

  5. Autenticazione – Metodo 1(Ticket Kerberos5) • OCS dovra’ validare il ticket presentato dal client attraverso le chiamate Kerberos5 del SO che sara’ configurato opportunamente. • OCS dovra’ riconoscere il principal ed il realm dell’utente attraverso gli opportuni attributi (o singolo attributo) nel Directory centrale INFN

  6. Autenticazione m.1 (Ticket Kerberos5) LDAPs user information Kerberos5 authentication OCS OCS Keytab Kerberos5 O=INFN, C=IT Client presentazione di ticket Kerberos5 Lecce Roma1 Frascati Napoli L=Lecce, O=INFN, C=IT L=Roma1, O=INFN, C=IT L=LNF, O=INFN, C=IT L=Napoli, O=INFN, C=IT krb5: LE.INFN.IT krb5: ROMA1.INFN.IT krb5: NA.INFN.IT krb5: LNF.INFN.IT

  7. Autenticazione – Metodo 1a(Certificato X.509) • OCS dovra’ validare il certificato X.509 presentato dal client attraverso la chiave pubblica della Certification Authority INFN • OCS dovra’ riconoscere l’utente nel Directory centrale INFN tramite l’attributo opportuno contentente il Subject X.509

  8. Autenticazione m.1a (Certificato X509) LDAPs user information OCS OCS Public Key INFN CA O=INFN, C=IT Client presentazione di Certificato X.509 Lecce Roma1 Frascati Napoli L=Lecce, O=INFN, C=IT L=Roma1, O=INFN, C=IT L=LNF, O=INFN, C=IT L=Napoli, O=INFN, C=IT krb5: LE.INFN.IT krb5: ROMA1.INFN.IT krb5: NA.INFN.IT krb5: LNF.INFN.IT

  9. Autenticazione – Metodo 2(Username/Password Kerberos5) • OCS dovra’ riconoscere il principal ed il realm dell’utente attraverso gli opportuni attributi (o singolo attributo) nel Directory centrale INFN • OCS dovra’ poi effettuare l’autenticazione tramite username e password attraverso le chiamate Kerberos5 del SO che sara’ configurato opportunamente.

  10. Autenticazione m.2 (user/pass Kerberos5) LDAPs user information Kerberos5 authentication OCS OCS O=INFN, C=IT Client presentazione di username/password Lecce Roma1 Frascati Napoli L=Lecce, O=INFN, C=IT L=Roma1, O=INFN, C=IT L=LNF, O=INFN, C=IT L=Napoli, O=INFN, C=IT krb5: LE.INFN.IT krb5: ROMA1.INFN.IT krb5: NA.INFN.IT krb5: LNF.INFN.IT

  11. Autenticazione – Metodo 3(LDAP) • L’infrastruttura di autenticazione INFN permette la convalida di username e password tramite LDAP • OCS dovra’ poter effettuare l’autenticazione attraverso il server LDAP centrale • Quest’ultimo la deleghera’ poi al server della sede opportuna che potra’ eventualmene servirsi di un back-end di autenticazione

  12. Autenticazione m.3 (LDAP) LDAPs user information LDAPs authentication OCS OCS O=INFN, C=IT Client presentazione di username/password Lecce Roma1 Frascati Napoli L=Lecce, O=INFN, C=IT L=Roma1, O=INFN, C=IT L=LNF, O=INFN, C=IT L=Napoli, O=INFN, C=IT + authentication passthru auth passthru auth passthru auth krb5: LE.INFN.IT NIS krb5: LNF.INFN.IT

  13. Autenticazione • I metodi di autenticazione precedentemente esposti dovranno essere contemporaneamente disponibili: • Qualora l’utente si presenti con un ticket Kerberos5 l’autenticazione dovra’ essere gestita attraverso il metodo 1; • Qualora si presenti con un Certificato X.509 si dovra’ invece procedere con il metodo 1a; • Altrimenti dalle informazioni sull’utente nel directory si potra’ evincere se e’ disponibile un server Kerberos 5 nella sede di appartenenza e attuare il metodo 2; • Diversamente dovra’ procedere con il metodo 3

  14. Gestione e-mail (1) • Ogni sede INFN gestisce un proprio dominio di posta del tipo @<NomeSede>.infn.it • La gestione del mailing dovra’ rimanere di competenza delle singole sedi secondo le proprie scelte tecnologiche (non OCS) • Dovra’ esserci comunque la possibilita’ di gestione di uno o piu’ domini di posta da parte di OCS

  15. Gestione e-mail (2) • OCS gestira’ la posta elettronica esclusivamente per l’invio dei messaggi, tramite un mail server esterno. • Nel caso di messaggi destinati ad utenti di OCS, usera’ gli indirizzi registrati nel directory LDAP

  16. Gestione e-mail (3) • Ferma restando la gestione del mailing da parte delle singole sedi ci e’ noto che in questa configurazione OCS possa perdere alcune funzionalita’ • In tal caso OCS potra’ gestire il traffico e-mail delle sedi ma dovra’ in ogni caso inoltrare i messaggi agli indirizzi registrati nel directory LDAP

  17. Future release ? • Alcune delle esigenze dell’INFN, nonche’ vari bug di OCS( ad es.: incompatibilita’ con vari browser, Public Instant Portal [vs. nota 312604.1 - vs. bug 4312180], etc. ) pare verrebbero risolti nella prossima versione di OCS: • Quali sono i tempi di attesa per una nuova release? • E’ possibile conoscere quali saranno le funzionalita’ che verranno corrette, aggiunte o potenziate?

  18. F I N E Per ulteriori informazioni o chiarimenti contattare: Dael Maselli Responsabile INFN WebTools ufficio: 06.9403.2214 cellulare: 06.9403.8263 e-mail: Dael.Maselli@LNF.INFN.IT

More Related