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

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

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=, 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.

INFN Authentication L’infrastruttura di autenticazione dell’INFN e’ basata su MIT Kerberos5 Esiste un server Kerberos5 per ogni sede che gestisca un realm.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

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

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

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

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

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.

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

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

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

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

Gestione (1) Ogni sede INFN gestisce un proprio dominio di posta del 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

Gestione (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

Gestione (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

Future release ? Alcune delle esigenze dell’INFN, nonche’ vari bug di OCS ( ad es.: incompatibilita’ con vari browser, Public Instant Portal [vs. nota vs. bug ], 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?

Per ulteriori informazioni o chiarimenti contattare: Dael Maselli Responsabile INFN WebTools ufficio: cellulare: F I N E