IBM WebSphere Portal security solutions White paper Integrazione del software WebSphere Portal con l infrastruttura di sicurezza delle aziende

IBM WebSphere Portal security solutions White paper Integrazione del software WebSphere Portal con l infrastruttura di sicurezza delle aziende di Ingo Schuster, Frank Seliger, Dieter Bühler e Thomas Schaeck IBM Software Group Ottobre 2003

Pagina 2 Sommario 2 Presentazione 2 Introduzione 4 Scenari di portali tipici 9 Metodi di autenticazione disponibili 10 Autenticazione mediante le funzioni di sicurezza di WebSphere Application Server 10 Autenticazione mediante un proxy di autenticazione distinto 12 Richieste in una sessione autenticata 13 Versatilità del registro utente 14 Accesso alla sessione del portale 15 Sconnessione o timeout dell utente 16 Personalizzazione degli accessi al portale e del processo di sconnessione 16 Capacità di single sign-on 17 Single sign-on da un client alle applicazioni Web 18 Single sign-on tra workstation Microsoft Windows e portali 18 Single sign-on da un portale a un sistema di back-end 23 Sicurezza delle comunicazioni client/ portale 26 Limitazione della protezione alle sole comunicazioni riservate 26 Utilizzo dei certificati del client 27 Connessioni di back-end protette 28 Spiegazione del concetto di controllo degli accessi per proteggere le risorse del portale 33 Amministrazione del controllo degli accessi 34 Delega dell amministrazione 34 Integrazione di sistemi di autorizzazione esterni 35 Gestione della sicurezza del portale 36 Riepilogo 36 Ulteriori informazioni Presentazione I portali offrono accesso personalizzato a informazioni, applicazioni, processi e individui da punti centralizzati. Con essi è possibile autenticare gli utenti e controllare gli accessi per una varietà di informazioni e applicazioni, basate su definizioni di sicurezza predefinite; consentire l accesso pubblico a informazioni non riservate nonché proteggere con sicurezza informazioni importanti, come i dati critici di aziende ed enti governativi. Per rispondere ai diversi requisiti di sicurezza, i server dei portali devono integrarsi con i vari componenti dell infrastruttura di sicurezza, ovvero l autenticazione, l autorizzazione e il controllo dei single signon: ogni azienda deve scegliere la soluzione che meglio risponde alle proprie esigenze di sicurezza. Ad esempio, si può scegliere tra un autenticazione semplice, dove si richiede di immettere un nome utente e una password, oppure affidarsi ad un autenticazione mediante smart card, come quella di una carta bancomat dotata di un chip in cui siano memorizzate una chiave privata e un certificato per attivare l autenticazione sul client mediante SSL (Secure Sockets Layer) o TLS (Transport Layer Security), creando una connessione autenticata e sicura tra client e portale. Grazie alla sua architettura modulare, IBM WebSphere Portal for Multiplatforms, Versione 5.0, consente l integrazione dei proxy di autenticazione, dei sistemi di autorizzazione e delle implementazioni degli archivi di credenziali diversi. Il software WebSphere Portal è concepito per operare con le funzioni di sicurezza 1 di IBM WebSphere Application Server e IBM Tivoli Access Manager, nonché con prodotti di sicurezza di terze parti, per creare un sistema con un livello di sicurezza elevato e adeguato all infrastruttura di cui fa parte. Introduzione L impiego di WebSphere Portal, Versione 5.0, consente di stabilire l accesso alle risorse del portale, come i gruppi di pagine, pagine, portlet e documenti. WebSphere Portal offre diversi metodi per eseguire l autenticazione e l autorizzazione dell utente e fornisce il supporto per il single sign-on. La Figura 1 illustra, da sinistra a destra, i componenti chiave richiamati quando il software WebSphere Portal gestisce le richieste di accesso alle pagine del portale. Sebbene vi siano pagine cui è possibile accedere senza previa autenticazione (utente anonimo), tutte le richieste di pagine personali e pagine di gruppo devono comunque passare attraverso un componente di autenticazione. Se l utente viene autenticato, la richiesta viene analizzata e indirizzata al componente appropriato.

Pagina 3 Figura 1. Sottosistemi di WebSphere Portal, Versione 5.0 Le richieste HTTP da parte di agenti utenti alla ricerca di una pagina di un portale vengono indirizzate al servlet del portale, che agisce come un punto di accesso centrale a tutte le pagine del portale. Le richieste SOAP (Simple Object Access Protocol) da altri portali che hanno lo scopo di richiamare uno dei portlet locali, vengono indirizzate al WSRP (Web Services for Remote Portal) o al router del SOAP. In entrambi i casi, l autorizzazione è obbligatoria. Il componente che riceve la richiesta, richiama il componente di autorizzazione per determinare se è possibile concedere l accesso alla pagina richiesta o al portlet richiamato. Per garantire coerenza nella concessione dei diritti di accesso, le informazioni di autorizzazione relative alla maggior parte delle risorse del portale vengono archiviate sul portale stesso. Tuttavia, per particolari tipi di risorse, il controllo degli accessi viene delegato a sistemi esterni, quali Tivoli Access Manager o Netegrity SiteMinder. Quando una richiesta viene indirizzata al servlet del portale e viene autorizzato l accesso a una pagina, il servlet comincia a ricercare informazioni sui portlet 2 cui fa riferimento la pagina, una volta ottenuti i dati, richiama il componente di autorizzazione per determinare il sottogruppo visualizzabile in base ai diritti di accesso attribuiti

Pagina 4 all utente. Successivamente, in base alle informazioni utente-agente ricevute dalla richiesta, seleziona e richiama il modulo di aggregazione appropriato, fornendo le informazioni relative alla pagina e ai portlet da visualizzare. Il modulo di aggregazione richiamato riporta la pagina e i portlet di riferimento in essa contenuti. Il modulo utilizza l interfaccia di programmazione dell applicazione (API) del portlet per trasferire informazioni supplementari relative al profilo utente e ai dati della richiesta del portlet dall archivio dati di WebSphere Portal al portlet. I portlet sono dei servlet con caratteristiche peculiari, in quanto sono concepiti per partecipare al modello di eventi del portale e sfruttare l infrastruttura del portale stesso. Ne consegue che, un portlet richiamato da un portale è in grado, a sua volta, di richiamare qualsiasi funzione della piattaforma Java 2 Enterprise Edition (J2EE), come connettori J2EE Connector Architecture (JCA), componenti Enterprise JavaBeans (EJB), message bean e componenti Java Database Connectivity (JDBC). Un portlet è in grado, inoltre, di richiamare i servizi Web e le URL (uniform resource locator) HTTP con le stesse modalità con cui richiama altri servlet; inoltre, può richiamare servizi di portlet specifici del portale e librerie di tag concepite per accedere all infrastruttura del portale da componenti JavaServer Pages (JSP). I portlet sono spesso utilizzati per integrare applicazioni back-end e portali, mediante cui offrono un interfaccia utente (UI) basata sul Web. È in queste circostanze che la capacità di single sign-on assume la massima importanza, in quanto, una volta ottenuto l accesso al portale, gli utenti non sono costretti a inserire una password per ciascun portlet applicativo per i rispettivi sistemi di back-end. Per attuare il single signon, WebSphere Portal dispone di un servizio di archivio di credenziali per portlet. Con questo servizio, le credenziali sono disponibili per l inoltro ai sistemi di back-end, dove gli utenti vengono autenticati in maniera trasparente. Il servizio di archivio delle credenziali si basa su un archivo che può essere parte integrante del portale o un archivio Tivoli Access Manager. Scenari di portali tipici Quando si progetta un sistema di portale utilizzando WebSphere Portal, si dispone di una varietà di opzioni di implementazione compresi una protezione semplice mediante firewall e un implementazione Internet basata su portale che offrono diversi livelli di prestazioni, scalabilità, disponibilità e sicurezza.

Pagina 5 Figura 2. Implementazione di un portale all interno di una rete protetta Portali in una rete protetta È possibile utilizzare una configurazione a portale semplice e far risiedere il client in una rete protetta, presumendo che non si prevedono attacchi dall interno. Tuttavia, poiché gli attacchi possono essere lanciati anche da un intranet, questa configurazione, per quanto diffusa, non è ottimale. Il server del portale, il server del database, il registro utenti e i client sono tutti sulla stessa rete, protetta da un firewall, che li rende invisibili su Internet (vedere Figura 2). Il server Web e l application server, con il codice del server del portale, sono situati sulla stessa macchina. I client possono collegarsi al server del portale direttamente,in quanto parte della stessa rete. Il portale utilizza un server di database distinto per archiviare i dati. Tutte le informazioni sugli utenti sono memorizzate nel registro utenti su un altra macchina. Inoltre, alla stessa rete sono collegati i sistemi di back-end accessibili dalle applicazioni del portale. Portali Internet Quando il portale deve servire client basati su Internet, la protezione semplice mediante firewall non è sufficiente. Almeno un nodo del sistema del portale deve essere visibile su Internet. In genere, si utilizzano due o più firewall, anche se le combinazioni disponibili sono varie.

Pagina 6 Figura 3. Esempio di configurazione di portale che serve client su Internet La prima configurazione è indicata per i portali che utilizzano le funzioni di sicurezza proposte da WebSphere Application Server. Se invece è il portale a gestire direttamente l autenticazione e il controllo degli accessi alle risorse, la macchina che funge da server Web dovrà essere visibile su Internet (vedere Figura 3), proprio per la sua connotazione di primo nodo accessibile da client esterni. Vale a dire che il server Web e l application server, con il codice del server del portale, devono essere collocati su macchine diverse. Il server Web deve essere collocato in una zona demilitarizzata (DMZ) all interno di un firewall esterno, in modo da limitare il traffico in entrata alle sole richieste HTTP. Un secondo firewall fornisce una protezione supplementare per la rete interna e i sistemi di back-end, consentendo solo il traffico proveniente dal server Web e diretto al server del portale. Per superare il secondo firewall, l hacker deve assumere il controllo del server Web. Per consentire l accesso ai dati esterni del server del portale, un proxy di uscita presente nella DMZ inoltrerà le richieste dalla Intranet e restituirà le risposte da Internet. Per segmentare ulteriormente l Intranet, si consiglia di utilizzare firewall supplementari.

Pagina 7 Figura 4. Un portale con componente di autenticazione separato La seconda opzione di configurazione è ideale per portali che utilizzano proxy di autenticazione distinti. Per effettuare un autenticazione, WebSphere Portal utilizza il proprio meccanismo di autenticazione o si affida a un proxy di autenticazione separato, come indicato nella Figura 4. Un componente di autenticazione separato è in grado di offrire un punto di autenticazione singolo centralizzato per uno o più portali e altre risorse Web. Il proxy di autenticazione può essere implementato come macchina server distinta, come plug-in per un server Web oppure come plug-in per il software IBM WebSphere Edge Server. Questa configurazione prevede che l autenticazione venga effettuata da un server proxy. Il proxy di autenticazione, protetto da un firewall esterno, sarà il solo nodo visibile ai client che si collegano da Internet. Il proxy di autenticazione collabora con il server di autenticazione, che si trova all interno di un altro firewall. Questo secondo firewall consente l ingresso solo delle richieste provenienti dal proxy di autenticazione e le risposte in entrata provenienti dal proxy di uscita, il quale a sua volta ha il compito di inoltrare le richieste provenienti dall Intranet e restituire le risposte provenienti da Internet. Il server di autorizzazione accede al registro utenti, che fa parte della stessa rete. Il registro utenti viene utilizzato dal server delle autorizzazioni, dal server del portale e da altri sistemi.

Pagina 8 Una configurazione che offre capacità e fault tolerance più elevati, è quella in cui le funzioni del server del portale utilizzano numerose macchine in cluster. Nell esempio riportato nella Figura 4, il cluster si compone di una macchina di load balancing, numerose macchine proxy di caching e e una serie macchine server di portale. Un database del portale, un server di content management e un server di ricerca sono in rete con il server di autorizzazione, il registro utenti e il cluster del server del portale. Un firewall supplementare separe la rete dall Intranet. Un altra variante della configurazione, è quella basata su un cluster di portali, che impiega un cluster di macchine proxy di autencazione distinto, con caratteristiche di load balancing e fault tolerant (vedere Figura 5). Il nodo di rete visibile ai client su Internet sarà in questo caso il load balancer, che distribuisce le richieste tra i diversi proxy di autenticazione, a loro volta situati nella DMZ, in modo che solo le richieste autenticate passino nella rete di produzione, attraverso il secondo firewall. Figura 5. Portale con cluster di server portali e proxy di autenticazione

Pagina 9 Il cluster del server del portale è situato nell area di produzione all interno del secondo firewall, insieme al database del portale, il server di ricerca e il server di content management. Un terzo firewall separa la rete del cluster di server del portale dai client in intranet. La Figura 5 illustra una configurazione tipica di gestione della rete con area di amministrazione separata. Il firewall intermedio utilizza una terza scheda di rete con filtri personalizzati per creare una connessione protetta tra la rete di amministrazione, le DMZ esterne e la rete di produzione. Il server di autorizzazione, il registro utenti, il sistema di amministrazione della rete e il sistema di rilevamento intrusioni (IDS) fanno tutti parte della rete di amministrazione. Metodi di autenticazione disponibili Le funzioni di controllo degli accessi richiedono l identificazione o autenticazione di un utente o un programma che richiedono l accesso a proprietà protetta, quali dati o siti. In molti casi, il processo di autenticazione richiede la stringa di identificazione dell utente (ID utente) e la relativa password per verificarne l autorità. Il metodo standard per fornire questi dati al server è mediante un autenticazione HTTP di base 3, che sfrutta i meccanismi del browser Web, proponendo una finestra di dialogo di accesso comune. In alternativa, si può utilizzare un tipo di autenticazione basata su maschere HTTP, in cui il server invia una maschera di autenticazione personalizzata all utente. Gli schemi di autenticazione basati su password offrono una sicurezza limitata, in quanto la password scelta a volte è mediocre, condivisa e riutilizzata tra sistemi protetti e non protetti o, in alcuni casi, rubata. Altri meccanismi sono l autenticazione mediante client SSL/TLS, un sistema basato su firme digitali e certificati (tra cui archiviazione protetta su smart card), l autenticazione basata su hardware e le password monouso, quali i token RSA SecureID. Inoltre sono disponibili vari dispositivi di rilevazione biometrica, come verifica delle impronte digitali, scansione dell iride e riconoscimento vocale, che contribuiscono a potenziare i meccanismi di autenticazione.

Pagina 10 WebSphere Portal offre un sottosistema di autenticazione che delega l autenticazione dell utente ai meccanismi di base di IBM WebSphere Application Server. Il sottosistema supporta le seguenti configurazioni di autenticazione: Impiego dei meccanismi di autenticazione nativa di WebSphere Application Serta ver. Una maschera di accesso personalizzata registra i dati di autenticazione dell utente in un servlet che quindi richiede l intervento delle funzioni di sicurezza di WebSphere Application Server 4 per convalidare le informazioni ricevute. Questa configurazione sfrutta l integrazione di WebSphere Portal e WebSphere Application Server, nonché la sua capacità di configurare il portale come un applicazione Web sicura. Impiego di un proxy di autenticazione. WebSphere Application Server propone l interfaccia TAI (Trust Association Interceptor) che consente di stabilire una collaborazione tra proxy di autenticazione sicuri. Autenticazione mediante le funzioni di sicurezza di WebSphere Application Server Per utilizzare le funzioni di sicurezza di WebSphere Application Server, il portale viene configurato come un applicazione Web sicura. Quando WebSphere Application Server riceve una richiesta per l applicazione, ovvero il portale, i componenti di sicurezza richiedono le credenziali di autenticazione del client. In base al metodo di autenticazione configurato, la richiesta da parte del componente di sicurezza genera una richiesta di autenticazione HTTP di base, oppure una richiesta HTTP di certificato del client su SSL (HTTPS), vale a dire una richiesta HTTP attraverso una connessione sicura, da inviare al browser Web. In alternativa, il client viene reindirizzato a una maschera di autenticazione che richiede all utente di fornire le credenziali di autenticazione. In quest ultimo caso, la maschera registra le credenziali in un servlet di autenticazione personalizzato di WebSphere Portal. Quest ultimo a sua volta richiama le funzioni di sicurezza di WebSphere Application Server per consentire l accesso all utente, utilizzando il meccanismo di autenticazione HTTP di base, oppure di autenticazione del certificato del client HTTPS, inviando le credenziali direttamente a WebSphere Application Server. WebSphere Application Server autentica gli utenti, confrontando le credenziali inserite con i dati presenti nel registro utenti. Il registro utenti può essere un elenco LDAP (Lightweight Directory Access Protocol) o un registro utenti personalizzato. Autenticazione mediante un proxy di autenticazione distinto Un proxy di autenticazione esterno è in grado di proteggere un portale, intercettando tutte le richieste al portale stesso. Può essere implementato come un server proxy quale WebSEAL in Tivoli Access Manager for e-business, oppure come un plug-in per server HTTP o per WebSphere Edge Server. Alcuni esempi di queste ultime tipologie sono

Pagina 11 Web Agent di Netegrity SiteMinder e il plug-in di Entrust GetAccess. Il plug-in Tivoli Access Manager per WebSphere Edge Server si integra in WebSphere Edge Server invece del server Web. 5 Un componente di autenticazione esterno autentica gli utenti, confrontando le credenziali fornite con i dati contenuti nel registro utenti, in molti casi un elenco LDAP. I TAI (Trust association interceptor) registrati in WebSphere Application Server stabiliscono una connessione tra WebSphere Application Server e il componente di autenticazione che lo protegge. I TAI sono programmi richiamati da WebSphere Application Server per lavorare con componenti di autenticazione esterni, come mostrato nella Figura 6. Il programma preferisce affidarsi a componenti esterni per elaborare le richieste di autenticazione, invece di eseguirle direttamente. WebSphere Application Server definisce l interfaccia che il TAI utilizzerà per la gestione e l autenticazione delle richieste. I TAI comunicano con i componenti di autenticazione e consentono a WebSphere Application Server di accedere alle decisioni di autenticazione, il tutto mediante l interfaccia appropriata. Le richieste di autenticazione per una destinazione sul portale che superano i componenti di autenticazione esterni, vengono ricevute da WebSphere Application Server e passate ai TAI registrati, ricercando in sequenza il responsabile di questa specifica autenticazione e una volta individuato, accetterà o rifiuterà la richiesta. Quando non ci sono TAI in grado di gestire la richiesta in entrata, WebSphere Application Server passa al meccanismo di autenticazione nativo e il client viene reindirizzato alla maschera di accesso personalizzata. Tuttavia, tutto ciò avviene solo con le richieste che oltrepassano il componente di autenticazione esterna. Figura 6. Componenti di autenticazione e TAI

Pagina 12 La Figura 7 illustra il flusso dei controlli effettuati sulle richiesta attraverso il proxy di autenticazione esterno. Le interazioni sono le stesse per i proxy di autenticazione implementati come server distinti e per i proxy implementati come plug-in di server Web o di WebSphere Edge Server. Figura 7. Flusso di controllo di una richiesta inoltrata da un proxy di autenticazione esterno Richieste in una sessione autenticata Una volta completata l autenticazione, l utente accede e inizia una sessione sul portale: in questa fase viene emesso dal client un token Lightweight Third Party Authentication (LTPA), contenente l ID utente e la data e l ora di scadenza, unitamente a un cookie di sessione HTTP (in genere denominato JSESSIONID) 6. LTPA è supportato dai componenti WebSphere.

Pagina 13 Figura 8. Flusso di una richiesta già autenticata Quale prova di autenticazione, le informazioni dell utente vengono firmate e criptate nel token LTPA e verificabili da tutti i server del dominio di single sign-on (SSO) di LTPA (vedere Figura 8). Versatilità del registro utenti Un registro utenti è un repository in grado di memorizzare le informazioni di utenti e gruppi, nonché le applicazioni convalidate dal registro stesso. WebSphere Application Server e WebSphere Portal consentono di scegliere tra un database WebSphere Portal interno, un elenco LDAP e un registro personalizzato da utilizzare come registro utenti. WebSphere Portal condivide il registro delle autenticazioni con WebSphere Application Server, disponendo, al tempo stesso, di un database per profili e preferenze utenti separato. Alcune informazioni sui profili possono essere memorizzate nello stesso archivio del registro delle autenticazioni. Ad esempio, un elenco LDAP può contenere una quantità decisamente maggiore di informazioni su ciascun utente, rispetto ai soli nome e password. In WebSphere Portal, Versione 5.0, le informazioni sull utente sono archiviate centralmente nel componente di gestione membri, che può essere configurato per proporre diversi layout di dati per il registro utenti e il proprio database, come mostra la Tabella 1. WebSphere Portal è in grado di operare anche con un registro utenti di sola lettura, in modo che tutti i dati utente del portale da aggiornare vengano memorizzati in un database interno.

Pagina 14 Tabella 1. Registri di autenticazione supportati e relative impostazioni di WebSphere Application Server e WebSphere Portal Configurazione gestione membri Registro di autenticazione WebSphere Application Server Descrizione LDAP e database LDAP Il registro di autenticazione è un directory server. È possibile configurare le informazioni sui profili da memoriazzare in LDAP e quelle da memorizzare nel database. Solo database Registro utenti del cliente fornito da WebSphere Portal Con WebSphere Portal è possibile utilizzare un registro utenti personalizzato per il database interno. Il registro delle autenticazioni è un componente di gestione membri e le informazioni sui profili sono memorizzate nello stesso database. Registro fornito dal cliente Registro utenti del cliente fornito dal cliente Il cliente fornisce un proprio registro utenti. Le informazioni sui profili sono memorizzate nei database del componente di gestione membri nel registro. Il componente di gestione membri verifica la membership di un gruppo. Questa informazione viene utilizzata dalle funzioni di controllo accessi e di amministrazione di WebSphere Portal. La funzione di ricerca aiuta a valutare i gruppi nidificati. Quinid si può configurare un opzione per interrompere la ricerca della membership del gruppo al primo livello e prevenire quindi una diminuzione delle prestazioni. Accesso alla sessione del portale Dopo l autenticazione effettuata da WebSphere Application Server, viene effettuato l accesso al portale (vedere Figura 9). L oggetto utente viene popolato dal registro utenti e dalla sessione utente ripristinata dall ultimo salvataggio, se tale opzione è stata selezionata. Infine, il browser Web viene reindirizzato alla pagina di destinazione, definibile come parte dei criteri di reindirizzamento. Contemporaneamente alla sequenza di accesso a WebSphere Portal, viene eseguito un accesso di tipo Java Authentication and Authorization Services 7 (JAAS). JAAS è un API Java che suddivide le classi in tre distinte categorie: comune, autenticazione e autorizzazione. WebSphere Portal utilizza, principalmente le classi comuni, come i soggetti JAAS. Solo una parte delle funzionalità delle classi di autenticazione quali LoginContext e LoginModule viene utilizzata e le classi di autorizzazioni sono praticamente inutilizzate. Un accesso di tipo JAAS, conforme alle specifiche JAAS, elabora diversi moduli di accesso e restituisce il soggetto dell utente nel caso l accesso vada a buon fine. Il soggetto è il contenitore dell identità (principi) e delle credenziali dell utente. Ogni modulo di accesso può aggiungere principi o credenziali al soggetto.

Pagina 15 Figura 9. Accesso al portale dopo autenticazione riuscita In base alle specifiche, i moduli di accesso JAAS possono tentare anch essi di autenticare l utente. In WebSphere Portal, tuttavia, l autenticazione dell utente viene già eseguita dal componente nativo di autenticazione. Pertanto, i moduli di accesso JAAS di WebSphere Portal si limitano, in genere, a popolare il soggetto JAAS dell utente, che consente di memorizzare, ad esempio, i token SSO; a loro volta i token SSO possono essere utilizzati da speciali oggetti credenziali attivi in grado di consentire l accesso ai portlet ad altre applicazioni comprese nel dominio SSO. Sessione scaduta e sconnessione dell utente Dopo un periodo specifico di inattività, si può verificare il timeout di una sessione oppure l utente decide di uscire manualmente utilizzando il pulsante di sconnessione creato dal mototre di aggregazione per ciascuna pagina di intestazione. Nel caso di inattività, quando si verifica un timeout, la funzione di sconnessione del portale esegue le seguenti azioni: Sospensione della sessione utente. La sessione dell utente viene definita come persistente. Sconnessione utente portlet. I portlet vengono notificati dell evento user logged out per offrire l opzione di portare a termine o

Pagina 16 arrestare le azioni e le transazioni attive. Se l azione di sconnessione è stata intenzionale e provocata dall utente e non imputabile a timeout della sessione, viene eseguita la procedura di chiusura sessione di WebSphere Application Server. Il token delle credenziali utente viene contrassegnato come non valido e alla risposta viene aggiungo un comando di invalidazione del relativo cookie. Il browser viene reindirizzato per eseguire la procedura di post-logout della destinazione. Quando si impiega un proxy di autenticazione, WebSphere Portal deve essere impostato per reindirizzarsi sulla pagina di chiusura di detto proxy dopo il logout. In questo modo, anche il proxy di autentificazione viene notificato dell avvenuta sconnessione. Personalizzazione degli accessi al portale e dei processi di sconnessione WebSphere Portal consente di personalizzare le procedure di connessione e di sconnessione dal portale. È possibile eseguire le seguenti modifiche: Specificare i criteri di reindirizzamento post-login e post-logout e le destinazioni Aggiungere moduli di accesso JAAS utilizzabili per autenticare un utente e popolare il soggetto dell utente JAAS del portale con principi e credenziali Proteggere mediante SSL le interazioni di connessione e le pagine personalizzate del portale Ampliare o sostituire la connessione delle classi di connessione e sconnessione del portale Capacità di single sign-on WebSphere Portal può essere impiegato per integrare i sistemi IT di un azienda e presentarli attraverso l interfaccia utente del portale. L obiettivo è di eseguire autenticazioni e autorizzazioni su sistemi di back-end mantenendo le due funzioni separate, per conservare i controlli di sicurezza correnti e non dover richiedere ripetutamente all utente di autenticarsi. La capacità di single sign-on offre un metodo affidabile per l autenticazione dei singoli utenti. Essa consente, all interno di un unico ambiente e utilizzando un autenticazione unica per tutta la sessione, di accedere ad applicazioni, sistemi e reti. Con WebSphere Portal, si creano due ambiti SSO, uno dal client al portale e ad altre applicazioni Web, l altro dal portale alle applicazioni back-end (vedere Figura 10). Nel primo caso, un client dovrà effettuare una sola autenticazione per accedere all applicazione Web prescelta, potendo, quindi, accedere a tutte le altre che rientrano nello stesso ambito SSO, senza dover effettuare una seconda autenticazione. Non è rilevante se ad effettuare le autenticazioni delle applicazioni Web sia WebSphere Portal o meno. Allo stesso modo, nel secondo caso, il client del portale dovrà accedere a una sola applicazione back-end per poter accedere, attraverso i rispettivi portlet, a tutte le altre contenute nello

Pagina 17 Figura10. Ambiti SSO di WebSphere Portal stesso ambito senza ulteriore autenticazione. Single sign-on dal client alle applicazioni Web Il single sign-on da un client alle applicazioni Web e al portale può essere effettuato mediante una varietà di meccanismi: Supporto integrato LTPA di WebSphere Application Server Supporto di single sign-on del proxy di autenticazione (come WebSEAL, Netegrity SiteMinder, RSA ClearTrust e Entrust GetAccess) Non vi sono differenze sostanziali nelle funzioni delle varie soluzioni SSO. Una volta effettuata l autenticazione, il client riceve un token di sicurezza che gli consente di superare le barriere di autenticazione. Per ottenere il single sign-on è possibile utilizzare cookie permanenti. Il browser Web archivia il cookie permanente sul client in un formato con protezione minima da lettura e copia. Per garantire un livello di sicurezza maggiore, tuttavia, WebSphere Portal utilizza solo cookie che vengono eliminati alla fine della sessione del browser Web e non cookie permanenti.

Pagina 18 Single sign-on tra workstation Microsoft Windows e portali Grazie a IBM Tivoli Access Manager for e-business, Versione 4.1 e successive, è possibile realizzare il single sign-on tra una workstation Microsoft Windows e i portali. Vale a dire che, un utente può accedere alla workstation locale e quindi utilizzare Microsoft Internet Explorer per accedere a un portale senza dover effettuare la procedura di autenticazione presso la pagina del portale. 8 Single sign-on dal portale a un sistema di back-end WebSphere Portal, Versione 5.0 offre un servizio di portlet che propone un archivio delle credenziali. Questo servizio offre al portale e ai portlet un meccanismo in grado di effettuare il mapping dall identità di un utente in genere l ID utente (principio) a un altra identità con una credenziale, tipo una password. Grazie a questa capacità, non è necessario utilizzare portlet per memorizzare le credenziali utente come parte dei dati del portlet specifici dell utente. Si consiglia invece di aggiornare i portlet per memorizzare le credenziali e utilizzarne gli archivi (vedere Figura 11). Il servizio di archivio credenziali offre le seguenti funzioni: Mappatura su una risorsa in archivio degli slot delle credenziali, degli ID utente e degli ID del portlet. Un portlet può reperire una credenziale solo se esiste un indirizzo abbinato. Ogni slot credenziali è associato a una determinata implementazione in archivio, che consente di conservare credenziali diverse in archivi fisici diversi. Reperire la credenziale dell utente. Alcune credenziali verranno memorizzate e gestite dal portale che utilizza sempre l archivio locale predefinito. Se una password utente non risulta nell archivio locale, verrà richiesta all archivio esterno associato. Se una credenziale non è disponibile o l autenticazione non riesce, viene inviata un eccezione. Il servizio trasmette questa eccezione al portlet associato per consentire la gestione dell errore. Un esempio, è il prompt che richiede all utente di impostare la credenziale mediante la modalità modifica del portlet. L archivio credenziali proibisce a chiunque anche all amministratore del portale - di gestire o utilizzare le credenziali. Solo il titolare ha l accesso e si preserva così il sistema di trust dell utente finale. Non verrà fornito alcun metodo per accedere alle credenziali di un altro utente. Amministrazione dell archivio credenziali (interfaccia di vault management). Gli amministratori del portale possono configurare i servizi di archviazione credenziali non controllati dall utente, ovvero la gestione dei segmenti, gli slot definiti dall amministratore e le credenziali (condivise) di sistema. Sebbene un amministratore

Pagina 19 non possa accedere o modificare slot di credenziali e password definiti dall utente, questi ultimi possono comunque essere eliminati se l utente associato viene eliminato. La Figura 11 illustra la struttura dell archivio credenziali di WebSphere Portal. L archivio è organizzato come segue: L amministratore del portale può partizionare l archivio in segmenti. I segmenti possono essere creati e configurati esclusivamente dall amministratore del portale. Un segmento dell archivio credenziali contiene una o più slot. Gli slot di credenziali sono come dei cassetti da cui i portlet reperiscono credenziali e in cui le memorizzano. Ciascuno slot può memorizzare una sola credenziale, se definito dall utente, e una credenziale per utente, se definito dall amministratore. 9 Figura 11. WebSphere Portal, Versione 5.0 propone un servizio di archivio credenziali per portale Lo slot è collegato a una risorsa in un implementazione dell archivio, dove le credenziali vengono effettivamente memorizzate. Alcuni esempi sono l archivio del database predefinito di WebSphere Portal o il repository di Tivoli Access Manager. Per ciascun segmento dell archivio credenziali, un flag contraddistingue quelli gestibili dall amministratore e quelli gestibili dall utente. Solo gli amministratori possono creare slot per credenziali in un segmento di archivio gestito da un amministratore. I portlet, che agiscono per conto dell utente del portale e hanno il permesso di creare slot di credenziali solo in segmenti di archivio gestiti dall utente, anche se possono impostare e reperire credenziali in entrambi i tipi di segmenti.

Pagina 20 Quindi i portlet che necessitano di una credenziale possono avere due opzioni: quella di usare uno slot di credenziali esistente condiviso che è stato definito dall amministratore del portale oppure creare uno slot di credenziali diverso per ogni singolo utente. Il servizio di archivio credenziali di WebSphere Portal effettua una distinzione tra tre tipologie di slot di credenziali: Uno slot di credenziali di sistema memorizza le credenziali del sistema, condivise tra tutti gli utenti e i portlet. Uno slot di credenziali condiviso che memorizza le credenziali utente condivise tra i portlet dell utente, che sono specifiche per utente ma uguali per tutti i portlet di un utente. Uno slot privato del portlet che memorizza le credenziali utente non condivise tra i portlet. Le credenziali sono specifiche per utente, ma sono le stesse per tutti i portlet di un utente. Il servizio di archivio credenziali restituisce credenziali in formato di oggetti. WebSphere Portal distingue tra oggetti credenziale passiva e attiva. Gli oggetti credenziale passiva sono contenitori per le informazioni riservate della credenziale, quale l ID utente e la password. I portlet che utilizzano credenziali passive devono estrarre le informazioni dalla credenziale stessa. Con gli oggetti credenziale passiva i portlet sono utilizzati per comunicare (autenticare) i sistemi di back-end, come illustrato nell esempio 1. Utilizzo dell oggetto credenziale passivo (pseudo-codice) // Retrieve the credential object from the credential vaultuserpasswo rdpassivecredential credential = (UserPasswordPassiveCredential)serv ice.getcredential(slotid, UserPasswordPassive, null, porletrequest); // Extract the actual secret out of the credential object UserPasswordCredentialSecret secret = credential.getusersecret([ ]); // Portlet connects to back-end system and authenticates using the user s secret... // Portlet uses the connection to communicate with the backend application... // Portlet takes care of logging at the back-end... Esempio 1. Modalità di impiego della credenziale passiva che reca l ID utente e la password

Pagina 21 Un oggetto credenziale attiva nasconde l ID utente e la password dal portlet, rendendolo un metodo ideale per preservare la sicurezza del portlet. Le credenziali attive consentono ai portlet di attivare l autenticazione presso server remoti utilizzando meccanismi standard, ovvero autenticazione HTTP di base, basata su maschera HTTP oppure POP3. Per accedere alle credenziali dal lato del server, le credenziali attive consentono l impiego di token hardware che non espongono mai le proprie informazioni riservate. Questi particolari tipi di token 10 utilizzano credenziali interne all hardware utilizzando gli algoritmi di autenticazione supportati. L esempio 2 illustra come il portlet impiega la credenziale attiva. In questo caso, è una credenziale attiva per l autenticazione basata su maschera HTTP, come mostra la Figura 12. Utilizzo dell oggetto credenziale attiva (pseudo codice) // 1. Retrieve the credential object from the credential vaulthttpformbas edauthcredential credential = (HttpFormBasedAuthCredential)service.getC redential(slotid, HttpFormBasedAuth, config, request); // 2. Log into the backend system credential.login(); // 3. Get an authenticated connection to use URLConnection connection = credential.getauthenticatedconnection(); // 4. Portlet uses the connection to communicate with the backend application... // 5. Log out of backend system credential.logout(); Esempio 2. Modalità di impiego di una credenziale attiva Tutti i tipi di credenziale disponibili all interno del portale sono registrati nel registro credenziali. WebSphere Portal, Versione 5.0 offre un gruppo ristretto di tipologie di credenziali di impiego immediato. Tuttavia, anche altri oggetti credenziali possono essere facilmente registrati.

Pagina 22 Figura 12. Un portlet che utilizza un oggetto credenziale attivo per il back-end single sign-on Oggetti credenziale passiva inclusi: SimplePassive. Memorizza credenziali come oggetti Java da serializzare. UserPasswordPassive. Memorizza credenziali a coppie di ID utente e password. JaasSubjectPassive. Memorizza credenziali come javax.security.a uth.subject objects. Utilizzato per offrire ai portlet il soggetto JAAS stabilito per l utente. BinaryPassive. Memorizza credenziali in un array di byte (implementazione semplice di PassiveCredential per credenziali binarie). Oggetti credenziale attiva incluse: HttpBasicAuth. Memorizza ID utente e password e fornisce supporto per l autenticazione HTTP di base. HttpFormBasedAuth. Memorizza ID utente e password e fornisce supporto per l autenticazione basata su maschera HTTP. JavaMail. Memorizza gli abbinamenti di ID utente e password e fa leva sulla funzionalità di autenticazione dell API di javax.mail. Token LTPA. Supporta l autenticazione presso un sistema di backend compreso nello stesso dominio SSO WebSphere Application Server SSO del portale. SiteMinderToken. Supporta l accesso di sistemi di back-end compresi nello stesso dominio SSO SiteMinder del portale. Utilizzato in genere quando il portale e altre risorse sono protette dal proxy di autenticazione di SiteMinder. WebSEALToken. Supporta l accesso di sistemi di back-end compresi nello stesso dominio SSO WebSEAL del portale. Utilizzato in genere quando il portale e altre risorse sono protette dal proxy di autenticazione di WebSEAL.

Pagina 23 Per motivi di sicurezza, gli oggetti credenziale non implementano java.io.serializable e possono pertanto essere memorizzati solo durante sessioni del portlet come valore di transito. Le classi di credenziali memorizzano il segreto della credenziale attuale come attributo privato. Se fosse serializzata nella tabella della sessione di WebSphere Application Server, la credenziale potrebbe essere letta da chiunque avesse accesso a detto database. Sicurezza delle comunicazioni client/portale I protocolli SSL e TLS 11 fanno leva su algoritmi crittografici diversi per implementare misure di sicurezza ad esempio, l autenticazione mediante certificati, algroritmi di scambio di chiavi di sessione, crittazione e controllo di integrità. Utilizzati in genere consentire la privacy e l affidabilità tra applicazioni in comunicazione tra loro, quali client eb e server Web. SSL e TLS offrono la sicurezza delle connessioni mediante tre proprietà di base: Confidenzialità. La crittazione viene utilizzata dopo l handshake iniziale per definire la chiave privata. La crittografia simmetrica, come Data Encryption Standard (DES) o RC4 viene utilizzata per la crittazione dei dati. Autenticazione. L identità dell utente può essere autenticata mediante crittografia della chiave pubblica, come RSA o DSS. Integrità. Il trasporto del messaggio prevede anche il controllo dell integrità dello stesso mediante il codice MAC (message authentication code). Per il calcolo del MAC vengono utilizzate funzioni hash, quali SHA e MD5. La tecnologia IP security standard (IPSec) rappresenta un alternativa a quella SSL. Rispetto a SSL, funziona a un livello inferiore del modello di riferimento OSI e in genere viene configurata per gestire il livello del sistema operativo. Sebbene sia supportato dalla maggior parte dei sistemi operativi dei client di oggi, solo alcuni sono preconfigurati per IPSec, e pertanto essa non dovrebbe essere utilizzata per comunicare tra client e complessi di server. Quando è necessario proteggere le comunicazioni tra server, tuttavia, la scelta tra SSL e IPSec, diventa una scelta di design. Entrambi le tecnologie offrono i propri vantaggi: IPSec opera a livello di rete e pertanto è trasparente alle applicazioni e non è necessario alcun intervento da parte delle applicazioni per supportarla. Inoltre, è in grado di avere prestazioni più veloci se il sistema operativo utilizza l hardware crittografico disponibile. Anche la tecnologia SSL può sfruttare l hardware crittografico, ma ciascuna applicazione deve essere in grado di supportarla. SSL, d altro canto, è ampiamente supportata e gli amministratori hanno acquisito un elevato grado di esperienza in anni di impiego di questa tecnologia. 12

Pagina 24 Che si usi SSL o IPsec, è necessario decidere dove interrompere la protezione della connessione e quale comunicazioni sono da proteggere. È necessario inoltre proteggere non solo le comunicazioni tra reti non protette (quali Internet), ma anche quelle delle reti aziendali. Non bisogna sottovalutare la possibilità della presenza dell errore umano o dell attacco dall interno. La Figura 13 mostra un semplice scenario di implementazione della tecnologia SSL (vedere Figura 2). Senza sistemi o firewall tra il client e il server del portale, una connessione deve essere protetta mediante SSL. Figura 13. Sicurezza delle comunicazioni per installazioni di portali all interno di una rete protetta Nel secondo scenario di implementazione (vedere Figure 3), il server Web è separato dal server del portale mediante firewall tra client, server Web e server del portale. In questo caso (vedere Figura 14), la DMZ non è del tutto trusted, anche se è consentito avere comunicazioni non protette all interno della rete di produzione. Ancora una volta, è necessario utilizzare la SSL per la connessione con il client. Il primo firewall è configurato per consentire il passaggio di questo tipo di dati. Il percorso tra il server Web e il secondo firewall è protetto mediante IPSec. Figura 14. Sicurezza delle comunicazioni per installazioni di portali in un intranet trusted

Pagina 25 Il terzo scenario di implementazione (vedere Figura 4) posiziona un reverse proxy per l autenticazione nella DMZ e aggiunge un cluster di server di portale alimentati da un load balancer dietro un altro firewall. Un altra possibile implementazione di comunicazione sicura vede l impiego di SSL dal client al reverse proxy e di IPSec a copertura del percorso residuo tra i server (vedere Figura 15). Figura 15. Sicurezza delle comunicazioni di un cluster di portali Internet In una configurazione di portale completamente a cluster con tutte le comunicazioni protette (vedere Figura 16), la connessione SLL del client viene canalizzata attraverso il primo load balancer e fatta terminare presso il cluster del proxy di autenticazione. Questa canalizzazione è consentita in quanto il primo load balancer non ha bisogno di leggere la richiesta per condurre la propria strategia di load balancing. Il secondo, tuttavia, utilizzerà tale strategia e pertanto la successiva connessione SSL deve essere fatta terminare presso detto server. Infine, c è una terza connessione SSL tra il load balancer e il cluster del portale. Quando si aggiunge un elenco LDAP allo scenario di implementazione (vedere Figura 16), è necessario proteggere le comunicazioni tra l application server e il server LDAP, in quanto le query e le risposte LDAP possono contenere informazioni di natura riservata. Il componente di sicurezza WebSphere Application Server può essere configurato per utilizzare LDAP su SSL (LDAPS).

Pagina 26 Figura 16. Comunicazioni sicure in una configurazione di portale completamente a cluster Limitazione della protezione alle sole comunicazioni di natura riservata SSL consuma una notevole quantità di potenza elaborativa. L operazione SSL più dispendiosa è l handshake iniziale, cui si aggiunge la crittazione simmetrica della massa dei dati che produce un ulteriore aggravio dei carichi. Si consiglia, pertanto, di conservare la protezione SSL al minimo necessario. Durante la sessione, WebSphere Portal consente di alternare tra connessioni SSL e non-ssl. È possibile impostare un portale in modo che utilizzi SSL solo per la connessione degli utenti, per la connessione e tutto il contenuto personalizzato oppure per l intero portale. La decisione finale se il portale deve proteggere tutto, in parte oppure niente della comunicazione mediante SSL deve essere basata sulla riservatezza dei dati. Utilizzo dei certificati del client I protocolli SSL e TLS specificano l autenticazione dei partner di comunicazione mediante l impiego di certificati X.509. Il client può ricorrere a un certificato per autenticare il server. Questo tipo di autenticazione è più conveniente di quella mediante password ed evita i noti svantaggi inerenti la sicurezza. Se a questo si abbina la memorizzazione della chiave privata associata e il certificato del client su una smart card, questa forma di autenticazione stabilirà una relazione di trust particolarmente forte. Un opzione di configurazione con WebSphere Application Server può essere l autenticazione forzata del client basata su certificato, da selezionare in fase di configurazione se si impiega un proxy di autenticazione quale Tivoli Access Manager WebSEAL. WebSEAL offre un controllo aggiuntivo, denominato autenticazione step-up, da configurare in modo che richieda automaticamente forma e forza di autenticazione diversa per le varie destinazioni.

Pagina 27 Connessioni back-end sicure Alcuni portlet sono concepiti per accedere ad applicazioni back-endche ospitano informazioni aziendali critiche. Con WebSphere Portal esistono due modi per mantenere questi dati privati: 1. Portlet selezionati possono utilizzare connessioni SSL per scambiare dati con un applicazione back-end corrispondente. In base al tipo di applicazione, potrebbe essere necessario l hand-shake SSL con l autenticazione del client. 2. Il portale e le applicazioni back-end possono istituire una VPN (virtual private network) utilizzando IPSec. WebSphere Portal offre un servizio portlet di accesso ai contenuti che consente ai portlet di stabilire e utilizzare una connessione SSL. È stato concepito per agevolare l assegnazione di una serie di certificati client al portale, utilizzabili dai portlet per autoidentificarsi con applicazioni back-end. Questa raccolta può differire da quanto utilizzato dall application server per autenticarsi direttamente. I certificati del portali sono disponibili solo per portale e portlet. Le altre applicazioni Web installate sullo stesso nodo dell application non possono utilizzarli. Il servizio di accesso ai contenuti offre ampie funzionalità SSL: Se è stato configurato un hanler HTTPS, qualsiasi componente, in modo particolare i portlet, può avviare una connessione HTTPS mediante URLConnection, HttpURLConnection oppure HttpsURLConnection. SSLContext e SSLSocketFaktory saranno creati e assegnati alla connessione al momento. I portlet possono richiedere una markup o un flusso di input, senza che sia necessaria altra comunicazione con il servizio di accesso ai contenuti. Se è stato configurato un proxy HTTPS, qualsiasi URL HTTPS richiesta dal servizio, dovrà passare attraverso detto proxy, a meno che non sia riportato diversamente nell elenco di esclusione del serivizio di accesso ai contenuti. Possono essere configurate tutte le porte, tranne la 443. È possibile configurare un archivio delle chiavi SSL, ovvero una raccolta delle chiavi, da utilizzare per verificare l identità dei sistemi remoti. L archivio delle chiavi verrà utilizzato per tutte le richieste provenienti direttamente da HTTPS e avviate dal servizio di accesso ai contenuti, tranne che per l handshake SSL tra un proxy HTTPS e le applicazioni back-end. È possibile configurare un archivio trust SSL, una raccolta di certificati trusted, con cui i sistemi remoti si presentano al portale per autoautenticarsi. L archivio trust verrà utilizzato per tutte le richieste provenienti direttamente da HTTPS e avviate dal servizio di accesso ai contenuti, tranne che per l handshake SSL tra un proxy HTTPS e le applicazioni back-end.