Gruppi di lavoro Dreams Single Sign On LDAP

Gruppi di lavoro Dreams Single Sign On, LDAP Stefano Zanmarchi, CCA

Tema affrontato Studio di fattibilità di un’infrastruttura centralizzata di autenticazione n Riguarda: n servizi web (siti dipartimentali, sistemi informativi, e-learning, …) n accesso a postazioni (windows e linux): aule didattiche, laboratori, … n

Autenticazione e autorizzazione Ogni sistema informatico che dà accesso a risorse e servizi affronta due processi distinti: n autenticazione: verifica dell’identità dell’utente ciò che sa: password n che ha: smart card n che è: scansione retinica n n autorizzazione: concessione delle risorse in base all’identità di chi vi accede

Situazione attuale L'elenco aggiornato di studenti, dottorandi, dipendenti, … viene fornito dal CCA alle strutture n Ogni struttura alimenta il proprio database di utenti e password e gestisce in proprio il processo di autenticazione n

Situazione attuale: svantaggi n Non consente l’integrazione tra sistemi n Ogni amministratore deve: n n n registrare e amministrare gli (stessi) utenti rispettare le normative di legge Ogni utente deve ricordare molte password (invogliato a sceglierne “facili”)

Soluzione attuale: escamotage n Alcune strutture hanno “centralizzato” il processo di autenticazione sfruttando: n n mail server sistema informativo studenti (SIS) sistema informativo dipendenti (SIT) Approccio apparentemente elegante ma…

Soluzione attuale: escamotage n Problematiche tecniche e legali: n eventuali modifiche ai server del CCA comprometterebbero questi meccanismi n le applicazioni dipartimentali possono accedere a password di servizi diversi dai propri

Alternativa: LDAP centralizzato Apparentemente una buona soluzione (molti sistemi hanno moduli di tipo auth_ldap) n Ripropone maggiorati i problemi descritti: n quanti più sistemi accedono al server LDAP, tanto maggiore la possibilità di intrusione n avvenimento molto grave in condizione di password unica n

Proposta: LDAP + SSO server n Server centrale di Web Single Sign On (SSO) basato su database LDAP degli utenti universitari per l’autenticazione dei servizi web n LDAP affiancato (sincronizzato) ad un server Active Directory per l’autenticazione delle postazioni windows

Single Sign On Web: vantaggi n n Credenziali uniche Fornite solo una volta: SSO Le applicazioni non conoscono le pwd Le applicazioni gestiscono solo la autorizzazione

Single Sign On Web n n n n 1: richiesta risorsa web 2: redirect a SSO server 3 -4 -5: autenticazione 6: redirect a web server 7: richiesta risorsa 8 -9: verifica (PKI trust) 10: concessione risorsa web

Schema complessivo

Componenti n SSO server: n n “Virtual LDAP”, prende i dati da: n n RDBMS, LDAP, File, Web Services, … Active Directory server: n n autenticazione servizi web, richiede un backend LDAP autenticazione PC windows Software di provisioning: n sincronizza LDAP e Virtual Directory

Scelte da effettuare n vari standard e implementazioni possibili: Standard: OASIS SAML, Liberty Aliance ID-FF n Schema LDAP: inet. Org. Person, edu. Person, … n Sw di Virtual Directory: Oracle, Symlabs, … n Sw LDAP: Oracle, Sun, Open. LDAP, … n Sw di provisioning LDAP Microsoft, Oracle, … n Server di SSO: Shibboleth, CAS, … n

Server di SSO n Varie soluzioni open-source e commerciali n n n JA-SIG CAS A-Select Bandit Project Open. ID Cosign BMC Identity Management Suite Oracle Enterprise Single Sign-On Suite Symlabs Federated Identity Access Manager IBM Tivoli Federated Identity Manager Shibboleth …

Server di SSO n Requisiti: n n n supporto applicazioni legacy (SIS, Portal, Business Objects, Moodle, Mailer, Aleph, CMS, …) vasto parco installato in produzione supporto alla Federated Identity (mutua accettazione degli utenti autenticati da altre università)

Shibboleth: caratteristiche n n n Open-source Standard OASIS SAML Dispone di moduli per n n n Apache (1. 3. x, 2. 0 e 2. 2) Microsoft IIS (4, 5 e 6) Compatibilità legacy n n n CMS: Zope, Plone Sistemi di archiviazione documentale: Dspace Sistemi di learning: Moodle, e. Academy Sistemi di mail: Horde Molto altro…

Shibboleth: federazioni in produzione n n n Svizzera SWITCH AAI: 28 università (175. 000 utenti). Regno Unito The UK Federation: 87 università Finlandia HAKA: 25 università USA: In. Common 41 università, 16 partner Francia: CRU: 28 università Svezia (SWAMID), Danimarca (DK-AAI), Norvegia (FEIDE), …

Shibboleth: progetti pilota n n n Belgio K. U. Leuven Australia Mams “three-year $4. 2 million project sponsored by Australia's Department of Education Science and Training” E in Italia? Il Garr ha organizzato due incontri e istituito un gruppo di lavoro per studiare la realizzazione di una Infrastruttura di Autenticazione e Autorizzazione (AAI) italiana. Il secondo incontro è stato incentrato su Shibboleth.

Link utili n Shibboleth: shibboleth. internet 2. edu/ Compatibilità legacy: n SWITCH AAI: www. switch. ch/aai/ n wiki. internet 2. edu/confluence/display/seas/Home n n n DEMO di sito protetto: https: //kohala. switch. ch/secure/ The UK Federation: www. ukfederation. org. uk USA In. Common: www. incommonfederation. org CRU France: federation. cru. fr/cru/index-en. html Schema LDAP edu. Person: www. nmi-edit. org/edu. Person/draft-internet 2 -mace-direduperson-latest. html