IBM Tivoli Access Manager: Guida per il responsabile di sistema

IBM Tivoli Access Manager

Guida per il responsabile di sistemaWebSEALVersione 3.9

GC13-3056-00

NotaPrima di utilizzare queste informazioni e il relativo prodotto, consultare quanto riportato in Appendice C, “Informazioniparticolari” a pagina 243.

Quinta edizione (aprile 2002)

Questa edizione sostituisce la pubblicazione GC32-0684-01

© Copyright International Business Machines Corporation 1999, 2002. Tutti i diritti riservati.

Indice

Prefazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixA chi è diretta questa guida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixContenuto della guida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPubblicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xPubblicazioni correlate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiAccesso alle pubblicazioni in linea. . . . . . . . . . . . . . . . . . . . . . . . . . . xvOrdinare le pubblicazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvCommenti sulle pubblicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Accessibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviContattare il servizio di assistenza ai clienti . . . . . . . . . . . . . . . . . . . . . . . . xviConvenzioni utilizzate in questo manuale . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Convenzioni tipografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Capitolo 1. Panoramica su IBM Tivoli Access Manager WebSEAL . . . . . . . . . . . 1Introduzione a IBM Tivoli Access Manager e WebSEAL . . . . . . . . . . . . . . . . . . . . . 1Comprensione del modello di protezione di Access Manager . . . . . . . . . . . . . . . . . . . 3

Lo spazio oggetti protetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Definizione e applicazione di criteri ACL e POP . . . . . . . . . . . . . . . . . . . . . . 4Gestione del criterio: Il gestore di portale Web . . . . . . . . . . . . . . . . . . . . . . . 6

Protezione dello spazio Web con WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 6Pianificazione e implementazione dei criteri di protezione . . . . . . . . . . . . . . . . . . . . 8

Identificazione dei tipi di contenuto e livelli di protezione . . . . . . . . . . . . . . . . . . . 8Comprensione della configurazione WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 9

Obiettivi dell’autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Accesso autenticato e non autenticato alle risorse . . . . . . . . . . . . . . . . . . . . . . 11Struttura della cache sessione/credenziali WebSEAL. . . . . . . . . . . . . . . . . . . . . 12

Comprensione dei junction WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . 13Junction WebSEAL e scalabilità del sito Web . . . . . . . . . . . . . . . . . . . . . . . 15

Capitolo 2. Configurazione base del server . . . . . . . . . . . . . . . . . . . . 19Informazioni generali sul server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Directory principale dell’installazione WebSEAL . . . . . . . . . . . . . . . . . . . . . . 19Avvio e arresto di WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20WebSEAL rappresentato nello spazio oggetti protetti . . . . . . . . . . . . . . . . . . . . 20WebSEAL restituisce HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20File di log GWebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Utilizzo del file di configurazione WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 21Introduzione al file di configurazione webseald.conf. . . . . . . . . . . . . . . . . . . . . 21Directory principale del server WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 23

Configurazione dei parametri di comunicazione . . . . . . . . . . . . . . . . . . . . . . . 23Configurazione di WebSEAL per richieste HTTP . . . . . . . . . . . . . . . . . . . . . . 23Configurazione di WebSEAL per richieste HTTPS . . . . . . . . . . . . . . . . . . . . . 24Limitazione delle connessioni da versioni SSL specifiche . . . . . . . . . . . . . . . . . . . 24Parametri di timeout per comunicazione HTTP/HTTPS . . . . . . . . . . . . . . . . . . . 24Ulteriori parametri di timeout del server WebSEAL . . . . . . . . . . . . . . . . . . . . . 25

Gestione dello spazio Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Directory principale della struttura documenti Web . . . . . . . . . . . . . . . . . . . . . 26Configurazione dell’indice directory . . . . . . . . . . . . . . . . . . . . . . . . . . 27Windows: Denominazione file per programmi CGI . . . . . . . . . . . . . . . . . . . . . 28Configurazione cache di documenti Web . . . . . . . . . . . . . . . . . . . . . . . . 28Specifica dei tipi di documento per il filtro . . . . . . . . . . . . . . . . . . . . . . . . 31

Gestione delle pagine di messaggi di errore HTTP personalizzate . . . . . . . . . . . . . . . . . 31Supporto macro per pagine di messaggi di errore HTTP . . . . . . . . . . . . . . . . . . . 33

Gestione delle pagine di gestione account personalizzate . . . . . . . . . . . . . . . . . . . . 34

© Copyright IBM Corp. 1999, 2002 iii

Parametri e valori delle pagine personalizzate . . . . . . . . . . . . . . . . . . . . . . . 34Descrizioni delle pagine HTML personalizzate. . . . . . . . . . . . . . . . . . . . . . . 34

Gestione di certificati del cliente e del server . . . . . . . . . . . . . . . . . . . . . . . . 35Comprensione dei tipi di file del database di chiavi GSKit . . . . . . . . . . . . . . . . . . . 36Configurazione dei parametri del database di chiavi. . . . . . . . . . . . . . . . . . . . . 37Utilizzo del programma di utilità iKeyman per la gestione dei certificati . . . . . . . . . . . . . . 38Configurazione del controllo CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Configurazione della cache CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Configurazione della funzione di registrazione HTTP predefinita . . . . . . . . . . . . . . . . . 40Abilitazione e disabilitazione della funzione di registrazione HTTP . . . . . . . . . . . . . . . . 40Specifica del tipo di formato data/ora . . . . . . . . . . . . . . . . . . . . . . . . . 41Specifica delle soglie di rollover del file di log . . . . . . . . . . . . . . . . . . . . . . . 41Specifica della frequenza di cancellazione dei buffer dei file di log . . . . . . . . . . . . . . . . 41Formato di log HTTP comune (per request.log) . . . . . . . . . . . . . . . . . . . . . . 42Visualizzazione del file request.log . . . . . . . . . . . . . . . . . . . . . . . . . . 42Visualizzazione del file agent.log . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Visualizzazione di referer.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Configurazione del logging HTTP mediante il logging di eventi . . . . . . . . . . . . . . . . . . 43Registrazione messaggi di funzionalità WebSEAL. . . . . . . . . . . . . . . . . . . . . . . 44

Capitolo 3. Configurazione avanzata del server . . . . . . . . . . . . . . . . . . 47Configurazione di una qualità di protezione di livello predefinito . . . . . . . . . . . . . . . . . 47

Configurazione QOP per singoli host e singole reti . . . . . . . . . . . . . . . . . . . . . 48Configurazione aggiornamenti e polling del database autorizzazioni . . . . . . . . . . . . . . . . 48

Configurazione ascolto notifiche di aggiornamento . . . . . . . . . . . . . . . . . . . . . 49Configurazione polling del database autorizzazioni . . . . . . . . . . . . . . . . . . . . . 49

Gestione dell’assegnazione dei thread di processo . . . . . . . . . . . . . . . . . . . . . . 49Configurazione dei thread di processo di WebSEAL . . . . . . . . . . . . . . . . . . . . . 50Assegnazione di thread di processo per junction (equità junction) . . . . . . . . . . . . . . . . 50

Replica di server WebSEAL front-end. . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configurazione di istanze multiple del server WebSEAL . . . . . . . . . . . . . . . . . . . . 53

Panoramica sulla configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Configurazione di istanze multiple WebSEAL su UNIX . . . . . . . . . . . . . . . . . . . . 54Configurazione di istanze multiple WebSEAL su Win NT/2000 . . . . . . . . . . . . . . . . . 56Annullamento della configurazione di istanze multiple WebSEAL . . . . . . . . . . . . . . . . 58Comandi di avvio, arresto, riavvio e stato del server. . . . . . . . . . . . . . . . . . . . . 59

Configurazione SU (switch user) per i responsabili . . . . . . . . . . . . . . . . . . . . . . 60Comprensione del flusso del processo switch user . . . . . . . . . . . . . . . . . . . . . 60Abilitazione della funzione switch user: riepilogo. . . . . . . . . . . . . . . . . . . . . . 61Configurazione del modulo HTML switch user . . . . . . . . . . . . . . . . . . . . . . 62Abilitazione ed esclusione di utenti da switch user . . . . . . . . . . . . . . . . . . . . . 63Configurazione del meccanismo di autenticazione switch user . . . . . . . . . . . . . . . . . 64Configurazione di un meccanismo switch user CDAS . . . . . . . . . . . . . . . . . . . . 65Impatto su altre funzionalità di WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 66

Configurazione cache di richieste WebSEAL del server . . . . . . . . . . . . . . . . . . . . . 67Informazioni secondarie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Flusso del processo di cache del server . . . . . . . . . . . . . . . . . . . . . . . . . 67Configurazione di parametri di cache del server . . . . . . . . . . . . . . . . . . . . . . 68Note e limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Gestione dei caratteri codificati UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . . . 70Prevenzione della vulnerabilità causata da scripting cross-site . . . . . . . . . . . . . . . . . . 71

Informazioni secondarie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configurazione del filtro di stringa URL. . . . . . . . . . . . . . . . . . . . . . . . . 72

Soppressione dell’identità del server . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Utilizzo di statistiche WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Sintassi del comando pdadmin stats . . . . . . . . . . . . . . . . . . . . . . . . . . 73Componenti di statistiche e tipi di attività . . . . . . . . . . . . . . . . . . . . . . . . 76Abilitazione delle statistiche in modo statico mediante il logging di eventi . . . . . . . . . . . . . 81

Utilizzo del programma di utilità di traccia per la cattura di azioni WebSEAL . . . . . . . . . . . . . 82Sintassi dei comandi trace di base . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Componenti di traccia WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

iv IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Capitolo 4. Criteri di sicurezza WebSEAL . . . . . . . . . . . . . . . . . . . . . 85Criteri ACL specifici di WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

/WebSEAL/<host>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85/WebSEAL/<host>/<file> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Autorizzazioni ACL WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Criterio ACL Default/WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Caratteri validi per i nomi ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Criterio three strikes login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Sintassi dei comandi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Criteri di rafforzamento della password . . . . . . . . . . . . . . . . . . . . . . . . . . 88Criteri di rafforzamento password impostati dal programma di utilità pdadmin . . . . . . . . . . . 88Sintassi dei comandi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Esempi di password valide e non valide. . . . . . . . . . . . . . . . . . . . . . . . . 90Impostazioni specifiche per l’utente e globali . . . . . . . . . . . . . . . . . . . . . . . 90

Criterio POP di rafforzamento autenticazione (a fasi) . . . . . . . . . . . . . . . . . . . . . 91Configurazione dei livelli per l’autenticazione a fasi . . . . . . . . . . . . . . . . . . . . . 91Abilitazione dell’autenticazione a fasi. . . . . . . . . . . . . . . . . . . . . . . . . . 92Modulo di login a fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Algoritmo di autenticazione a fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Note e limitazioni per l’autenticazione a fasi . . . . . . . . . . . . . . . . . . . . . . . 94Distinzione tra autenticazione a fasi e multi-factor . . . . . . . . . . . . . . . . . . . . . 95

Criterio POP di autenticazione basato su rete . . . . . . . . . . . . . . . . . . . . . . . . 96Configurazione dei livelli di autenticazione . . . . . . . . . . . . . . . . . . . . . . . . 96Specifica di indirizzi IP e intervalli . . . . . . . . . . . . . . . . . . . . . . . . . . 97Disabilitazione dell’autenticazione a fasi mediante indirizzo IP . . . . . . . . . . . . . . . . . 98Algoritmo di autenticazione basata su rete . . . . . . . . . . . . . . . . . . . . . . . . 98Note e limitazioni per l’autenticazione basata su rete . . . . . . . . . . . . . . . . . . . . 98

Criterio POP di qualità di protezione . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Gestione di utenti non autenticati (HTTP/HTTPS) . . . . . . . . . . . . . . . . . . . . . . 99

Elaborazione di una richiesta da client anonimo . . . . . . . . . . . . . . . . . . . . . . 99Forzatura del login utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Applicazioni di HTTPS non autenticati . . . . . . . . . . . . . . . . . . . . . . . . . 100Controllo di utenti non autenticati con criteri ACL/POP . . . . . . . . . . . . . . . . . . . 100

Capitolo 5. Autenticazione WebSEAL . . . . . . . . . . . . . . . . . . . . . . 101Comprensione del processo di autenticazione. . . . . . . . . . . . . . . . . . . . . . . . 101

Tipi di dati di sessione supportati . . . . . . . . . . . . . . . . . . . . . . . . . . 102Metodi di autenticazione supportati . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Gestione dello stato di sessione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Panoramica dello stato di sessione . . . . . . . . . . . . . . . . . . . . . . . . . . 103Panoramica della cache di sessione GSKit e WebSEAL. . . . . . . . . . . . . . . . . . . . 103Configurazione cache ID sessione SSL GSKit . . . . . . . . . . . . . . . . . . . . . . . 104Configurazione della cache di sessione/credenziali WebSEAL . . . . . . . . . . . . . . . . . 105Mantenimento dello stato con cookie di sessione . . . . . . . . . . . . . . . . . . . . . 106Individuazione di tipi di dati ID sessione validi . . . . . . . . . . . . . . . . . . . . . . 108Configurazione dei cookie di failover . . . . . . . . . . . . . . . . . . . . . . . . . 108

Panoramica sulla configurazione dell’autenticazione . . . . . . . . . . . . . . . . . . . . . 112Parametri di autenticazione locali. . . . . . . . . . . . . . . . . . . . . . . . . . . 112Parametri di autenticazione CDAS esterni personalizzati . . . . . . . . . . . . . . . . . . . 112Configurazione predefinita per l’autenticazione WebSEAL . . . . . . . . . . . . . . . . . . 113Configurazione di metodi di autenticazione multipli . . . . . . . . . . . . . . . . . . . . 113Richiesta di login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Comandi di logout e modifica password . . . . . . . . . . . . . . . . . . . . . . . . 114

Configurazione dell’autenticazione Base (BA). . . . . . . . . . . . . . . . . . . . . . . . 115Abilitazione e disabilitazione di BA (Basic Authentication) . . . . . . . . . . . . . . . . . . 115Impostazione del nome realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Configurazione del meccanismo Basic Authentication . . . . . . . . . . . . . . . . . . . . 116Condizioni di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Configurazione dell’autenticazione moduli . . . . . . . . . . . . . . . . . . . . . . . . 117Abilitazione e disabilitazione dell’autenticazione moduli . . . . . . . . . . . . . . . . . . . 117Configurazione del meccanismo di autenticazione moduli . . . . . . . . . . . . . . . . . . 117

Indice v

Condizioni di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Personalizzazione dei moduli di risposta HTML. . . . . . . . . . . . . . . . . . . . . . 118

Configurazione dell’autenticazione via certificato del client . . . . . . . . . . . . . . . . . . . 118Informazioni secondarie: Autenticazione reciproca mediante certificati . . . . . . . . . . . . . . 118Il certificato di prova WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Abilitazione e disabilitazione dell’autenticazione mediante certificato . . . . . . . . . . . . . . . 120Configurazione del meccanismo di autenticazione mediante certificato . . . . . . . . . . . . . . 120Condizioni di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Configurazione dell’autenticazione mediante intestazione HTTP . . . . . . . . . . . . . . . . . 121Abilitazione e disabilitazione dell’autenticazione mediante intestazione HTTP . . . . . . . . . . . . 121Specifica dei tipi di intestazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Configurazione del meccanismo di autenticazione di intestazione HTTP. . . . . . . . . . . . . . 122Condizioni di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configurazione dell’autenticazione mediante indirizzo IP. . . . . . . . . . . . . . . . . . . . 123Abilitazione e disabilitazione dell’autenticazione di indirizzo IP . . . . . . . . . . . . . . . . 123Configurazione del meccanismo di autenticazione mediante indirizzo IP . . . . . . . . . . . . . 123

Configurazione dell’autenticazione token . . . . . . . . . . . . . . . . . . . . . . . . . 123Abilitazione e disabilitazione dell’autenticazione token . . . . . . . . . . . . . . . . . . . 123Configurazione del meccanismo di autenticazione via token . . . . . . . . . . . . . . . . . . 123

Supporto MPA (multiplexing proxy agents) . . . . . . . . . . . . . . . . . . . . . . . . 124Tipi di dati di sessione e metodi di autenticazione validi . . . . . . . . . . . . . . . . . . . 125Flusso del processo di autenticazione per MPA e client multipli . . . . . . . . . . . . . . . . 126Abilitazione e disabilitazione dell’autenticazione MPA. . . . . . . . . . . . . . . . . . . . 127Creazione di un account utente per MPA . . . . . . . . . . . . . . . . . . . . . . . . 127Aggiunta dell’account MPA al gruppo webseal-mpa-servers . . . . . . . . . . . . . . . . . . 127Limitazioni dell’autenticazione MPA. . . . . . . . . . . . . . . . . . . . . . . . . . 127

Configurazione della riautenticazione basata su criteri di protezione . . . . . . . . . . . . . . . . 127Condizioni riguardanti la riautenticazione POP . . . . . . . . . . . . . . . . . . . . . . 127Creazione e applicazione del POP di riautenticazione . . . . . . . . . . . . . . . . . . . . 128Configurazione di reimpostazione ed estensione della durata di cache di sessione . . . . . . . . . . 129

Configurazione della riautenticazione basata sul criterio di inattività della sessione . . . . . . . . . . . 130Condizioni riguardanti la riautenticazione per inattività . . . . . . . . . . . . . . . . . . . 130Abilitazione della riautenticazione per inattività . . . . . . . . . . . . . . . . . . . . . . 131Configurazione di reimpostazione ed estensione della durata di cache di sessione . . . . . . . . . . 131

Capitolo 6. Soluzioni CDSSO (cross-domain sign-on) . . . . . . . . . . . . . . . 135Configurazione autenticazione CDSSO . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Integrazione di una libreria condivisa CDMF personalizzata. . . . . . . . . . . . . . . . . . 135Flusso del processo di autenticazione per CDSSO con CDMF . . . . . . . . . . . . . . . . . 135Abilitazione e disabilitazione dell’autenticazione CDSSO . . . . . . . . . . . . . . . . . . . 137Configurazione del meccanismo di autenticazione CDSSO . . . . . . . . . . . . . . . . . . 137Codifica dei dati del token di autenticazione . . . . . . . . . . . . . . . . . . . . . . . 138Configurazione della registrazione data/ora del token. . . . . . . . . . . . . . . . . . . . 138Espressione dei collegamenti HTML CDSSO . . . . . . . . . . . . . . . . . . . . . . . 139Protezione del token di autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . 139

Configurazione single sign-on e-community . . . . . . . . . . . . . . . . . . . . . . . . 139Funzioni e requisiti dell’e-community . . . . . . . . . . . . . . . . . . . . . . . . . 141Flusso del processo e-community. . . . . . . . . . . . . . . . . . . . . . . . . . . 141Comprensione del cookie e-community. . . . . . . . . . . . . . . . . . . . . . . . . 145Comprensione della richiesta e risposta “di convalida” . . . . . . . . . . . . . . . . . . . 146Comprensione del token “di convalida” . . . . . . . . . . . . . . . . . . . . . . . . 147Codifica del token “di convalida” . . . . . . . . . . . . . . . . . . . . . . . . . . 147Configurazione di una e-community . . . . . . . . . . . . . . . . . . . . . . . . . 148

Capitolo 7. Junction WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 153Panoramica sui junction WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Ubicazione e formato del database di junction . . . . . . . . . . . . . . . . . . . . . . 153Applicazione del controllo accesso superficiale: riepilogo . . . . . . . . . . . . . . . . . . . 154Applicazione del controllo accesso raffinato: riepilogo . . . . . . . . . . . . . . . . . . . . 154Indicazioni per la creazione di junction WebSEAL . . . . . . . . . . . . . . . . . . . . . 154

vi IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Ulteriori riferimenti per i junction WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 155Utilizzo di pdadmin per creare junction . . . . . . . . . . . . . . . . . . . . . . . . . 155Configurazione di un junction WebSEAL base . . . . . . . . . . . . . . . . . . . . . . . 156

Creazione di junction di tipo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 156Creazione di junction di tipo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Aggiunta di server back-end supplementari a un junction . . . . . . . . . . . . . . . . . . 158

Junction SSL autenticati reciprocamente . . . . . . . . . . . . . . . . . . . . . . . . . 158WebSEAL convalida il certificato del server di back-end . . . . . . . . . . . . . . . . . . . 159Corrispondenza DN (Distinguished name) . . . . . . . . . . . . . . . . . . . . . . . 159WebSEAL effettua l’autenticazione con il certificato del client . . . . . . . . . . . . . . . . . 159WebSEAL effettua l’autenticazione con l’intestazione BA . . . . . . . . . . . . . . . . . . . 160Gestione dei dati sull’identità del client attraverso junction . . . . . . . . . . . . . . . . . . 160

Creazione di junction proxy TCP e SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 161Junction WebSEAL-WebSEAL su SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 162Modifica di URL a risorse di back-end . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Comprensione dei tipi di percorso utilizzati in URL . . . . . . . . . . . . . . . . . . . . 164Filtro degli URL nelle risposte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Elaborazione di URL nelle richieste . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Opzioni di junction supplementari . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Forzatura di un nuovo junction (–f) . . . . . . . . . . . . . . . . . . . . . . . . . . 169Per fornire l’identità client nelle intestazioni HTTP (–c) . . . . . . . . . . . . . . . . . . . 170Specifica di indirizzi IP client nelle intestazioni HTTP (–r) . . . . . . . . . . . . . . . . . . 171Limitazione della dimensione di intestazioni HTTP generate da WebSEAL . . . . . . . . . . . . . 172Trasmissione dei cookie di sessione ai server di portale di junction (–k) . . . . . . . . . . . . . . 173Supporto di URL non sensibili al maiuscolo/minuscolo (–i) . . . . . . . . . . . . . . . . . . 173Supporto di junction di stato (–s, –u) . . . . . . . . . . . . . . . . . . . . . . . . . 174Specifica UUID di server back-end per junction di stato (–u) . . . . . . . . . . . . . . . . . 174Junction a file system Windows (–w) . . . . . . . . . . . . . . . . . . . . . . . . . 177

Note tecniche per l’utilizzo di junction WebSEAL . . . . . . . . . . . . . . . . . . . . . . 178Montaggio di server multipli sullo stesso junction . . . . . . . . . . . . . . . . . . . . . 178Eccezioni nell’applicazione di autorizzazioni sui junction . . . . . . . . . . . . . . . . . . . 178Autenticazione di certificato attraverso junction . . . . . . . . . . . . . . . . . . . . . . 179

Utilizzo di query_contents con server di terzi . . . . . . . . . . . . . . . . . . . . . . . 179Installazione dei componenti query_contents . . . . . . . . . . . . . . . . . . . . . . . 179Installazione di query_contents su server UNIX di terzi . . . . . . . . . . . . . . . . . . . 180Installazione di query_contents su server Win32 di terzi . . . . . . . . . . . . . . . . . . . 180Personalizzazione di query_contents. . . . . . . . . . . . . . . . . . . . . . . . . . 182Protezione di query_contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Capitolo 8. Soluzioni Web single sign-on . . . . . . . . . . . . . . . . . . . . 185Configurazione di intestazioni BA per soluzioni single sign-on . . . . . . . . . . . . . . . . . . 185

Concetti SSO (single sign-on) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Per fornire l’identità client nelle intestazioni BA . . . . . . . . . . . . . . . . . . . . . . 186Specifica dell’identità client e di una password generica . . . . . . . . . . . . . . . . . . . 186Invio di informazioni sull’intestazione BA originale del client . . . . . . . . . . . . . . . . . 187Rimozione delle informazioni di intestazione BA del client . . . . . . . . . . . . . . . . . . 188Specifica di nomi utente e password da GSO . . . . . . . . . . . . . . . . . . . . . . . 189

Utilizzo di GSO (global sign-on) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Associazione delle informazioni di autenticazione . . . . . . . . . . . . . . . . . . . . . 190Configurazione di un junction WebSEAL abilitato per GSO . . . . . . . . . . . . . . . . . . 191Configurazione della cache GSO . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Configurazione SSO (single sign-on) per IBM WebSphere (LTPA) . . . . . . . . . . . . . . . . . 192Configurazione di un junction LTPA. . . . . . . . . . . . . . . . . . . . . . . . . . 193Configurazione della cache LTPA. . . . . . . . . . . . . . . . . . . . . . . . . . . 193Note tecniche per single sign-on LTPA . . . . . . . . . . . . . . . . . . . . . . . . . 194

Configurazione dell’autenticazione SSO (single sign-on) di moduli . . . . . . . . . . . . . . . . 194Informazioni secondarie e obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 194Flusso del processo single sign-on di moduli . . . . . . . . . . . . . . . . . . . . . . . 195Requisiti per il supporto di applicazioni . . . . . . . . . . . . . . . . . . . . . . . . 196Creazione del file di configurazione per SSO di moduli . . . . . . . . . . . . . . . . . . . 197Abilitazione del single sign-on di moduli . . . . . . . . . . . . . . . . . . . . . . . . 200

Indice vii

File di configurazione di esempio per IBM HelpNow . . . . . . . . . . . . . . . . . . . . 201

Capitolo 9. Integrazione di applicazioni . . . . . . . . . . . . . . . . . . . . . 203Supporto della programmazione CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Windows: Supporto di variabili di ambiente WIN32 . . . . . . . . . . . . . . . . . . . . 204Supporto di applicazioni per il server back-end . . . . . . . . . . . . . . . . . . . . . . . 205Miglior utilizzo di junction per l’integrazione di applicazioni . . . . . . . . . . . . . . . . . . 205

Come fornire informazioni di intestazione HOST complete con -v . . . . . . . . . . . . . . . . 206Supporto del filtro URL assoluto standard . . . . . . . . . . . . . . . . . . . . . . . . 206

Creazione di un servizio di personalizzazione privato . . . . . . . . . . . . . . . . . . . . . 207Configurazione di WebSEAL per un servizio di personalizzazione . . . . . . . . . . . . . . . . 208Esempio di servizio di personalizzazione . . . . . . . . . . . . . . . . . . . . . . . . 208

Abilitazione di concessioni dynamic business (tag/valore) . . . . . . . . . . . . . . . . . . . 209Creazione di concessioni business da dati LDAP . . . . . . . . . . . . . . . . . . . . . 209

Mantenimento dello stato di sessione tra client e applicazioni back-end . . . . . . . . . . . . . . . 211Informazioni secondarie per la gestione della sessione utente . . . . . . . . . . . . . . . . . 212Abilitazione della gestione id sessione utente . . . . . . . . . . . . . . . . . . . . . . . 212Inserimento dei dati di credenziale nell’intestazione HTTP . . . . . . . . . . . . . . . . . . 213Conclusione delle sessioni utente . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Controllo dell’accesso agli URL dinamici . . . . . . . . . . . . . . . . . . . . . . . . . 215Componenti URL dinamici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Associazione di oggetti ACL e POP a URL dinamici . . . . . . . . . . . . . . . . . . . . 216Aggiornamento di WebSEAL per URL dinamici . . . . . . . . . . . . . . . . . . . . . . 218Risoluzione di URL dinamici nello spazio oggetti . . . . . . . . . . . . . . . . . . . . . 218Configurazione di limitazioni su richieste POST . . . . . . . . . . . . . . . . . . . . . . 219Riepilogo e note tecniche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Esempio di URL dinamico: Travel Kingdom . . . . . . . . . . . . . . . . . . . . . . . . 221L’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221L’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Il criterio di protezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Client protetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Controllo dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Conclusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Appendice A. Riferimento webseald.conf . . . . . . . . . . . . . . . . . . . . 225

Appendice B. Riferimento junction WebSEAL . . . . . . . . . . . . . . . . . . 237Utilizzo di pdadmin per creare junction . . . . . . . . . . . . . . . . . . . . . . . . . 237I comandi junction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Creazione di un nuovo junction per un server iniziale . . . . . . . . . . . . . . . . . . . . . 239Aggiunta di un server supplementare a un junction esistente . . . . . . . . . . . . . . . . . . 241

Appendice C. Informazioni particolari . . . . . . . . . . . . . . . . . . . . . . 243Marchi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Indice analitico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

viii IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Prefazione

Benvenuti nella Guida per il responsabile IBM®Tivoli®Access Manager WebSEAL.

IBM Tivoli Access Manager WebSEAL è il gestore per la protezione delle risorsebasate su Web. WebSEAL è un server Web a elevate prestazioni, multi-thread, cheapplica un criterio di protezione elevata allo spazio dell’oggetto Web protetto. Essoè in grado di fornire singole soluzioni di registrazione e incorporare le risorse diserver delle applicazioni Web back-end nei propri criteri di protezione.

La presente guida per il responsabile fornisce una serie dettagliata di informazionidi riferimento e procedure per la gestione delle risorse del proprio dominio Webprotetto. Questa guida fornisce anche informazioni secondarie e di concetto relativeall’ampia gamma della funzionalità WebSEAL.

A chi è diretta questa guidaQuesta guida è diretta al responsabile degli amministratori di sistema per laconfigurazione e la manutenzione di un ambiente Access Manager WebSEAL.

I lettori dovrebbero avere familiarità con i seguenti argomenti:v Sistemi operativi PC e UNIX®

v Concetti ed architettura databasev Gestione sicurezzav Protocolli Internet, inclusi HTTP, TCP/IP, File Transfer Protocol (FTP) e Telnetv LDAP(Lightweight Directory Access Protocol)e servizi di directoryv Un registro utenti supportatov Autenticazione ed autorizzazione

Se viene abilitata la comunicazione SSL (Secure Sockets Layer), si dovrebbe averela giusta familiarità con il protocollo SSL, il cambio di chiavi (pubblico e privato),le firme digitali, gli algoritmi crittografici e le autorità di certificato.

Contenuto della guidav Capitolo 1: Panoramica su IBM Tivoli Access Manager WebSEAL

Questo capitolo introduce l’utente ai fondamentali concetti e alla funzionalitàWebSEAL, ad esempio: organizzazione e protezione dello spazio oggetti,autenticazione, acquisizione di credenziali e junction WebSEAL.

v Capitolo 2: Configurazione base del server

Questo capitolo rappresenta un riferimento tecnico per attività generali diconfigurazione di WebSEAL, comprendenti: l’utilizzo del file di configurazioneWebSEAL, la gestione dello spazio Web, la gestione di certificati e laconfigurazione della funzione di logging.

v Capitolo 3: Configurazione avanzata del server

Questo capitolo rappresenta un riferimento tecnico per attività avanzate diconfigurazione WebSEAL, comprendenti: la configurazione di istanze multipleWebSEAL, la configurazione della funzionalità di commutazione utente, lagestione dell’assegnazione dei thread di processo e la configurazione degliaggiornamenti e del polling del database di autorizzazioni.

© Copyright IBM Corp. 1999, 2002 ix

v Capitolo 4: Criteri di sicurezza WebSEAL

Questo capitolo fornisce procedure tecniche dettagliate per la personalizzazionedei criteri di protezione su WebSEAL, incluso: criteri ACL e POP, qualità dellaprotezione (QOP), criterio di autenticazione a fasi, criterio di autenticazionebasato sulla rete, criterio di login a tre fasi e criterio di ristrettezza dellapassword.

v Capitolo 5: Autenticazione WebSEAL

Questo capitolo fornisce procedure tecniche dettagliate per l’impostazione diWebSEAL per la gestione di una serie di metodi di autenticazione, incluso: nomeutente e password, certificati del client, codice di accesso del token SecurID, datidi intestazione HTTP speciali e funzionalità di riautenticazione.

v Capitolo 6: Soluzioni CDSSO (cross domain sign-on)

Questo capitolo tratta delle soluzioni CDSSO (cross domain sign-on) per la parteesterna di una configurazione proxy di WebSEAL, tra il cliente e il serverWebSEAL.

v Capitolo 7: Junction WebSEAL

Questo capitolo rappresenta un completo riferimento tecnico per l’impostazionee l’utilizzo di junction WebSEAL.

v Capitolo 8: Soluzioni Web SSO (single sign-on)

Questo capitolo tratta delle soluzioni SSO (single sign-on) per la parte interna diuna configurazione proxy di WebSEAL, tra il server WebSEAL e il server diapplicazioni back-end di junction.

v Capitolo 9: Integrazione applicazioni

Questo capitolo illustra una serie di capacità WebSEAL per l’integrazione dellafunzionalità di applicazioni di terzi.

v Appendice A: Riferimento webseald.conf

v Appendice B: Riferimento junction WebSEAL

PubblicazioniIn questa sezione vengono riportate le pubblicazioni relative ad Access Manager e irelativi documenti correlati. Descrive inoltre come accedere in linea allepubblicazioni di Tivoli, come ordinarle e commentarle.

IBM Tivoli Access ManagerLa libreria di Access Manager è organizzata nelle seguenti categorie:v Informazioni sul rilasciov Informazioni di basev Informazioni su WebSEALv Informazioni sulla protezione Webv Informazioni di riferimento per gli sviluppatoriv Informazioni tecniche supplementari

Le pubblicazioni presenti nella libreria del prodotto sono incluse in formato PDF(Portable Document Format) sul CD del prodotto. Per accedere a tali pubblicazionimediante un browser Web, aprire il file infocenter.html, ubicato nella directory/doc sul CD.

Per ulteriori informazioni su Access Manager e sugli argomenti correlati, visitare iseguenti siti Web:

x IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

http://www.ibm.com/redbookshttps://www.tivoli.com/secure/support/documents/fieldguides

Informazioni sul rilasciov IBM Tivoli Access Manager per e-business - Readme

GI11-0918 (am39_readme.pdf)In questo documento vengono fornite le informazioni sull’installazione e l’avviodi Access Manager.

v IBM Tivoli Access Manager per e-business - Note sul rilascio

GI11-0919 (am39_relnotes.pdf)Fornisce informazioni aggiornate, come limitazioni di software, soluzionialternative e aggiornamenti della documentazione.

Informazioni di basev IBM Tivoli Access Manager - Guida all’installazione di base

GC32-0844 (am39_install.pdf)In questo manuale vengono riportate le procedure relative all’installazione, allaconfigurazione e all’aggiornamento del software Access Manager, compresal’interfaccia Web Portal Manager.

v IBM Tivoli Access Manager - Guida di base per il responsabile di sistema

GC13-3064 (am39_admin.pdf)Descrive i concetti e le procedure per utilizzare i servizi di Access Manager.Inoltre, fornisce istruzioni per eseguire applicazioni dall’interfaccia Web PortalManager e utilizzando il comando pdadmin.

v IBM Tivoli Access Manager Base for Linux on zSeries™ Installation Guide

GC23-4796 (am39_zinstall.pdf)In questo capitolo viene descritta la procedura per l’installazione e laconfigurazione di Access Manager Base per Linux su piattaforme zSeries.

Informazioni su WebSEALv IBM Tivoli Access Manager - Guida all’installazione di WebSEAL

GC32-0848 (amweb39_install.pdf)In questo manuale vengono fornite le istruzioni per l’installazione, laconfigurazione e la rimozione del server WebSEAL e del kit di sviluppodell’applicazione WebSEAL.

v IBM Tivoli Access Manager WebSEAL - Guida per il responsabile di sistema

GC13-3056 (amweb39_admin.pdf)Fornisce materiale supplementare, procedure di gestione e informazioni tecnichedi riferimento sull’utilizzo di WebSEAL per gestire le risorse del dominio Webprotetto.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)Fornisce informazioni sulla programmazione e la gestione di CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) e PSM (Password Strength Module).

v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation Guide

GC23-4797 (amweb39_zinstall.pdf)In questo manuale vengono fornite le istruzioni per l’installazione, laconfigurazione e la rimozione del server WebSEAL e del kit di sviluppodell’applicazione WebSEAL per Linux su piattaforme zSeries.

Prefazione xi

Informazioni sulla protezione Webv IBM Tivoli Access Manager for WebSphere Application Server - Guida per l’utente

GC13-3057 (amwas39_user.pdf)Fornisce le istruzioni relative all’installazione, la rimozione e la gestione diAccess Manager per IBM WebSphere® Application Server.

v IBM Tivoli Access Manager for WebLogic Server User’s Guide

GC32-0851 (amwls39_user.pdf)Fornisce le istruzioni relative all’installazione, la rimozione e la gestione diAccess Manager per BEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide

GC23-4685 (amedge39_user.pdf)Descrive le procedure necessarie per l’installazione, la configurazione e lagestione dei plug-in per IBM WebSphere Edge Server.

v IBM Tivoli Access Manager Plug-in for Web Servers User’s Guide

GC23-4686 (amws39_user.pdf)Fornisce le istruzioni per l’installazione, le procedure di configurazione e leinformazioni tecniche di riferimento per la protezione del dominio Webmediante i plug-in per le applicazioni dei server Web.

Riferimenti per gli sviluppatoriv IBM Tivoli Access Manager Authorization C API Developer’s Reference

GC32-0849 (am39_authC_devref.pdf)Fornisce materiale di riferimento che descrive la modalità di utilizzo dell’API Cdi autorizzazione di Access Manager e dell’interfaccia dei plug-in di servizio diAccess Manager per aggiungere la protezione alle applicazioni.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s Reference

GC23-4688 (am39_authJ_devref.pdf)Fornisce informazioni di riferimento per l’utilizzo dell’implementazione dellalingua Java™ dell’API di autorizzazione in modo da abilitare l’utilizzo dellaprotezione di Access Manager da parte di un’applicazione.

v IBM Tivoli Access Manager Administration C API Developer’s Reference

GC32-0843 (am39_adminC_devref.pdf)Fornisce informazioni di riferimento sull’uso dell’amministrazione API perabilitare un’applicazione ad eseguire le attività di gestione di Access Manager. Inquesto documento viene descritta l’implementazione C dell’API diamministrazione.

v IBM Tivoli Access Manager Administration Java Classes Developer’s Reference

SC32-0842 (am39_adminJ_devref.pdf)Fornisce informazioni di riferimento per l’utilizzo dell’implementazione dellalingua Java dell’API di amministrazione in modo da abilitare l’esecuzione diattività di Access Manager da parte di un’applicazione.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)Fornisce informazioni sulla programmazione e la gestione di CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) e PSM (Password Strength Module).

xii IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Supplementi tecniciv IBM Tivoli Access Manager Performance Tuning Guide

GC43-0846 (am39_perftune.pdf)Fornisce informazioni sulla regolazione delle prestazioni per un ambientecomposto da Access Manager con IBM SecureWay Director definito comeregistro utente.

v IBM Tivoli Access Manager Capacity Planning Guide

GC32-0847 (am39_capplan.pdf)Aiuta i progettisti a determinare il numero di server WebSEAL, LDAP e Webbackend necessari per ottenere un carico di lavoro richiesto.

v IBM Tivoli Access Manager Error Message Reference

SC32-0845 (am39_error_ref.pdf)Fornisce le spiegazioni e le azioni consigliate per i messaggi prodotti da AccessManager.

Il Glossario Tivoli comprende le definizioni di molti termini tecnici relativi alsoftware Tivoli. Il Glossario Tivoli è disponibile, soltanto in lingua inglese, sulseguente sito Web:

http://www.tivoli.com/support/documents/glossary/termsm03.htm

Pubblicazioni correlatein questa sezione vengono riportate le pubblicazioni relative alla libreria di AccessManager.

IBM DB2® Universal Database ™

IBM DB2 Universal Database è necessario per l’installazione di IBM SecureWayDirectory, server z/OS™ e OS/390® SecureWay LDAP. Le informazioni su DB2sono disponibili sul seguente sito Web:

http://www.ibm.com/software/data/db2/

IBM Global Security ToolkitAccess Manager fornisce la crittografia dei dati attraverso l’utilizzo di IBM GlobalSecurity Toolkit (GSKit). GSKit viene fornito sul CD base di IBM Tivoli AccessManager per la propria particolare piattaforma.

Il pacchetto GSKit provvede all’installazione del programma di utilità per lagestione delle chiavi iKeyman (gsk5ikm), che consente all’utente di creare databasedi chiavi, coppie di chiavi pubbliche-private e richieste di certificati. Il seguentedocumento è disponibile nella directory /doc/GSKit:v Secure Sockets Layer Introduction and iKeyman User’s Guide

gskikm5c.pdf

Fornisce informazioni per gli amministratori di rete o del sistema che desideranoabilitare la comunicazione SSL per il dominio di protezione di Access Manager.

IBM SecureWay DirectoryIBM SecureWay Directory, Versione 3.2.2, è disponibile sul CD di IBM Tivoli AccessManager Base per la particolare piattaforma. Se si desidera installare il server IBMSecureWay Directory come registro utente, i seguenti documenti sono disponibilinella directory /doc/Directory sul CD di IBM Tivoli Access Manager Base per laparticolare piattaforma:v IBM SecureWay Directory Installation and Configuration Guide

Prefazione xiii

(aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf)Fornisce informazioni sull’installazione, la configurazione e la migrazione deicomponenti di IBM SecureWay Directory su sistemi operativi AIX®, Linux,Solaris e Microsoft® Windows®.

v IBM SecureWay Directory Release Notes

(relnote.pdf)Integra la documentazione di IBM SecureWay Directory, Versione 3.2.2 e descrivele funzioni disponibili in questo rilascio.

v IBM SecureWay Directory Readme Addendum

(addendum322.pdf)Fornisce informazioni sulle modifiche e le correzioni che si sono verificate inseguito alla traduzione della documentazione di IBM SecureWay Directory.Questo file è disponibile soltanto in lingua inglese.

v IBM SecureWay Directory Server Readme

(server.pdf)Fornisce una descrizione del server IBM SecureWay Directory, Versione 3.2.2.

v IBM SecureWay Directory Client Readme

(client.pdf)Fornisce una descrizione del client IBM SecureWay Directory SDK, Versione3.2.2. Questo kit di sviluppo software (SDK) fornisce un supporto di sviluppodell’applicazione LDAP.

v SSL Introduction and iKeyman User’s Guide

(gskikm5c.pdf)Fornisce informazioni per gli amministratori di rete o del sistema che desideranoabilitare la comunicazione SSL per il dominio di protezione di Access Manager.

v IBM SecureWay Directory Configuration Schema

(scparent.pdf)Descrive il DIT (directory information tree) e gli attributi utilizzati perconfigurare il file slapd32.conf. In IBM SecureWay Directory Versione 3.2, leimpostazioni delle directory vengono memorizzate utilizzando LDAP DirectoryInterchange Format (LDIF) nel file slapd32.conf.

v IBM SecureWay Directory Tuning Guide

(tuning.pdf)Fornisce le informazioni sulla regolazione delle prestazioni per IBM SecureWayDirectory. La regolazione delle considerazioni per l’intervallo delle dimensionidella directory possono variare da poche migliaia a milioni di voci.

Per ulteriori informazioni su IBM SecureWay Directory, consultare il seguente sitoWeb:

http://www.software.ibm.com/network/directory/library/

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition, Versione 4.0.2,è installato con l’interfaccia del gestore di portale Web. Per ulteriori informazionisu IBM WebSphere Application Server, visitare il seguente sito Web:

http://www.ibm.com/software/webservers/appserv/infocenter.html

xiv IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Accesso alle pubblicazioni in lineaLe pubblicazioni presenti nelle librerie del prodotto sono disponibili in formatoPDF (Portable Document Format) sul CD del prodotto. Per accedere a talipubblicazioni mediante un browser Web, aprire il file infocenter.html, ubicatonella directory /doc sul CD.

Se viene pubblicata una versione aggiornata di una o più pubblicazioni in linea oin copia stampata, tali aggiornamenti vengono inviati a Tivoli Information Center.Tivoli Information Center contiene le versioni più recenti delle pubblicazionipresenti nella libreria del prodotto in formato PDF, HTML o entrambi. Inoltre, peralcuni prodotti, è possibile trovare la documentazione tradotta.

E’ possibile accedere a Tivoli Information Center e ad altre fonti di informazionitecniche da sito Web riportato di seguito:

http://www.tivoli.com/support/documents/

Le informazioni, comprese le note sul rilascio, le guide all’installazione, le guideper l’utente, le guide per i responsabili di sistema e i riferimenti per glisviluppatori, sono organizzate per prodotto.

Nota: Se si stampa un qualsiasi documento PDF in un formato della carta diversodal formato lettera standard, selezionare la casella di spunta Adatta allapagina nella finestra di dialogo di stampa di Adobe Acrobat (visualizzataselezionando File → Stampa) in modo da ssicurarsi che le dimensioni letteradella pagina vengano stampate sulla carta che si sta utilizzando.

Ordinare le pubblicazioniE’ possibile ordinare molte pubblicazioni di Tivoli in linea dal seguente sito Web:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

E’ possibile ordinare per telefono chiamando uno di questi numeri:v Negli Stati Uniti: 800-879-2755v In Canada: 800-426-4968v Per gli altri paesi, consultare l’elenco di numeri di telefono sul seguente sito

Web:http://www.tivoli.com/inside/store/lit_order.html

Commenti sulle pubblicazioniE’ molto importante conoscere quali siano state le esperienze degli utenti con ladocumentazione e i prodotti Tivoli e sono pertanto graditi tutti i suggerimentiforniti per un eventuale miglioramento dei servizi. Se si desidera esprimere deicommenti o fornire dei suggerimenti relativi alle pubblicazioni o ai prodotti,mettersi in contatto in uno dei seguenti modi:v Mandare una e-mail a [email protected] Completare il sondaggio di feedback del cliente sul seguente sito Web:

http://www.tivoli.com/support/survey/

Prefazione xv

AccessibilitàLe funzioni di accessibilità consentono a un utente disabile, che ad esempio ha unamobilità limitata o problemi di vista, di utilizzare correttamente i prodotti software.Con questo prodotto, è possibile utilizzare le tecnologie aggiuntive per poterascoltare ed esplorare l’interfaccia. E’ inoltre possibile utilizzare la tastiera al postodel mouse in modo da sfruttare tutte le funzioni dell’interfaccia grafica utente.

Contattare il servizio di assistenza ai clientiSe si hanno problemi con qualche prodotto Tivoli, è possibile contattare TivoliCustomer Support. Consultare il Tivoli Customer Support Handbook sul seguente sitoWeb:

http://www.tivoli.com/support/handbook/

Il manuale fornisce le informazioni per contattare Tivoli Customer Supportsecondo la gravità del problema e le seguenti informazioni:v Registrazione ed eleggibilitàv Numeri di telefono e indirizzi e-mail, a sdeconda del paese di appartenenzav Tipo di informazioni da procurarsi prima di contattare il supporto

Convenzioni utilizzate in questo manualeIn questo manuale vengono utilizzate diverse convenzioni per termini ed azionispeciali, per percorsi e comandi dipendenti da sistemi operativi e per i grafici.

Convenzioni tipograficheIn questo libro sono utilizzate le seguenti convenzioni tipografiche:

Grassetto Opzioni e nomi di comandi, parole chiave e altre informazioni chedevono essere utilizzate letteralmente vengono visualizzate ingrassetto.

Corsivo Variabili, opzioni e valori di comandi che devono essere inseritivengono visualizzati in corsivo. I titoli delle pubblicazioni e paroleo frasi speciali che devono essere enfatizzate vengono visualizzatein corsivo.

Spaziatura fissaEsempi di codice, righe comandi, output dello schermo, nomi difile e directory e messaggi di sistema vengono visualizzati con ilfont monospace.

xvi IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Capitolo 1. Panoramica su IBM Tivoli Access ManagerWebSEAL

IBM®Tivoli®Access Manager per e-business (Access Manager) rappresenta unasoluzione centralizzata e sicura per la gestione di criteri per applicazioni e-businesse distribuite. IBM Tivoli Access Manager WebSEAL è un server Web multi-threadad alte prestazioni che applica criteri di elevata protezione allo spazio oggetti Webprotetto di Access Manager. E’ in grado di fornire singole soluzioni di registrazionee incorporare le risorse di server delle applicazioni Web back-end nei propri criteridi protezione.

Questa panoramica introduce le capacità principali del server WebSEAL.

Indice degli argomenti:v “Introduzione a IBM Tivoli Access Manager e WebSEAL” a pagina 1v “Comprensione del modello di protezione di Access Manager” a pagina 3v “Protezione dello spazio Web con WebSEAL” a pagina 6v “Pianificazione e implementazione dei criteri di protezione” a pagina 8v “Comprensione della configurazione WebSEAL” a pagina 9v “Comprensione dei junction WebSEAL” a pagina 13

Introduzione a IBM Tivoli Access Manager e WebSEALIBM Tivoli Access Manager:

Access Manager rappresenta una soluzione completa per la gestione dei criteri diprotezione di rete e delle autorizzazioni che fornisce una protezione delle risorsegeograficamente disperse in reti interne ed esterne.

Oltre alla funzione di gestione dei criteri di protezione propri, Access Managerfornisce capacità di autenticazione, autorizzazione, protezione dei dati e gestionecentralizzata delle risorse. Access Manager viene utilizzato insieme ad applicazionistandard su base Internet per creare reti interne gestite in modo ottimale e con unelevato livello di protezione.

Access Manager fornisce:v Struttura di autenticazione

Access Manager fornisce un’ampia gamma di programmi di autenticazioneincorporati e supporta programmi di autenticazione esterni.

v Struttura di autorizzazioneIl servizio di autorizzazione Access Manager, a cui si accede attraverso l’API diautorizzazione Access Manager, fornisce l’accettazione o il rifiuto di richieste perl’accesso a risorse protette ubicate sul dominio protetto.

Con Access Manager, i responsabili commerciali possono gestire con sicurezzal’accesso a risorse interne private basate sulla rete, diminuendo il carico diconnettività di Internet e semplificando l’utilizzo. Access Manager, in combinazionecon un sistema di firewall aziendale, è in grado di proteggere completamente larete locale dell’impresa da accessi e intrusioni non autorizzati.

© Copyright IBM Corp. 1999, 2002 1

IBM Tivoli Access Manager WebSEAL:

IBM Tivoli Access Manager WebSEAL è il gestore risorse responsabile dellagestione e della protezione di informazioni e risorse basate sul Web.

WebSEAL è un server Web multi-thread ad alte prestazioni che applica criteri dielevata protezione allo spazio oggetti Web protetto di Access Manager. Esso puòfornire soluzioni single sign-on e incorporare le risorse del server di back-end diapplicazioni Web nei propri criteri di protezione.

WebSEAL opera generalmente come un proxy Web opposto, ricevendo richiesteHTTP/HTTPS da un browser Web e distribuendo il contenuto dal proprio serverWeb o da server back-end di junction di applicazioni Web. Le richieste trasmesseattraverso WebSEAL vengono valutate dal servizio di autorizzazione di AccessManager per determinare se l’utente è autorizzato ad accedere alla risorsa richiesta.

WebSEAL offre le seguenti caratteristiche:v Supporta metodi di autenticazione multipli

Entrambe le architetture incorporata e plug-in consentono la flessibilità nelsupporto di una serie di meccanismi di autenticazione.

v Accetta richieste HTTP e HTTPSv Integra e protegge risorse di server back-end attraverso la tecnologia junction di

WebSEALv Gestisce il controllo dell’accesso approfondito per lo spazio Web del server locale

e di back-endLe risorse supportate comprendono URL, espressioni regolari basate su URL,programmi CGI, file HTML, servlet Java e file di classi Java.

v Viene eseguito come proxy Web oppostoWebSEAL appare come server Web ai client e come browser Web ai server diback-end di junction di cui effettua la protezione.

v Fornisce capacità di collegamento singolo (single sign-on)

Client WebSEAL

Supporta più metodi di autenticazioneIntegra i servizi di autorizzazione di Access ManagerGestisce il controllo di primo livello delle risorse WebGestisce una varietà di tipi di risorseIncorpora e protegge risorse dei server di back-endUnifica lo spazio delle risorse Web protettoFornisce soluzioni SSO (single sign-on)

autenticazi one

WebapplicazioniServer delle

/

Spazio oggettiWeb protetto

Nodo W ebSEAL

Figura 1. Protezione dello spazio Web attraverso WebSEAL

2 IBM Tivoli Access Manager: Guida per il responsabile di sistema WebSEAL

Comprensione del modello di protezione di Access ManagerIl criterio di protezione per un dominio protetto Access Manager viene mantenutoe governato mediante due strutture di sicurezza chiave:v Registro utenti

Il registro utenti (LDAP, Lotus Domino o Microsoft Active Directory) contienetutti gli utenti e i gruppi a cui è concesso di partecipare al dominio protettoAccess Manager.

v Database di autorizzazione (criterio) principale

Il database di autorizzazione contiene una rappresentazione di tutte le risorsedel dominio (lo spazio oggetti protetti). Il responsabile della sicurezza puòimporre qualsiasi livello di protezione applicando regole, conosciute come criteriaccess control list (ACL) e protected object policies (POP), a quelle risorse cherichiedono una protezione.

L’identità di un utente viene dimostrata a WebSEAL attraverso il processo diautenticazione. Un utente può partecipare ad un dominio protetto come autenticatoo non autenticato. Solo gli utenti che dispongono di una voce nel registro utentipossono diventare utenti autenticati. Mediante l’utilizzo di ACL e POP, ilresponsabile della sicurezza può rendere determinate risorse pubbliche disponibiliagli utenti non autenticati. Altre risorse possono essere rese disponibili solo adeterminati utenti autenticati.

Quando un utente effettua correttamente l’autenticazione presso WebSEAL, vienecreata una credenziale per tale utente. La credenziale contiene l’identità dell’utente,qualsiasi appartenenza a gruppi e qualsiasi attributo di protezione speciale(“esteso”).

Il servizio di autorizzazione di Access Manager applica i criteri di protezioneconfrontando le credenziali di autenticazione di un utente con le autorizzazioni deicriteri assegnate alla risorsa richiesta. La risultante raccomandazione vienetrasmessa al gestore risorse (ad esempio, WebSEAL) che completa la risposta allarichiesta originale. La credenziale dell’utente è essenziale per la pienapartecipazione al dominio protetto.

Lo spazio oggetti protettiLo spazio oggetti protetti è una rappresentazione gerarchica delle risorseappartenenti a un dominio protetto Access Manager. Gli oggetti virtuali cheappaiono nella rappresentazione gerarchica dello spazio oggetti rappresentano leeffettive risorse fisiche della rete.v Risorsa di sistema – il file o l’applicazione fisica effettiva.v Oggetto protetto – la rappresentazione logica di una reale risorsa del sistema

utilizzata dal servizio di autorizzazione, dal gestore di portale Web e da altriprogrammi di utilità di gestione Access Manager.

Maschere di criteri possono essere collegate agli oggetti nello spazio oggetti inmodo da offrire protezione alle risorse. Il servizio di autorizzazione prendedecisioni di autorizzazione in base a queste maschere.

Le seguenti categorie di spazio oggetti sono utilizzate da Access Manager:v Oggetti Web

Questi oggetti rappresentano qualsiasi elemento che può essere indirizzato da unURL HTTP. Ciò include pagine Web statiche e URL dinamici che vengono

Capitolo 1. Panoramica su IBM Tivoli Access Manager WebSEAL 3

convertiti in query di database o altro tipo di applicazione. Il server WebSEAL èresponsabile per la protezione degli oggetti Web.

v Oggetti di gestione Access Manager

Questi oggetti rappresentano le attività di gestione che possono essere eseguiteattraverso il gestore di portale Web. Gli oggetti rappresentano le attivitànecessarie per definire utenti e impostare criteri di protezione. Access Managersupporta la delega di attività di gestione e può limitare la capacità di unresponsabile di impostare criteri di protezione in un sottoinsieme dello spaziooggetti.

v Oggetti definiti dall’utente

Questi oggetti rappresentano attività definite dai clienti o risorse di rete protetteda applicazioni mediante il servizio di autorizzazione attraverso l’API diautorizzazione di Access Manager.

Definizione e applicazione di criteri ACL e POPI responsabili della sicurezza proteggono le risorse di sistema Access Managerdefinendo regole, conosciute come criteri ACL e POP, e applicando tali criteri allerappresentazioni di oggetto di queste risorse nello spazio oggetti protetti.

Il servizio di autorizzazione Access Manager prende decisioni di autorizzazione inbase ai criteri applicati a tali oggetti. Quando un’operazione richiesta su un oggettoprotetto viene permessa, l’applicazione responsabile della risorsa implementa taleoperazione.

Un solo criterio può imporre i parametri di protezione di molti oggetti. Ognimodifica alla regola influenzerà tutti gli oggetti a cui la maschera è collegata.

ACL (access control list)Un criterio access control list, o criterio ACL, è l’insieme di regole (autorizzazioni)che specifica le condizioni necessarie per eseguire determinate operazioni su unarisorsa. Le definizioni di criterio ACL sono componenti importanti del criterio disicurezza stabilito per il dominio protetto. I criteri ACL, come tutti i criteri,vengono utilizzati per inserire requisiti di protezione di un’organizzazione nellerisorse rappresentate nello spazio oggetti protetti.

Un criterio ACL controlla in modo specifico:1. Quali operazioni possono essere eseguite sulla risorsa2. Chi può eseguire tali operazioni

Oggettidi gestione

OggettiWeb

Oggettidefiniti dagli utenti

Figura 2. Spazio oggetti protetti di Access Manager


Un criterio ACL è composto da una o più voci che comprendono designazioni diutenti e gruppi e i relativi permessi o diritti specifici. Un ACL può anche contenereregole che si applicano ad utenti non autenticati.

POP (protected object policies)I criteri ACL forniscono al servizio di autorizzazione le informazioni perrispondere “sì” o “no” ad una richiesta di accesso a un oggetto protetto pereseguire su tale oggetto alcune operazioni.

I criteri POP contengono condizioni aggiuntive sulla richiesta che viene restituita aAccess Manager Base e al gestore risorse (ad es. WebSEAL) insieme alla risposta“sì” del criterio ACL proveniente dal servizio di autorizzazione. E’ responsabilitàdi Access Manager e del gestore risorse di rafforzare le condizioni POP.

Le tabelle seguenti elencano gli attributi disponibili per un POP:

Applicato da Access Manager Base

Attributo POP Descrizione

Nome Il nome del criterio. Diventa <pop-name> nei comandipdadmin pop.

Descrizione Testo descrittivo del criterio. Appare nel comando popshow.

Modalità di avvertenza Fornisce ai responsabili un modo per verificare criteriACL e POP.

Livello di audit Specifica il tipo di audit: all, none, successful access,denied access, errors.

Accesso ora del giorno Limitazioni di giorno e ora per un corretto accessoall’oggetto protetto.

Applicato dal gestore risorse (ad es. WebSEAL)

Attributo POP Descrizione

QOP (Quality of Protection) Specifica il grado di protezione dei dati: none, integrity,privacy.

Criterio metodo diautenticazione endpoint IP

Specifica i requisiti di autenticazione per l’accesso daparte di membri di reti esterne.

Criterio esplicito e ereditatoIl criterio può essere applicato esplicitamente oppure ereditato. Lo spazio oggettiprotetti di Access Manager supporta l’ereditarietà degli attributi di criterio ACL e

utente peter ---------T---rx

gruppo engineer ing ---------T---rx

utente m ichael ---------T---rx

Non autenticat o ---------------

ACL(cont enent e più voci )

Figura 3. Criterio ACL


POP. Questa è un’importante considerazione per il responsabile della sicurezza chegestisce lo spazio oggetti. Il responsabile deve solo applicare criteri espliciti suipunti della gerarchia in cui è necessario modificare le regole.

Gestione del criterio: Il gestore di portale WebIl gestore di portale Web è un’applicazione grafica basata sul Web utilizzata pergestire criteri di protezione in un dominio protetto Access Manager. Il programmadi utilità di riga comandi pdadmin fornisce le stesse capacità di amministrazionedel gestore di portale Web, oltre ad alcuni comandi non supportati da quest’ultimo.

Dal gestore di portale Web (o pdadmin), è possibile gestire il registro utenti, ildatabase dei criteri di autorizzazione principale e i server Access Manager. E’anche possibile aggiungere ed eliminare utenti/gruppi ed applicare criteri ACL ePOP ad oggetti di rete.

Protezione dello spazio Web con WebSEALQuando WebSEAL applica la sicurezza di un dominio protetto, ogni client devefornire la prova della propria identità. A turno, i criteri di protezione AccessManager determinano se tale client ha il permesso per eseguire un’operazione suuna risorsa richiesta. Poiché l’accesso a qualsiasi risorsa Web in un dominioprotetto è controllato da WebSEAL, le esigenze di WebSEAL riguardo adautenticazione e autorizzazione possono fornire una sicurezza di rete completa.

In sistemi protetti, l’autorizzazione è distinta dall’autenticazione. L’autorizzazionedetermina se un client autenticato ha il diritto di eseguire un’operazione su unaspecifica risorsa in un dominio protetto. L’autenticazione può convalidare l’identitàdi un client, ma non interviene riguardo ai diritti del client di eseguire operazionisu una risorsa protetta.

Nel modello di autorizzazione di Access Manager, il criterio di autorizzazioneviene implementato indipendentemente dal meccanismo utilizzato perl’autenticazione utente. Gli utenti possono autenticare la propria identitàutilizzando chiavi pubbliche/private, chiavi segrete o meccanismi personalizzati.

Parte del processo di autenticazione comprende la creazione di una credenziale chedescrive l’identità del client. Le decisioni di autorizzazione prese da un servizio diautorizzazione si basano sulle credenziali dell’utente.

Oggettidi gestione

OggettiWeb

Oggettidefiniti dagli utenti

Regola esplicita

Regolaereditata

Figura 4. Criteri espliciti e ereditati


Le risorse in un dominio protetto ricevono un livello di protezione come impostodal criterio di protezione per il dominio. Il criterio di protezione definisce ipartecipanti legittimi del dominio protetto e il grado di protezione da applicare aciascuna risorsa che la richiede.

Il processo di autorizzazione è formato dai seguenti componenti base:v Un gestore risorse è responsabile dell’implementazione dell’operazione richiesta

quando viene concessa l’autorizzazione. WebSEAL è un gestore risorse.Un componente del gestore risorse è un enforcer dei criteri che indirizza larichiesta al servizio di autorizzazione per l’elaborazione.

Nota: Le applicazioni tradizionali uniscono l’enforcer dei criteri e il gestorerisorse in un unico processo. Esempi di questa struttura comprendonoWebSEAL e applicazioni di terzi.

v Un servizio di autorizzazione esegue l’azione di presa della decisiva sullarichiesta.

Il seguente diagramma illustra il processo di autorizzazione completo:

1. Una richiesta di risorsa da parte di un client autenticato viene diretta al gestorerisorse ed intercettata dal processo dell’enforcer dei criteri.Il gestore risorse può essere WebSEAL (per l’accesso HTTP o HTTPS) oppureun’applicazione di terzi.

2. Il processo dell’enforcer dei criteri utilizza l’API di autorizzazione AccessManager per chiamare il servizio di autorizzazione ed ottenere una decisione.

3. Il servizio di autorizzazione esegue un controllo sulla risorsa, rappresentatacome oggetto nello spazio oggetti protetti. Per prima cosa vengono controllati icriteri POP. Quindi, il criterio ACL collegato all’oggetto viene controllatorispetto alle credenziali del client. Successivamente, vengono verificati i criteriPOP rafforzati dal gestore risorse.

4. La decisione di accettare o rifiutare la richiesta viene restituita comeraccomandazione al gestore risorse (via enforcer dei criteri).

Client

Servizio diautorizzazione

Dominio protetto

Criterioautorizzazione

Spazio oggettiprotetto

2. Richiestaautorizzazione(APIautorizzazione)

5. Operazioneautorizzata

1. Richiesta

6. Risposta

3. Controlloautorizzazione

4. Decisioneautorizzazione(API autorizzazione)

Risorse

/

Responsabiledelle risorse

Programmaapplicazione

criteri

Figura 5. Processo di autorizzazione di Access Manager


5. Se viene finalmente approvata, il gestore risorse trasmette la richiestaall’applicazione responsabile per la risorsa.

6. Il client riceve il risultato dell’operazione richiesta.

Pianificazione e implementazione dei criteri di protezioneUn criterio di protezione costituito identifica:1. Le risorse Web che richiedono protezione2. Il livello di protezione

Access Manager utilizza una rappresentazione virtuale di queste risorse Web,denominata spazio oggetti protetti. Lo spazio oggetti protetti contiene oggetti cherappresentano risorse fisiche effettivamente presenti nella propria rete.

L’utente implementa il criterio di protezione applicando i meccanismi diprotezione adatti agli oggetti che richiedono protezione.

I meccanismi di protezione comprendono:v Criteri ACL (access control list)

I criteri ACL identificano i tipi di utente che è possibile considerare per l’accessoe specificano le operazioni consentite sull’oggetto.

v POP (protected object policies)Un POP specifica condizioni supplementari che governano l’accesso all’oggettoprotetto, quali la privacy, l’integrità, l’auditing e l’accesso ad ora del giornostabilita.

v Attributi estesiGli attributi estesi sono valori supplementari inseriti in un oggetto, un ACL o unPOP che possono essere letti ed interpretati da applicazioni di terzi (ad esempio,un servizio di autorizzazione esterno).

Il componente fondamentale di Access Manager è il servizio di autorizzazioneAccess Manager, che permette o rifiuta l’accesso agli oggetti protetti (risorse) inbase alle credenziali dell’utente e ai controlli dell’accesso sistemati sugli oggetti.

Per implementare correttamente il criterio di protezione, è necessario organizzarein modo logico i differenti tipi di contenuto (come descritto in “Identificazione deitipi di contenuto e livelli di protezione” a pagina 8) ed applicare i criteri ACL ePOP adatti. La gestione del controllo dell’accesso può essere molto complessa eviene semplificata organizzando in categorie i tipi di contenuto.

Identificazione dei tipi di contenuto e livelli di protezioneIn qualità di responsabile della sicurezza del proprio spazio Web, l’utente deveidentificare correttamente i tipi di contenuto disponibili in un’ampia varietà di tipidell’utente. Alcuni contenuti possono essere altamente protetti e disponibili solo adutenti specifici; altri contenuti sono destinati a una visualizzazione pubblicagenerale. Ciascuno scenario di protezione richiede specifiche di protezione diversee la relativa configurazione WebSEAL adatta.

E’ responsabilità dell’utente:v Conoscere il proprio contenuto Webv Identificare i tipi di utenti che richiedono accesso a tale contenuto


v Comprendere i punti deboli e i punti forti delle opzioni di configurazioneWebSEAL disponibili in modo da proteggerne il contenuto

La protezione del contenuto Web ricade in tre ampie categorie:1. Contenuto pubblico – l’accesso non richiede protezionev Accesso di client non autenticati via HTTPv Credenziale non autenticata utilizzata per il controllo dell’accesso sulle

risorsev Requisiti base di configurazione WebSEAL

2. Contenuto pubblico – l’accesso richiede privacy (codifica)v Accesso di client non autenticati via HTTPSv Crittografia necessaria per proteggere dati sensibili richiesta dal server di

applicazione (per numeri di carte di credito e informazioni di account utente)v Credenziale non autenticata utilizzata per il controllo dell’accesso sulle

risorsev La configurazione WebSEAL deve esigere la privacy

3. Contenuto privato – l’accesso richiede l’autenticazionev Accesso di client autenticati via HTTP o HTTPSv Il responsabile determina la necessità di codificav Credenziale autenticata utilizzata per il controllo dell’accesso sulle risorse; i

client devono avere l’account definito nel registro utentiv La configurazione WebSEAL è complessa e tutte le opzioni devono essere

attentamente considerate per determinare l’impatto del criterio di protezione

Comprensione della configurazione WebSEALL’autenticazione è un metodo di identificazione di un singolo processo o entità chesta tentando di collegarsi a un dominio protetto. Quando sia il server che il clientrichiedono l’autenticazione, tale scambio è conosciuto come autenticazionereciproca.

WebSEAL può applicare un elevato grado di protezione in un dominio protettorichiedendo ad ogni client di fornire la prova della propria identità.

Le seguenti condizioni si applicano all’autenticazione WebSEAL:v WebSEAL supporta una serie standard di metodi di autenticazione.

E’ possibile personalizzare WebSEAL per il supporto di altri metodi diautenticazione.

Client WebSEAL

Chi sei?

Chi sei?

Figura 6. Autenticazione reciproca


v Il processo del server WebSEAL è indipendente dal metodo di autenticazione.v WebSEAL richiede esclusivamente un’identità del client. Da questa identità,

WebSEAL crea una credenziale autenticata (o non autenticata) che può essereutilizzata dal servizio di autorizzazione Access Manager per autorizzare orifiutare l’accesso alle risorse.

Questo approccio flessibile di autenticazione consente al criterio di protezione diessere basato su requisiti commerciali e non sulla topologia fisica della rete.

Obiettivi dell’autenticazioneSebbene sia indipendente dal processo di autenticazione, WebSEAL ne richiede irisultati, cioé l’identità del client. Il processo di autenticazione deriva dalle seguentiazioni:1. Il metodo di autenticazione determina un’identità del client

L’autenticazione del client riesce solo se l’utente dispone di un account definitonel registro utenti di Access Manager oppure se viene elaborato con esitopositivo da un CDAS. Diversamente, l’utente viene designato come Nonautenticato.Le informazioni di identità specifiche del metodo, quali password, token ecertificati, rappresentano proprietà di identità fisiche dell’utente. Questeinformazioni possono essere utilizzate per stabilire una sessione protetta con ilserver.

2. WebSEAL utilizza l’identità per acquisire credenziali per tale client.WebSEAL collega l’identità client ad un utente registrato di Access Manager.WebSEAL, quindi, crea le credenziali adatte per questo utente. Questaoperazione è conosciuta come acquisizione delle credenziali.La credenziale rappresenta i privilegi di un utente nel dominio protetto,descrive l’utente in un contesto specifico ed è valida solo per la durata di talesessione. I dati di credenziale includono il nome utente, qualsiasi appartenenzaa gruppi e qualsiasi attributo “esteso” di protezione speciale.Se un utente non è membro del registro utenti (“anonymous”), WebSEAL creaper lui una credenziale non autenticata. Ricordare che un ACL può contenereregole speciali che governano gli utenti non autenticati.Tali credenziali sono disponibili al servizio di autorizzazione che permette orifiuta l’accesso a oggetti richiesti nello spazio oggetti protetti di WebSEAL.

Le credenziali possono essere utilizzate da qualsiasi servizio Access Manager cherichiede informazioni sul client. Le credenziali consentono a Access Manager dieseguire in modo sicuro una moltitudine di servizi quali autorizzazione, auditing edelega.

Access Manager distingue l’autenticazione dell’utente dall’acquisizione dellecredenziali. L’identità di un utente è sempre costante. Tuttavia le credenziali, chedefiniscono i gruppi o i ruoli ai quali l’utente partecipa, sono variabili. Lecredenziali specifiche per il contesto possono cambiare nel tempo. Ad esempio,quando una persona viene promossa, le credenziali devono riflettere il nuovolivello di responsabilità.

Per ulteriori informazioni sul supporto di metodi specifici di autenticazione, fareriferimento Capitolo 5, “Autenticazione WebSEAL” a pagina 101.


Accesso autenticato e non autenticato alle risorseIn un ambiente di dominio protetto Access Manager, l’identità di un utente vienedimostrata a WebSEAL attraverso il processo di autenticazione. In generale, unutente può partecipare ad un dominio protetto come autenticato o non autenticato.

In entrambi i casi, il servizio di autorizzazione Access Manager richiede unacredenziale utente per prendere decisioni di autorizzazione sulle richieste di risorsein un dominio protetto. WebSEAL gestisce le credenziali dell’utente autenticato inmodo diverso da quelle dell’utente non autenticato.

Le credenziali per un utente non autenticato sono semplicemente un passaportogenerico che consente all’utente di partecipare ad un dominio protetto ed accederealle risorse disponibili per utenti non autenticati.

La credenziale per un utente autenticato è un passaporto unico che descrive unutente specifico appartenente al registro utenti di Access Manager (o elaborato conesito positivo attraverso un CDAS). La credenziale dell’utente autenticato contienel’identità dell’utente, qualsiasi appartenenza a gruppi e qualsiasi attributo diprotezione speciale (“esteso”).

Il flusso di processo per utenti autenticati:v Un utente effettua una richiesta per una risorsa protetta da WebSEAL. La

protezione sulla risorsa richiede che l’utente sia autenticato. WebSEAL richiedeall’utente di collegarsi.

v Una corretta autenticazione può verificarsi solo se l’utente è membro del registroutenti di Access Manager oppure è gestito da un’operazione CDAS.

v Un ID sessione WebSEAL viene creato per l’utente.v Una credenziale per tale utente viene creata dalle rispettive informazioni

contenute nel registro (ad es. appartenenze a gruppi).v L’ID sessione e la credenziale, più altri dati, vengono memorizzati come voce

nella cache di sessione/credenziali WebSEAL.v Mentre WebSEAL elabora questa richiesta (e le future richieste durante questa

sessione), rileva le informazioni di credenziale disponibili.v Ogni volta che viene richiesto un controllo dell’autorizzazione, il servizio di

autorizzazione Access Manager utilizza le informazioni di credenziale durante ilprocesso decisionale.

v Quando l’utente si scollega, la rispettiva voce della cache viene rimossa e lasessione viene terminata.

Il flusso di processo per utenti non autenticati:v Un utente effettua una richiesta per una risorsa protetta da WebSEAL. La

protezione sulla risorsa non richiede che l’utente sia autenticato. WebSEAL nonrichiede all’utente di collegarsi.

v WebSEAL crea una credenziale non autenticata per l’utente.v Nessuna voce viene creata nella cache di sessione/credenziali WebSEAL.v L’utente può accedere a risorse che contengono le autorizzazioni corrette per

una categoria di tipo non autenticato di utente.v Se l’utente richiede l’accesso a una risorsa non disponibile per utenti non

autenticati, WebSEAL richiede all’utente di effettuare il collegamento.v Un collegamento riuscito determina la modifica dello stato dell’utente in

Autenticato.


v Se il collegamento non riesce, viene restituito un messaggio 403 “Accessovietato”. L’utente può ancora continuare ad accedere alle altre risorse disponibiliper gli utenti non autenticati.

Struttura della cache sessione/credenziali WebSEALLa cache di sessione WebSEAL è anche conosciuta come cache di credenzialiWebSEAL. La cache può essere rappresentata come una tabella interna in cuiWebSEAL memorizza informazioni relative a tutte le sessioni stabilite da utentiautenticati.

Ogni sessione utente è rappresentata da una voce nella tabella cache.

Ogni voce di cache contiene i seguenti tipi di informazioni:v ID sessione

L’ID sessione è un identificativo univoco che viene inviato con ogni richiestaeffettuata da un determinato utente. L’ID sessione identifica la specifica voce dicache per tale utente.

v Dati della cache

Il più importante dato memorizzato nella voce di cache è la credenzialedell’utente. La credenziale è richiesta ogni volta che l’utente richiede risorseprotette. Il servizio di autorizzazione utilizza i dati della credenziale perpermettere o rifiutare l’accesso alla risorsa.WebSEAL può contrassegnare, o “indicare”, una voce di cache per il supporto dideterminate funzionalità. Ad esempio, quando la ri-autenticazione inattività disessione è abilitata, la voce di cache viene “contrassegnata” nel momento in cuiil valore dell’inattività di sessione scade.

v Timestamp

Il timestamp di creazione per la voce di cache diventa il punto di riferimentoper il valore di durata della sessione. Il timestamp di “ultima attività” per lavoce di cache diventa il punto di riferimento per il timer di inattività dellasessione.

La credenziale dell’utente contiene:v Nome utentev Appartenenze a gruppiv Attributi estesi

Cache sessione/credenziali WebSEAL

ID sessione Dati cache Formati orari

1234credenziali utenteindicatori internidati interni

ora di creazioneora ultimaattivazione

vocecache

Figura 7. Cache di sessione/credenziali WebSEAL


Gli attributi estesi consentono di memorizzare dati personalizzati nellacredenziale dell’utente. Un esempio di attributo esteso della credenziale ètagvalue_user_session_id. Il valore di questo attributo può essere inserito inun’intestazione HTTP per consentire a un server back-end di junction dimantenere lo stato di sessione con l’utente.

Comprensione dei junction WebSEALAccess Manager fornisce servizi di autorizzazione, autenticazione e gestione peruna rete. In una rete basata sul Web, questi servizi sono forniti in modo ancoramigliore da uno o più server front-end WebSEAL che integrano e proteggono lerisorse e le applicazioni Web ubicate su server Web back-end.

La connessione tra un server WebSEAL e il server di applicazioni back-end Web èconosciuta come junction WebSEAL, oppure junction. Un junction WebSEAL è unaconnessione TCP/IP tra un server front-end WebSEAL e un server back-end.

Il server back-end può essere un altro server WebSEAL oppure, più comunemente,un server di applicazioni Web di terzi. Lo spazio Web del server back-end è“connesso” al server WebSEAL su un punto di junction (montaggio), progettato inmodo speciale, nello spazio Web di WebSEAL.

Un junction consente a WebSEAL di fornire servizi di protezione per parte delserver back-end. WebSEAL può eseguire controlli di autenticazione eautorizzazione su tutte le richieste prima di trasmettere tali richieste al serverback-end. Se il server back-end richiede un controllo dell’accesso approfondito suipropri oggetti, è necessario eseguire passi di configurazione supplementari perdescrivere lo spazio Web di terzi al servizio di protezione di Access Manager(vedere “Utilizzo di query_contents con server di terzi” a pagina 179).

I junction forniscono un ambiente protetto e scalabile che consente bilanciamentodel carico, elevata disponibilità e capacità di gestione dello stato, tutto eseguitovisibilmente per i client. Come responsabile, l’utente può beneficiare da questagestione centralizzata dello spazio Web.

I junction WebSEAL forniscono il valore aggiunto della combinazione logica dellospazio Web di un server back-end con lo spazio Web del server WebSEAL. Ijunction tra server di cooperazione creano un singolo spazio Web unificato edistribuito, perfettamente ed uniformemente visibile agli utenti.

ClientWeb

applicazioniServer delle

nodo

TCP o SSL

WebSEAL/

/mnt

Dominio protetto

Figura 8. Connessione di WebSEAL e server back-end mediante junction


Il client non ha mai la necessità di conoscere l’ubicazione fisica di una risorsa Web.WebSEAL traduce indirizzi URL logici negli indirizzi fisici previsti da un serverback-end. Gli oggetti Web possono essere spostati da server a server, senzainfluenzare il modo in cui il client accede a tali oggetti.

Uno spazio Web unificato semplifica la gestione di tutte le risorse da parte delresponsabile di sistema. Ulteriori vantaggi di gestione comprendono la scalabilità,il bilanciamento del carico e l’elevata disponibilità.

La maggior parte dei server Web commerciali non dispongono della capacità didefinire uno spazio oggetti Web logico. Al contrario, il loro controllo dell’accesso ècollegato alla struttura fisica di directory e file. I junction WebSEAL sono in gradodi definire in modo trasparente uno spazio oggetti che riflette la strutturaorganizzativa anziché la macchina fisica e la struttura di directory comunementepresente su server Web standard.

I junction WebSEAL consentono anche di creare soluzioni di collegamento singolo(SSO - single sign-on). Una configurazione single sign-on consente ad un utente diaccedere a una risorsa, indipendentemente dall’ubicazione della risorsa, utilizzandoun solo login iniziale. Qualsiasi ulteriore requisito di login dai server back-endviene gestito in modo visibile all’utente.

I junction WebSEAL rappresentano uno strumento importante per rendere scalabileil proprio sito Web. I junction permettono di rispondere all’incremento delladomanda su un sito Web mediante il collegamento di server supplementari.

/

Spazio Web WebSEAL

Spazio Web combinato:WebSEAL più server junctioned

/nodo

Figura 9. Il junction WebSEAL realizza uno spazio Web unificato


Junction WebSEAL e scalabilità del sito WebI junction WebSEAL vengono utilizzati per creare un sito Web dimensionabile. Conl’aumento delle domande sul sito Web, è facilmente possibile aggiungere altriserver per espandere le capacità del sito.

Server supplementari possono essere aggiunti per i seguenti motivi:v Per estendere il sito con contenuto aggiuntivov Per duplicare il contenuto esistente per il bilanciamentod el carico, la capacità di

fail-over e l’elevata disponibilità

Server front-end WebSEAL di replicaIl supporto di junction per i server back-end inizia con almeno un server front-endWebSEAL. I server front-end WebSEAL di replica forniscono al sito ilbilanciamento del carico durante periodi di forte domanda. Il meccanismo dibilanciamento del carico è gestito da un meccanismo come IBM NetworkDispatcher o Cisco Local Director.

La replica front-end fornisce al sito anche la capacità di fail-over; se un server nonfunziona per un qualsiasi motivo, i restanti server di replica continueranno afornire l’accesso al sito. Corrette funzioni di bilanciamento del carico e capacità diripristino da malfunzionamento (fail-over) determinano un’elevata disponibilità pergli utenti del sito.

Quando si effettua la replica di server front-end WebSEAL, ogni server devecontenere la copia esatta dello spazio Web e del database di junction.

Le informazioni di account per l’autenticazione risiedono in un registro utentiindipendente dai server front-end.

Supporto per server back-endIl contenuto del sito Web può essere trattato dallo stesso server WebSEAL, daserver back-end o da una combinazione di entrambi. Il supporto di junctionWebSEAL per i server back-end consente di dimensionare in scala il sito Webattraverso ulteriori contenuti e risorse.

Client SSL Client SSL

Server WebSEALprimario

Internet

Server WebSEALreplica

Meccanismo dibilanciamento di carico

Figura 10. Server WebSEAL front-end di replica


Ciascun server back-end deve essere collegato a un punto di junction (montaggio)separato. Con l’aumento della domanda di contenuto supplementare, sarà possibileaggiungere altri server attraverso junction. Questo scenario offre una soluzione perle reti che presentano un forte investimento in server Web di terzi.

Il diagramma seguente illustra il modo in cui i junction forniscono uno spaziooggetti logico unificato. Questo spazio Web è visibile all’utente e consente lagestione centralizzata.

Client SSL


Internet


Server di terzi/engineering

Client SSL

Server di terzi/sales


Figura 11. Junction di server back-end

Spazio oggetti Web

/Nodo engineering Nodo sales

Figura 12. Spazio Web unificato


I server back-end di replica sono collegati allo stesso punto di junction, cometrattato nella successiva sezione.

Server back-end di replicaPer estendere le funzioni di scalabilità a una configurazione di server back-end, èpossibile replicare i server back-end. Come per i server di replica front-end, iserver back-end di replica devono contenere spazi Web assolutamente simili l’unocon l’altro.

WebSEAL bilancia il carico sui server di replica utilizzando un algoritmo dipianificazione di “minor-utilizzo”. Questo algoritmo indirizza ogni nuova richiestaal server che presenta il minor numero di connessioni in corso.

WebSEAL effettuareà anche un corretto fail-over quando un server non risponde einizierà il riutilizzo di tale server una volta che sarà stato riavviato.

Se l’applicazione di back-end richiede che venga mantenuto lo stato su variepagine, è possibile utilizzare junction stateful per assicurare che ogni sessionevenga restituita allo stesso server back-end.

Client SSL


Internet


Client SSL

ServerEngineering replicati

ServerSales replicati

Serverfront-endreplicati


Figura 13. Server back-end di replica


Capitolo 2. Configurazione base del server

Il presente capitolo contiene informazioni che descrivono le attività generali diamministrazione e configurazione che l’utente esegue per personalizzare il serverWebSEAL per la propria rete.

Indice degli argomenti:v “Informazioni generali sul server” a pagina 19v “Utilizzo del file di configurazione WebSEAL” a pagina 21v “Configurazione dei parametri di comunicazione” a pagina 23v “Gestione dello spazio Web” a pagina 25v “Gestione delle pagine di messaggi di errore HTTP personalizzate” a pagina 31v “Gestione delle pagine di gestione account personalizzate” a pagina 34v “Gestione di certificati del cliente e del server” a pagina 35v “Configurazione della funzione di registrazione HTTP predefinita” a pagina 40v “Configurazione del logging HTTP mediante il logging di eventi” a pagina 43v “Registrazione messaggi di funzionalità WebSEAL” a pagina 44

Informazioni generali sul serverLe sezioni seguenti forniscono informazioni generali relative al server WebSEAL:v “Directory principale dell’installazione WebSEAL” a pagina 19v “Avvio e arresto di WebSEAL” a pagina 20v “WebSEAL rappresentato nello spazio oggetti protetti” a pagina 20v “WebSEAL restituisce HTTP/1.1” a pagina 20v “File di log GWebSEAL” a pagina 21

Directory principale dell’installazione WebSEALI file di programma WebSEAL sono installati nella seguente directory principale:

UNIX:/opt/pdweb/

Windows:C:\Program Files\Tivoli\PDWeb\

E’ possibile configurare questo percorso su un’installazione Access Manager perWindows. Non è possibile configurarlo su installazioni UNIX di Access Manager.

La presente guida utilizza la variabile <install-path> per rappresentare questadirectory principale.

Su installazioni UNIX, la seguente directory separata contiene file espandibili, qualii file di audit e di log:/var/pdweb/


Avvio e arresto di WebSEALE’ possibile avviare e arrestare il processo server WebSEAL utilizzando il comandopdweb su UNIX ed utilizzando il pannello di controllo dei servizi su Windows.

UNIX:pdweb {start|stop|restart|status}

Il comando pdweb è ubicato nella seguente directory:/usr/bin/

Ad esempio, per arrestare il server WebSEAL e quindi riavviarlo, utilizzare:# /usr/bin/pdweb restart

Windows:

Identificare il processo server WebSEAL nel Pannello di controllo servizi eutilizzare i pulsanti di controllo appropriati.

WebSEAL rappresentato nello spazio oggetti protettiIl parametro server-name nel file di configurazione webseald.conf specifica ilpunto, nello spazio oggetti protetti di Access Manager, che rappresenta questaistanza del server WebSEAL.

Per un’installazione di server WebSEAL singola, questo valore vieneautomaticamente impostato utilizzando il nome host della macchina sulla qualequesto server WebSEAL sta per essere installato.

Ad esempio, se il nome della macchina (host) è sales1, il valore del parametroviene impostato come:[server]server-name = sales1

La rappresentazione di questa istanza di server WebSEAL nello spazio oggettiprotetti di Access Manager sarà:/WebSEAL/sales1

Vedere anche: “Replica di server WebSEAL front-end” a pagina 52.

Per istanze multiple di WebSEAL sulla stessa macchina, questo valore vieneimpostato mediante l’opzione –i sullo script PDWeb_config (UNIX) o ivweb_setup(Windows) utilizzato per creare le istanze multiple del server WebSEAL.

Vedere anche: “Configurazione di istanze multiple del server WebSEAL” a pagina53.

WebSEAL restituisce HTTP/1.1Le richieste HTTP/1.0 vengono inviate a server back-end di junction solo se taliserver restituiscono uno stato 400 (Richiesta non corretta), uno stato 504 (VersioneHTTP non supportata), oppure se il browser del client specifica HTTP/1.0 nellarichiesta.

Diversamente, se il server back-end accetta HTTP/1.1, WebSEAL invia richiesteHTTP/1.1.


Tuttavia, anche quando WebSEAL invia una richiesta HTTP/1.0 a un serverback-end di junction (e il server back-end restituisce una risposta HTTP/1.0),WebSEAL restituisce sempre una risposta HTTP/1.1 al browser del client.

File di log GWebSEALIl file di log WebSEAL registra messaggi di funzionalità quali messaggi di errore odi avvertenza del server. Il nome e l’ubicazione del file di log sono definiti dalparametro server-log nella stanza [logging] del file di configurazionewebseald.conf:

UNIX:[logging]server-log = /var/pdweb/log/webseald.log

Windows:[logging]server-log = C:/Program Files/Tivoli/PDWeb/log/webseald.log

Vedere anche “Registrazione messaggi di funzionalità WebSEAL” a pagina 44.

Utilizzo del file di configurazione WebSEALLe sezioni seguenti forniscono informazioni sul file di configurazione WebSEAL(webseald.conf):v “Introduzione al file di configurazione webseald.conf” a pagina 21v “Directory principale del server WebSEAL” a pagina 23

Introduzione al file di configurazione webseald.confE’ possibile personalizzare l’operazione di WebSEAL configurando i parametriubicati nel file di configurazione webseald.conf. Il file si trova nella seguentedirectory:

UNIX:/opt/pdweb/etc/

Windows:C:\Program Files\Tivoli\PDWeb\etc\

I file di configurazione Access Manager sono ASCII basati su testo e possono esseremodificati mediante un comune editor di testo. I file di configurazione contengonovoci di parametri nel seguente formato:parametro = valore

L’installazione iniziale di Access Manager imposta valori predefiniti per la maggiorparte dei parametri. Alcuni parametri sono statici e non cambiano mai; altripossono essere modificati allo scopo di personalizzare le prestazioni e lafunzionalità del server.

Ciascun file contiene sezioni, o stanze, contenenti uno o più parametri per unaparticolare categoria di configurazione. Le intestazioni della stanza appaiono traparentesi quadre:[nome-stanza]

Capitolo 2. Configurazione base del server 21

Ad esempio, la stanza [junction] in webseald.conf definisce le impostazioni diconfigurazione che interessano i junction WebSEAL. La stanza[authentication-mechanisms] definisce i meccanismi di autenticazione supportatida WebSEAL, insieme ai file di librerie condivise associate.

I file di configurazione contengono commenti che illustrano l’utilizzo di ciascunparametro. Il carattere “#” è utilizzato per indicare una riga di commento. Tutte lerighe di commento iniziano con il carattere “#”. Perciò, il carattere “#” non è uncarattere valido da utilizzare nei valori di parametri.

Nota: Ogni volta che si effettuano modifiche al file webseald.conf, è necessarioriavviare manualmente WebSEAL in modo che le nuove modifiche venganoriconosciute. Consultare “Avvio e arresto di WebSEAL” a pagina 20.

La seguente tabella riepiloga le sezioni e le stanze contenute nel file diconfigurazione webseald.conf:

Sezioni Stanze

WEBSEAL GENERALE [server]

LDAP [ldap]

ACTIVE DIRECTORY [uraf-ad]

DOMINO [uraf-domino]

SSL [ssl]

JUNCTION [junction][filter-url][filter-schemes][filter-content-types][script-filtering][gso-cache][ltpa-cache]

AUTENTICAZIONE [ba][forms][token][certificate][http-headers][auth-headers][ipaddr][authentication-levels][mpa][cdsso][cdsso-peers][failover][e-community-sso][inter-domain-keys][reauthentication][authentication-mechanisms][ssl-qop][ssl-qop-mgmt-hosts][ssl-qop-mgmt-networks][ssl-qop-mgmt-default]

SESSIONE [session]


Sezioni Stanze

CONTENUTO [content][acnt-mgt][cgi][cgi-types][cgi-environment-variable][content-index-icons][icons][content-cache][content-mime-types][content-encodings]

LOGGING [logging]

API DI AUTORIZZAZIONE [aznapi-configuration][aznapi-entitlement-services]

POLICY DIRECTOR [policy-director]

Consultare Appendice A, “Riferimento webseald.conf” a pagina 225.

Directory principale del server WebSEALIl parametro server-root nel file di configurazione webseald.conf definiscel’ubicazione principale del server WebSEAL per altri parametri presenti in questofile. Tutti i nomi di percorso correlati espressi nel file di configurazionewebseald.conf sono collegati a questa directory principale.

UNIX:[server]server-root = /opt/pdweb/www

Windows:[server]server-root = C:\Program Files\Tivoli\PDWeb\www

Nota: In normali condizioni, non è il caso di modificare questo nome di percorso.

Configurazione dei parametri di comunicazioneLe seguenti sezioni riportano informazioni generali sul server WebSEAL:v “Configurazione di WebSEAL per richieste HTTP” a pagina 23v “Configurazione di WebSEAL per richieste HTTPS” a pagina 24v “Limitazione delle connessioni da versioni SSL specifiche” a pagina 24v “Parametri di timeout per comunicazione HTTP/HTTPS” a pagina 24v “Ulteriori parametri di timeout del server WebSEAL” a pagina 25

Configurazione di WebSEAL per richieste HTTPGeneralmente, WebSEAL gestisce molte richieste HTTP provenienti da utenti nonautenticati. Ad esempio, è uso comune consentire ad utenti anonimi l’accesso insola lettura a documenti selezionati della sezione pubblica del proprio sito Web.

I parametri per la gestione di richieste HTTP su TCP sono ubicati nella stanza[server] del file di configurazione webseald.conf.


Abilitazione/disabilitazione dell’accesso HTTPPer abilitare o disabilitare l’accesso HTTP durante la configurazione WebSEAL:http = {yes|no}

Impostazione del valore della porta di accesso HTTPLa porta predefinita per l’accesso HTTP è 80:http-port = 80

Per passare alla porta 8080, ad esempio, impostare:http-port = 8080

Configurazione di WebSEAL per richieste HTTPSI parametri per la gestione di richieste HTTP su SSL (HTTPS) sono ubicati nellastanza [server] del file di configurazione webseald.conf.

Abilitazione/disabilitazione dell’accesso HTTPSPer abilitare o disabilitare l’accesso HTTPS durante la configurazione WebSEAL:https = {yes|no}

Impostazione del valore della porta di accesso HTTPSLa porta predefinita per l’accesso HTTPS è 443:https-port = 443

Per passare alla porta 4343, ad esempio, impostare:https-port = 4343

Limitazione delle connessioni da versioni SSL specificheE’ possibile abilitare o disabilitare indipendentemente la connettività per SSL(Secure Sockets Layer) versione 2, SSL versione 3 e TLS (Transport Layer Security)versione 1. I parametri che controllano le connessioni per versioni SSL e TLSspecifiche sono ubicati nella stanza [ssl] del file di configurazione webseald.conf.Per impostazione predefinita, tutte le versioni SSL e TLS sono abilitate.[ssl]disable-ssl-v2 = nodisable-ssl-v3 = nodisable-tls-v1 = no

Parametri di timeout per comunicazione HTTP/HTTPSWebSEAL utilizza l’implementazione IBM Global Security Kit (GSKit) di SSL.Quando WebSEAL riceve una richiesta da un client HTTPS, l’SSL GSKit stabilisce ilcontatto iniziale e mantiene lo stato della sessione.

WebSEAL supporta i seguenti parametri di timeout per la comunicazione HTTP eHTTPS. Tali parametri sono ubicati nella stanza [server] del file di configurazionewebseald.conf.v client-connect-timeout

Una volta avvenuto il contatto iniziale, questo parametro imposta il tempo cheWebSEAL manterrà aperta la connessione per la richiesta HTTP o HTTPSiniziale. Il valore predefinito è di 120 secondi.[server]client-connect-timeout = 120

v persistent-con-timeout


Dopo la prima richiesta HTTP e la risposta del server, questo parametrocontrolla il numero massimo di secondi che WebSEAL mantiene aperta unaconnessione permanente HTTP prima di chiuderla. Il valore predefinito è di 5secondi.[server]persistent-con-timeout = 5

Ulteriori parametri di timeout del server WebSEALI seguenti parametri di timeout aggiuntivi vengono impostati nel file diconfigurazione webseald.conf:

Parametro Descrizione Valore predefinito(secondi)

[junction]http-timeout

Il valore di timeout per l’invio e lalettura da un server back-end su unjunction TCP.

120

[junction]https-timeout

Il valore di timeout per l’invio e lalettura da un server back-end su unjunction SSL.

120

[cgi]cgi-timeout

Il valore di timeout per l’invio e lalettura da un processo CGI locale.

120

[junction]ping-time

WebSEAL esegue un periodico pingdi sfondo di ogni server di junctionper determinare se questo è inesecuzione. WebSEAL non effettueràquesto controllo più di una voltaogni 300 secondi (o qualsiasi altrovalore impostato).

300

Gestione dello spazio WebLe seguenti sezioni illustrano le attività richieste per la gestione dello spazio Web:v “Directory principale della struttura documenti Web” a pagina 26v “Configurazione dell’indice directory” a pagina 27v “Windows: Denominazione file per programmi CGI” a pagina 28

Collegamento

Client WebSEAL

Handshake SSL

Richiesta HTTP

Risposta

Richiesta HTTP

GSKit controllato

timeout connessione client

timeout continuo

Figura 14. Parametri di timeout per la comunicazione HTTP e HTTPS


v “Configurazione cache di documenti Web” a pagina 28v “Specifica dei tipi di documento per il filtro” a pagina 31

Directory principale della struttura documenti WebLa posizione della struttura documenti Web è il percorso assoluto per la root dellastruttura documenti per le risorse rese disponibili da WebSEAL. Questo nomepercorso è rappresentato dal parametro doc-root nella stanza [content] del file diconfigurazione webseald.conf. L’ubicazione predefinita viene stabilita inizialmentedurante l’installazione di WebSEAL:

UNIX:[content]doc-root = /opt/pdweb/www/docs

Windows:[content]doc-root = C:\Program Files\Tivoli\PDWeb\www\docs

Questo valore viene utilizzato solo una volta, al primo avvio di WebSEAL dopol’installazione. Il valore viene quindi memorizzato nel database di junction. Lesuccessive modifiche di questo valore in webseald.conf non hanno alcun impatto.

Come modificare la root dei documenti dopo l’installazione:

Dopo l’installazione, è necessario utilizzare il programma di utilità pdadmin percambiare il valore di ubicazione della directory root dei documenti. Il seguenteesempio, (il nome macchina, o nome host, è websealA) illustra questa procedura:1. Effettuare il login a pdadmin:

# pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>

2. Utilizzare il comando server task list per visualizzare tutti i punti di junctioncorrenti:pdadmin> server task webseald-websealA list/

3. Utilizzare il comando server task show per visualizzare i dettagli del junction:pdadmin> server task webseald-websealA show /Punto junction: /Tipo: LocaleLimite hard junction: 0 - utilizzando il valore globaleLimite soft junction: 0 - utilizzando il valore globaleThread di processo attivi: 0Directory principale: /opt/pdweb/www/docs

4. Creare un nuovo junction locale per sostituire il punto di junction corrente(l’opzione -f è necessaria per forzare la sovrascrittura di un junction esistentecon un nuovo junction):pdadmin> server task webseald-websealA create -t local -f -d /tmp/docs /Junction creato su /

5. Elencare il nuovo punto di junction:pdadmin> server task webseald-websealA list/

6. Visualizzare i dettagli di questo junction:


pdadmin> server task webseald-websealA show /Punto junction: /Tipo: LocaleLimite hard junction: 0 - utilizzando il valore globaleLimite soft junction: 0 - utilizzando il valore globaleThread di processo attivi: 0Directory root: /tmp/docs

Configurazione dell’indice directoryE’ possibile specificare il nome del file predefinito restituito da WebSEAL quandol’espressione URL di una richiesta termina con un nome di directory. Se questo filepredefinito esiste, WebSEAL restituisce il file al client. Se il file non esiste,WebSEAL genera in modo dinamico un indice di directory e restituisce l’elenco alclient.

Il parametro per la configurazione del file indice di directory si trova nella stanza[content] del file di configurazione webseald.conf.

Il valore predefinito per il file di indice è:[content]directory-index = index.html

E’ possibile cambiare questo nome file se il proprio sito utilizza una convenzionediversa. Ad esempio:[content]directory-index = homepage.html

WebSEAL genera in modo dinamico un indice di directory se la directory presentenella richiesta non contiene il file di indice definito dal parametro directory-index.L’indice generato contiene un elenco del contenuto della directory, concollegamenti a ciascuna voce della directory. L’indice viene generato solo se ilclient che richiede l’accesso alla directory dispone dell’autorizzazione “list” (l)sull’ACL per tale directory.

E’ possibile configurare le icone grafiche specifiche utilizzate da WebSEAL per ognitipo file elencato in un indice generato. La stanza [content-index-icons] del file diconfigurazione webseald.conf contiene un elenco dei tipi MIME del documento edei file .gif associati che vengono visualizzati:[content-index-icons]image/*= /icons/image2.gifvideo/* = /icons/movie.gifaudio/* = /icons/sound2.giftext/html = /icons/generic.giftext/* = /icons/text.gifapplication/x-tar = /icons/tar.gifapplication/* = /icons/binary.gif

E’ possibile configurare questo elenco per specificare altre icone per ciascun tipoMIME. Le icone possono anche essere posizionate in remoto. Ad esempio:application/* = http://www.acme.com/icons/binary.gif

E’ anche possibile configurare i seguenti valori di icone supplementari:v Icona utilizzata per rappresentare sottodirectory:

[icons]diricon = /icons/folder2.gif

v Icona utilizzata per rappresentare la directory principale:


[icons]backicon = /icons/back.gif

v Icona utilizzata per rappresentare tipi file sconosciuti:[icons]unknownicon = /icons/unknown.gif

Windows: Denominazione file per programmi CGII parametri contenuti nella stanza [cgi-types] del file di configurazionewebseald.conf consentono all’utente di specificare i tipi di estensione di fileWindows riconosciuti ed eseguiti come programmi CGI.

Il sistema operativo UNIX non ha alcun requisito per l’estensione dei nomi file. Itipi di estensione file devono essere definiti, tuttavia, per i sistemi operativiWindows. La stanza [cgi-types] elenca tutti i tipi di estensione validi e associa ogniestensione (quando necessario) a un appropriato programma CGI.[cgi-types]<estensione> = <programma-cgi>

Per impostazione predefinita, soli i file con estensioni che corrispondono a quelleelencate nella stanza verranno eseguiti come programmi CGI. Se un programmaCGI ha un’estensione non contenuta in tale elenco, il programma non verràeseguito.

I file con estensioni .exe vengono eseguiti come programmi da impostazionipredefinite Windows e non richiedono alcuna associazione.

Nota: Ogni volta che si desidera installare un file .exe su Windows per ildownload, tuttavia, è necessario ridenominare l’estensione oppure installareil file come parte di un archivio (ad esempio .zip).

E’ necessario fornire il programma interpreter adatto per le estensioni cherappresentano i file script interpretati. Esempi di questi tipi di estensionecomprendono: file script shell (.sh e .ksh), script Perl (.pl) e script Tcl (.tcl).

Il seguente esempio illustra una tipica configurazione della stanza [cgi-types]:[cgi-types]bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Nota: Esistono serie condizioni di sicurezza coinvolte nell’utilizzo di file .bat e.cmd. Utilizzare questi tipi di file con cautela.

Configurazione cache di documenti WebI client possono spesso subire un tempo di accesso alla rete e di download dei fileelevato a causa delle basse prestazioni del recupero dei documenti Web. Le basseprestazioni possono verificarsi perché il server WebSEAL è in attesa di documentirecuperati da server back-end di junction oppure a causa di una lentamemorizzazione locale.

La memorizzazione nella cache dei documenti Web offre la flessibilità di trattarelocalmente i documenti da WebSEAL anziché da un server back-end su unjunction. La funzione di cache dei documenti Web consente di memorizzare tipi di


documenti Web a cui si accede spesso nella memoria del server WebSEAL. I clientavranno una risposta molto più rapida alle richieste di documenti memorizzatinella cache del server WebSEAL.

I documenti memorizzati nella cache possono comprendere documenti di testostatico e immagini grafiche. I documenti generati in modo dinamico, ad esempio irisultati di query del database, non possono essere memorizzati nella cache.

La memorizzazione nella cache viene eseguita sulla base del tipo MIME. Quando siconfigura WebSEAL per la cache di documenti Web, si identificano i tre seguentiparametri:v Tipo MIME del documentov Tipo di mezzo di memorizzazionev Dimensione del mezzo di memorizzazione

La cache di documenti Web viene definita nella stanza [content-cache] del file diconfigurazione webseald.conf. Viene applicata la seguente sintassi:<tipo-mime> = <tipo-cache>:<dimensione-cache>

Parametro Descrizione

tipo-mime Rappresenta qualsiasi tipo MIME valido convogliato inun’intestazione di risposta “Tipo-contenuto” HTTP. Questo valore puòcontenere un carattere globale ( * ). Un valore */* rappresenta unacache di oggetti predefinita che conserverà qualsiasi oggetto che noncorrisponde a una cache esplicitamente configurata.

tipo-cache Specifica il tipo del mezzo di memorizzazione da utilizzare per lacache. Questo rilascio di Access Manager supporta solo cache di“memoria”.

dimensione-cache Specifica la dimensione massima (in kilobyte) che la cache puòraggiungere prima che gli oggetti in essa contenuti vengano rimossiin base all’algoritmo di “minimo utilizzo recente”.

Esempio:text/html = memory:2000image/* = memory:5000*/* = memory:1000

Condizioni relative alla cache di documenti WebIl meccanismo di memorizzazione nella cache dei documenti Web osserva leseguenti condizioni:v La funzione di cache si verifica solo quando una cache è definita in

webseald.conf.v Per impostazione predefinita, nessuna cache è definita al momento

dell’installazione.v Se non si specifica una cache predefinita, i documenti che non corrispondono ad

alcuna cache esplicita non vengono memorizzati nella cache.v L’autorizzazione viene ancora eseguita su tutte le richieste di informazioni

memorizzate nella cache.v Il meccanismo di cache non memorizza le risposte alle richieste contenenti

stringhe di interrogazione.v Il meccanismo di cache non memorizza risposte a richieste su junction

configurati con le opzioni –c e –C.


Ripulitura di tutte le cacheE’ possibile utilizzare il programma di utilità pdadmin per ripulire tutte le cacheconfigurate. Il programma di utilità non consente all’utente di ripulire singolecache.

E’ necessario collegarsi al dominio protetto come responsabile Access Managersec_master prima di poter utilizzare il programma pdadmin.

Per svuotare tutte le cache dei documenti Web, immettere il seguente comando:

UNIX:# pdadmin server task webseald-<nome-macchina> cache flush all

Windows:MSDOS> pdadmin server task webseald-<nome-macchina> cache flush all

Controllo della cache per documenti specificiE’ possibile controllare la funzione di cache per documenti specifici collegando unPOP (Protected Object Policy) speciale a tali oggetti. Questo POP deve contenereun attributo esteso denominato document-cache-control.

L’attributo esteso document-cache-control riconosce i due seguenti valori:

Valore Descrizione

no-cache Il valore no-cache specifica a WebSEAL di non memorizzare nellacache un determinato documento. Ricordare che tutti gli elementisecondari dell’oggetto a cui si applica il POP ereditano allo stessomodo le condizioni del POP.

public Il valore public consente a WebSEAL di memorizzare nella cache ildocumento, ignorando il fatto che il junction era stato creato conun’opzione –c o –C. Inoltre, questo valore consente anche dimemorizzare nella cache tale documento quando la richiesta vieneinviata con un’intestazione di autorizzazione (ad esempio BasicAuthentication). Questa condizione include anche una richiesta in cuiWebSEAL inserisce informazioni BA per conto del client (come avvienecon GSO o junction –b supply). Generalmente, i server proxy nonmemorizzano nella cache i documenti di risposta alle richieste cheincludono intestazioni di autorizzazione.

Utilizzare i comandi pdadmin pop create, pdadmin pop modify e pdadmin popattach. L’esempio seguente illustra la creazione di un POP denominato “doc-cache”con l’attributo esteso document-cache-control e il suo collegamento a un oggetto(budget.html):pdadmin> pop create doc-cachepdadmin> pop modify doc-cache set attribute document-cache-control no-cachepdadmin> pop attach /WebSEAL/hostA/junction/budget.html doc-cache

Il documento budget.html non viene mai memorizzato nella cache da WebSEAL.Ogni richiesta di questo documento deve essere fatta direttamente al serverback-end su cui è ubicato.

Dettagli sul programma di utilità di riga comandi pdadmin sono reperibili nelmanuale IBM Tivoli Access Manager - Guida per il responsabile di sistema base.


Specifica dei tipi di documento per il filtroE’ possibile specificare i tipi di contenuto dei documenti che WebSEAL filtra nellerisposte provenienti da server back-end di junction. Il parametro type nella stanza[filter-content-types] del file di configurazione webseald.conf accetta un valore ditipo MIME. WebSEAL è configurato per impostazione predefinita per filtraredocumenti di due tipi MIME:[filter-content-types]type = text/htmltype = text/vnd.wap.wml

Le spcifiche di tipo MIME in questa stanza determinano la funzione di filtrosupplementare che viene eseguita da WebSEAL sulle risposte provenienti da serverback-end di junction. La funzionalità di filtro supplementare include:v Filtro di schema URL

Stanza [filter-schemes] nel file di configurazione webseald.conf

v Filtro di attributo URLConsultare “Regole di filtro URL standard per WebSEAL” a pagina 164.

v Filtro di script fper URL assolutiConsultare “Modifica di URL assoluti con funzione di filtro script” a pagina 165.

Gestione delle pagine di messaggi di errore HTTP personalizzateA volte il server WebSEAL prova a servire una richiesta e non ottiene esitopositivo. Questo malfunzionamento può essere provocato da diverse cause. Adesempio:v Un file non esistev Le impostazioni di autorizzazione negano l’accessov I programmi CGI non possono essere eseguiti a causa di autorizzazioni del file

UNIX non corrette o qualcosa di simile

Quando si verifica un errore nel trattare una richiesta, il server restituisce unmessaggio di errore al browser, ad esempio, “403 Accesso vietato”, in una paginadi errore HTML. Sono disponibili vari tipi di messaggi di errore; ciascun messaggioè memorizzato in un file HTML separato.

Tali file vengono memorizzati nella seguente directory:

UNIX: <percorso-installazione>/www/lib/errors/<dir-locale>

Windows: <percorso-installazione>\www\lib\errors\<dir-locale>

La directory errors contiene una serie di sottodirectory di locale contenentiversioni in lingua locale dei file di messaggi di errore.

Ad esempio, il percorso di directory per i messaggi in inglese (US/English) è:

UNIX: <percorso-installazione>/www/lib/errors/en_US

Windows: <percorso-installazione>\www\lib\errors\en_US

I messaggi in questa directory sono in formato HTML in modo che possano esserecorrettamente visualizzati in un browser. E’ possibile modificare queste pagineHTML per personalizzarne il contenuto. I nomi dei file rappresentano i valori


esadecimali dei codici di errore interni che vengono restituiti quando le operazioninon riescono. I nomi di questi file non devono essere modificati.

la seguente tabella contiene un elenco dei nomi di file e il contenuto per alcuni deipiù comuni messaggi di errore:

Nome file Titolo Descrizione Codice dierrore HTTP

132120c8.html Autenticazione non riuscita Non è possibile recuperare le credenziali per ilcertificato client utilizzato. Le cause possibilicomprendono:

v l’utente ha fornito un certificato non corretto

v il certificato è stato revocato

v le credenziali dell’utente non sono presenti neldatabase di autenticazione

38ad52fa.html Directory non vuota L’operazione richiesta prevede la rimozione di unadirectory non vuota. Questa è un’operazioneillegale.

38cf013d.html Memorizzazione nella cachedella richiesta non riuscita

I valori request-max-cache o request-body-max-read sono stati superati.

38cf0259.html Impossibile registrare unutente

La risorsa richiesta ha bisogno che il serverWebSEAL colleghi l’utente a un altro server Web.Tuttavia, si è verificato un problema mentreWebSEAL provava a recuperare le informazioni.

38cf025a.html L’utente non dispone diinformazioni SSO (SingleSign-on)

WebSEAL non è in grado di localizzare l’utenteGSO per la risorsa richiesta.

38cf025b.html Nessuna destinazione SSO(Single Sign-on) per l’utente

WebSEAL non è in grado di localizzare ladestinazione GSO per la risorsa richiesta.

38cf025c.html Destinazioni sign-onmultiple per l’utente

Destinazioni GSO multiple definite per la risorsarichiesta. Si tratta di un errore di configurazione.

38cf025d.html Login necessario La risorsa richiesta è protetta da un server Webback-end di junction e si richiede WebSEAL percollegare l’utente a tale server Web. Per poter fareciò, l’utente deve prima collegarsi a WebSEAL.

38cf025e.html Impossibile registrare unutente

La risorsa richiesta ha bisogno che WebSEALcolleghi l’utente a un altro server Web. Tuttavia leinformazioni di registrazione per l’account utentenon sono corrette.

38cf025f.html Richiesta di autenticazioneimprevista

WebSEAL ha ricevuto una richiesta diautenticazione imprevista da parte di un serverWeb back-end di junction.

38cf0421.html Temporaneamente spostata La risorsa richiesta è stata temporaneamentespostata. Ciò si verifica generalmente se si èverificato un reindirizzamento non gestitocorrettamente.

302

38cf0424.html Richiesta errata WebSEAL ha ricevuto una richiesta HTTP nonvalida.

400

38cf0425.html Login necessario La risorsa richiesta è protetta da WebSEAL e, perpotervi accedere, è prima necessario effettuare illogin.

38cf0427.html Accesso negato L’utente non dispone delle autorizzazioni peraccedere alla risorsa richiesta.

403


Nome file Titolo Descrizione Codice dierrore HTTP

38cf0428.html Non trovata Non è possibile localizzare la risorsa richiesta. 404

38cf0432.html Servizio non disponibile Un servizio richiesto da WebSEAL per completarela richiesta non è attualmente disponibile.

503

38cf0437.html Server sospeso Il server WebSEAL è stato temporaneamentesospeso dal responsabile di sistema. Nessunarichiesta verrà gestita fino a quando il responsabilenon ripristinerà il server in servizio.

38cf0439.html Informazioni di sessioneperse

L’interazione browser/server è stata un sessione distato con un server back-end di junction che nonrisponde più. WebSEAL richiede un serviziopresente su questo server per completare larichiesta.

38cf0442.html Servizio non disponibile Il servizio richiesto da WebSEAL si trova su unserver Web di junction in cui l’autenticazionereciproca SSL non ha avuto esito positivo.

38cf07aa.html Programma CGI nonriuscito

Un programma CGI non ha potuto essere eseguitocorrettamente.

default.html Errore server WebSEAL non può completare la richiesta a causadi un errore imprevisto.

500

deletesuccess.html Esito positivo La richiesta DELETE iniziata dal client è statacompletata correttamente.

200

putsuccess.html Esito positivo L’operazione PUT iniziata dal client è statacompletata correttamente.

200

relocated.html Temporaneamente spostata La risorsa richiesta è stata temporaneamentespostata.

302

websealerror.html Errore server WebSEAL 400 Errore interno del server WebSEAL. 400

Supporto macro per pagine di messaggi di errore HTTPLe seguenti macro sono disponibili per la personalizzazione delle pagine di erroreHTML elencate nella precedente sezione. Le macro sostituiscono dinamicamente leinformazioni appropriate che sono disponibili.

Macro Descrizione

%ERROR_CODE% Il valore numerico del codice di errore.

%ERROR_TEXT% Il testo associato a un codice di errore nel catalogo deimessaggi.

%METHOD% Il metodo HTTP richiesto dal client.

%URL% L’URL richiesto dal client.

%HOSTNAME% Il nome host completo.

%HTTP_BASE% URL HTTP base del server “http://<host>:<tcpport>/”.

%HTTPS_BASE% URL HTTPS base del server, “https://<host>:<sslport>/”.

%REFERER% Il valore dell’intestazione del referer proveniente dalla richiestaoppure “Sconosciuto”, se non presente.

%BACK_URL% Il valore dell’intestazione del referer proveniente dalla richiestaoppure “/” se non presente.

%BACK_NAME% Il valore “INDIETRO” se un’intestazione referer è presentenella richiesta, oppure “HOME” se non presente.


Gestione delle pagine di gestione account personalizzateAccess Manager include pagine HTML di gestione account di esempio che èpossibile personalizzare per contenere messaggi specifici per il sito oppure pereseguire azioni specifiche per il sito. La maggior parte dei moduli sono adatti perle autenticazioni Moduli, token e BA su HTTP o HTTPS.

Le ubicazioni dei file per questi moduli sono definite mediante il parametromgt-pages-root nella stanza [acnt-mgt] del file di configurazione webseald.conf.mgt-pages-root = lib/html/<lang-dir>

L’effettiva directory utilizzata si basa sulla localizzazione. La directory predefinitadell’Inglese/Americano è:lib/html/C

La locale giapponese individua i propri file in:lib/html/JP

Parametri e valori delle pagine personalizzateI seguenti parametri e valori speciali delle pagine HTML sono ubicati nella stanza[acnt-mgt] del file di configurazione webseald.conf. Alcune pagine sono utilizzateesclusivamente dal metodo di login Moduli per fornire informazioni di identità.

Parametro Pagina Utilizzo

login = login.html Login di moduli

login-success = login_success.html Login di moduli

logout = logout.html Login di moduli

account-locked = acct_locked.html Qualsiasi metodo

passwd-expired = passwd_exp.html Qualsiasi metodo

passwd-change = passwd.html Qualsiasi metodo

passwd-change-success = passwd_rep.html Qualsiasi metodo

passwd-change-failure = passwd.html Qualsiasi metodo

help = help.html Qualsiasi metodo

token-login = tokenlogin.html Login di token

next-token = nexttoken.html Login di token

stepup-login = stepuplogin.html Autenticazione a fasi

Descrizioni delle pagine HTML personalizzate

Modulo Descrizione

login.html Modulo di richiesta standard per nome utente e password

login_success.html Pagina visualizzata dopo un login riuscito

logout.html Pagina visualizzata dopo l’avvenuto scollegamento.

acct_locked.html Pagina visualizzata se l’autenticazione utente non è riuscitaa causa di un account bloccato.


Modulo Descrizione

passwd_exp.html Pagina visualizzata se l’autenticazione utente non è riuscitaa causa di una password scaduta.

passwd.html Modulo di modifica della password. Visualizzato anche sela richiesta di modifica della password non riesce.

passwd_rep.html Pagina visualizzata se la richiesta di modifica dellapassword ha avuto esito positivo.

help.html Pagina contenente collegamenti a pagine diamministrazione valide.

tokenlogin.html Modulo di login token.

nexttoken.html Modulo di token successivo.

stepuplogin.html Modulo di login autenticazione a fasi.

Supporto macro per pagine di gestione accountEsistono anche due macro disponibili per l’utilizzo in queste pagine. Questestringhe di macro possono essere inserite nei file di maschera. La macro sostituiscedinamicamente i valori appropriati.

Macro Descrizione

%USERNAME% Il nome dell’utente collegato.

%ERROR% Il messaggio di errore codificato restituito da Access Manager.

%METHOD% Il metodo HTTP richiesto dal client.

%URL% L’URL richiesto dal client.

%HOSTNAME% Il nome host completo.

%HTTP_BASE% URL HTTP base del server “http://<host>:<tcpport>/”.

%HTTPS_BASE% URL HTTPS base del server, “https://<host>:<sslport>/”.

%REFERER% Il valore dell’intestazione del referer proveniente dallarichiesta oppure “Sconosciuto”, se non presente.

%BACK_URL% Il valore dell’intestazione del referer proveniente dallarichiesta oppure “/” se non presente.

%BACK_NAME% Il valore “INDIETRO” se un’intestazione referer è presentenella richiesta, oppure “HOME” se non presente.

Gestione di certificati del cliente e del serverQuesta sezione descrive le attività di gestione e configurazione per impostareWebSEAL in modo da gestire certificati digitali del client e del server utilizzati perl’autenticazione su SSL.

WebSEAL richiede certificati per le seguenti situazioni:v WebSEAL identifica sé stesso ai client SSL con il proprio certificato serverv WebSEAL identifica sé stesso a un server back-end di junction (configurato per

l’autenticazione reciproca) mediante un certificato del clientv WebSEAL fa riferimento al proprio database di certificati principali CA

(Certificate Authority) per convalidare i client che accedono mediante certificaticlient


v WebSEAL fa riferimento al proprio database di certificati principali CA(Certificate Authority) per convalidare i server back-end di junction configuratiper l’autenticazione reciproca

WebSEAL utilizza l’implementazione IBM Global Security Kit (GSKit) di SSL perconfigurare e gestire i certificati digitali. GSKit fornisce il programma di utilitàiKeyman per impostare e gestire il database di chiavi dei certificati che contieneuno o più certificati server/client WebSEAL e i certificati principali di CA.

Durante l’installazione, WebSEAL include i seguenti componenti per supportarel’autenticazione SSL mediante certificati digitali:v Un database di chiavi predefinito (pdsrv.kdb)v Un file del database di chiavi predefinito (pdsrv.sth) e una password (“pdsrv”)v Vari certificati principali di CA comuniv Un certificato di prova autoconvalidato che WebSEAL può utilizzare per

identificare sé stesso ai client SSLSi raccomanda di applicare un certificato comunemente riconosciuto e originatoda un’autorità di certificazione (CA) per sostituire questo certificato di prova.

La configurazione per la gestione dei certificati WebSEAL comprende:v “Configurazione dei parametri del database di chiavi” a pagina 37v “Utilizzo del programma di utilità iKeyman per la gestione dei certificati” a

pagina 38v “Configurazione del controllo CRL” a pagina 39

Comprensione dei tipi di file del database di chiavi GSKitLo strumento IBM Key Management (iKeyman) utilizza diversi tipi di file,riepilogati nella seguente tabella.

Un database di chiavi CMS è composto da un file con estensione .kdb e,eventualmente, duo o più file aggiuntivi. Il file .kdb viene creato quando si crea unnuovo database di chiavi. Un record di chiave in un file .kdb può corrispondere aun certificato oppure a un certificato con le relative informazioni crittografate sullachiave privata.

I file .rdb e .crl vengono creati quando si crea una nuova richiesta di certificato. Ilfile .rdb è necessario durante il processo di richiesta del certificato CA.

Tipo file Descrizione

.kdb Il file del “database di chiavi”. Memorizza certificati personali, richieste di certificati personali ecertificati del firmatario. Ad esempio, il file di database di chiavi predefinito di WebSEAL èpdsrv.kdb.

.sth Il file di “password”. Memorizza una versione crittografata della password del database di chiavi. Ilnome derivato di questo file equivale al file .kdb associato.

.rdb Il file del database delle “richieste”. Creato automaticamente quando si crea un file di database dichiavi .kdb. Il nome derivato di questo file equivale al file .kdb associato. Questo file contiene lerichieste di certificato insolute e che non sono ancora state restituite dalla CA. Quando uncertificato viene restituito da una CA, nel file .rdb viene ricercata la corrispondente richiesta dicertificato (basata sulla chiave pubblica). Se viene rilevata una corrispondenza, il certificato vienericevuto e la relativa richiesta viene cancellata dal file .rdb. Se non viene rilevata alcunacorrispondenza, il tentativo di ricevere il certificato viene rifiutato. Compresi nella richiesta dicertificato, sono presenti il nome comune, l’organizzazione, l’indirizzo e altre informazionispecificate al momento della richiesta, oltre alla chiave pubblica e privata associata alla richiesta.


Tipo file Descrizione

.crl Il file di “elenco di revoca certificati”. Questo file generalmente contiene l’elenco dei certificati chesono stati revocati per varie ragioni. Tuttavia, iKeyman non fornisce alcun supporto per gli elenchidi revoca dei certificati, quindi il file è vuoto.

.arm Un file binario codificato ASCII. Un file .arm contiene una rappresentazione ASCII codificata inbase 64 di un certificato, inclusa la rispettiva chiave pubblica ma senza la chiave privata. I datibinari originali del certificato vengono trasformati in una rappresentazione ASCII. Quando unutente riceve un certificato in un file .arm, iKeyman decodifica la rappresentazione ASCII e sistemala rappresentazione binaria nel file .kdb appropriato. Allo stesso modo, quando un utente estrae uncertificato da un file .kdb, iKeyman converte i dati da binari a ASCII e li inserisce in un file .arm. Idati ASCII nel file .arm rappresentano ciò che l’utente invia alla CA durante il processo di richiestadel certificato. Nota: E’ accettato l’utilizzo di qualsiasi tipo di file (diverso da .arm), così come lostesso file è un file codificato in Base64.

.der Il file delle “regole di codifica distinte”. Un file .der contiene una rappresentazione binaria di uncertificato, inclusa la chiave pubblica ma senza quella privata. E’ molto simile a un file .arm, adeccezione del fatto che la rappresentazione è binaria e non ASCII.

.p12 Il file “PKCS 12”, dove PKCS indica “Public-Key Cryptography Standards”. Un file .p12 contieneuna rappresentazione binaria di un certificato, incluse la chiave pubblica e quella privata. Un file.p12 può anche includere più di un certificato; ad esempio, un certificato, il certificato della CA cheha emesso il certificato, colui che emette il certificato della CA, e così via. Poiché un file .p12contiene una chiave privata, è protetto mediante password.

Configurazione dei parametri del database di chiaviFile di chiavi del certificato WebSEAL:

Al momento dell’installazione, WebSEAL fornisce un database di chiavi delcertificato predefinito. Il parametro webseal-cert-keyfile, ubicato nella stanza [ssl]del file di configurazione webseald.conf, identifica il nome e la posizione di questofile:[ssl]webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

Per creare un nuovo database, è possibile utilizzare il programma di utilitàiKeyman. Tuttavia, è necessario immettere il nome e l’ubicazione di questo nuovofile di chiavi nel parametro webseal-cert-keyfile in modo che WebSEAL puòrilevare e utilizzare i certificati contenuti in tale database.

Password del file di chiavi del certificato:

Al momento dell’installazione, WebSEAL fornisce anche un file di passwordpredefinito che contiene la password per il file di chiavi pdsrv.kdb. Il parametrowebseal-cert-keyfile-stash informa WebSEAL sull’ubicazione del file di password:webseal-cert-keyfile-stash = /var/pdweb/www/certs/pdsrv.sth

La password crittografata predefinita in questo file di password è “pdsrv”. E’anche possibile esprimere una password come semplice testo nel parametrowebseal-cert-keyfile-pwd. Ad esempio:webseal-cert-keyfile-pwd = pdsrv

Al momento dell’installazione, WebSEAL utilizza il file di password per ottenere lapassword del file di chiavi. Il parametro webseal-cert-keyfile-pwd è commentato.Utilizzando il file di password, è possibile evitare la visualizzazione dellapassword come testo nel file di configurazione webseald.conf.


Nota: Decommentare il parametro di password specifico che si desidera utilizzare.Se sono specificati sia la password che il file di password, viene utilizzato ilvalore della password.

Certificato di prova WebSEAL:

Al momento dell’installazione, WebSEAL fornisce un certificato di provaautoconvalidato e non protetto. Il certificato di prova, che agisce come certificatodel server, consente a WebSEAL di identificare sé stesso ai client SSL.

Per un miglior controllo dell’utilizzo di questo certificato di prova, il certificatostesso non è installato come certificato predefinito. Al contrario, il parametrowebseal-cert-keyfile-label indica tale certificato come certificato attivo del server ericopre qualsiasi altro certificato indicato come “predefinito” nel database di file dichiavi.webseal-cert-keyfile-label = WebSEAL

Sebbene questo certificato di prova consenta a WebSEAL di rispondere a unarichiesta di browser abilitato SSL, non può essere verificato mediante il browser(che non contiene un appropriato certificato CA principale). Poiché la chiaveprivata per questo certificato predefinito è contenuta in qualsiasi distribuzione diWebSEAL, tale certificato non offre una comunicazione sicura.

E’ necessario utilizzare il programma di utilità iKeyman per generare una richiestadi certificato che possa essere inviata a una Autorità di certificazione (CA).Utilizzare iKeyman per installare ed etichettare il certificato del server che vienerestituito.

Se si utilizzano differenti certificati per altri scenari (ad esempio, junction –K), èpossibile utilizzare il programma di utilità iKeyman per creare, installare eetichettare tali certificati. L’etichetta del file di chiavi non deve contenere spazi.

WebSEAL (che per impostazione predefinita viene eseguito come user ivmgr) devedisporre di autorizzazione alla lettura (r) su questi file del database di chiavi.

Comunicazioni SSL interne con i server Access Manager:

La stanza [ssl] del file di configurazione webseald.conf contiene quattro parametriaggiuntivi utilizzati per configurare il file di chiavi utilizzato da WebSEAL percomunicazioni SSl interne con altri server Access Manager. Modificare questiparametri solo attraverso lo script di configurazione pdconfig.[ssl]ssl-keyfile =ssl-keyfile-pwd =ssl-keyfile-stash =ssl-keyfile-label =

Utilizzo del programma di utilità iKeyman per la gestione deicertificati

Il programma di utilità iKeyman è uno strumento fornito con GSKit che può essereutilizzato per gestire certificati digitali utilizzati da WebSEAL. Utilizzare iKeymanper:v creare uno o più database di chiaviv modificare le password dei database di chiaviv creare nuovi certificati WebSEAL


v impostare un nuovo certificato WebSEAL predefinitov creare un certificato self-signed per il testingv richiedere e ricevere certificati root CAv aggiungere certificati e cancellare certificati dal databasev copiare certificati da un database all’altro

Configurazione del controllo CRLCRL (Certificate Revocation List) è un metodo di prevenzione della convalida dicertificati indesiderati. CRL contiene le identità dei certificati giudicati nonaffidabili. L’implementazione GSKit di SSL utilizzata da WebSEAL supporta ilcontrollo CRL. GSKit consente a WebSEAL di eseguire il controllo CRL sucertificati client e su certificati di junction SSL.

WebSEAL deve conoscere l’ubicazione di questo elenco per poter eseguire ilcontrollo CRL. I parametri per l’ubicazione del server LDAP che può esserereferenziato per il controllo CRL durante l’autenticazione del certificato si trovanonella stanza [ssl] del file di configurazione webseald.conf:[ssl]#ssl-ldap-server = <server-name>#ssl-ldap-server-port = <port-id>#ssl-ldap-user = <webseal-admin-name>#ssl-ldap-user-password = <admin-password>

Per impostazione predefinita, il controllo CRL è disabilitato (i parametri sonocommentati). Per abilitare il controllo CRL durante l’autenticazione del certificato,decommentare ciascun parametro e immettere i valori appropriati.

Un valore nullo per ssl-ldap-user indica che il meccanismo di autenticazione SSLdeve collegarsi al server LDAP come utente anonimo.

Configurazione della cache CRLGSKit consente a WebSEAL di eseguire il controllo CRL su certificati client e sucertificati di junction SSL. Per migliorare le prestazioni del controllo CRL, èpossibile memorizzare nella cache il modulo CRL di una particolare Autorità dicertificazione (CA). I successivi controlli CRL vengono effettuati confrontandoquesta versione dell’elenco presente nella cache.

Le impostazioni per i due parametri del file di configurazione webseald.conftrattati in questa sezione vengono trasmessi direttamente al programma di utilitàGSKit. Per ulteriori informazioni sulla funzionalità di GSKit, fare riferimento alladocumentazione su GSKit.

Impostazione del numero massimo di voci della cacheIl parametro gsk-crl-cache-size specifica il numero massimo di voci presenti nellacache CRL GSKit. Ogni voce rappresenta un intero CRL per una particolareAutorità di certificazione. L’impostazione predefinita è “0”. Un valore maggiore di“0” è necessario per attivare la cache. Quando gsk-crl-cache-size egsk-crl-cache-entry-lifetime sono entrambi impostati su “0” (predefinito), ilcontrollo CRL è disabilitato.[ssl]gsk-crl-cache-size = 0

Impostazione del valore di timeout di durata della cache GSKitIl parametro gsk-crl-cache-entry-lifetime specifica il valore di timeout della duratadi tutte le voci presenti nella cache CRL GSKit. Il valore è espresso in secondi e


può avere un intervallo da 0 a 86400 secondi. Quando gsk-crl-cache-size egsk-crl-cache-entry-lifetime sono entrambi impostati su “0” (predefinito), ilcontrollo CRL è disabilitato.[ssl]gsk-crl-cache-size = 0

Configurazione della funzione di registrazione HTTP predefinitaWebSEAL mantiene tre file di log HTTP convenzionali che registrano l’attivitàdiversa dai messaggi:v request.log

v agent.log

v referer.log

Per impostazione predefinita, questi file di log sono ubicati nella seguentedirectory:

UNIX:/var/pdweb/www/log/

Windows:C:\Program Files\Tivoli\PDWeb\www\log\

I parametri per la configurazione della funzione di registrazione HTTP standard sitrovano nella stanza [logging] del file di configurazione webseald.conf.

La seguente tabella illustra la relazione tra i file di log HTTP e i parametri del filedi configurazione:

File di log Parametrodi posizione

Abilita/Disabilita parametro( = yes o no)

request.log requests-file requests

referer.log referers-file referers

agent.log agents-file agents

Ad esempio, la voce per la posizione predefinita del file request.log appare nelmodo seguente:

UNIX:requests-file = /var/pdweb/www/log/request.log

Windows:requests-file = \Program Files\Tivoli\PDWeb\www\log\request.log

Abilitazione e disabilitazione della funzione di registrazioneHTTP

Per impostazione predefinita, la funzione di registrazione HTTP è abilitata:[logging]requests = yesreferers = yesagents = yes


Ogni log può essere abilitato o disabilitato indipendentemente dagli altri. Se unparametro è impostato su “no”, la funzione di registrazione è disabilitata per talefile.

Una volta effettuata l’abilitazione come descritto, la funzione di registrazione HTTPpredefinita di WebSEAL viene effettivamente gestita dal meccanismo diregistrazione eventi di Access Manager, come descritto in “Configurazione dellogging HTTP mediante il logging di eventi” a pagina 43.

Specifica del tipo di formato data/oraE’ possibile scegliere di avere i formati data/ora in ogni log registrati in GMT(Greenwich Mean Time) anziché nell’ora del fuso locale. Per impostazionepredefinita, è utilizzata l’ora del fuso locale:[logging]gmt-time = no

Per utilizzare formati data/ora GMT, impostare:gmt-time = yes

Specifica delle soglie di rollover del file di logIl parametro max-size specifica la dimensione massima che può raggiungere ognifile di log HTTP e ha il seguente valore predefinito (in byte):[logging]max-size = 2000000

Quando un file di log raggiunge il valore specificato, conosciuto come soglia dirollover, viene eseguita una copia di backup del file esistente con uguale nome, alquale vengono accodate la data e il formato orario corrente. Viene quindi iniziatoun nuovo file di log.

I diversi valori max-size possibili vengono interpretati come riportato di seguito:v Se il valore di max-size è inferiore a zero (< 0), un nuovo file di log viene creato

ad ogni richiamo del processo di registrazione e ogni 24 ore a partiredall’istanza.

v Se il valore di max-size è uguale a zero (= 0), nessun rollover viene eseguito e ifile di log si accrescono all’infinito. Se un file di log esiste già, i nuovi dativerranno aggiunti a tale file.

v Se il valore di max-size è maggiore di zero (> 0), un rollover viene eseguitoquando il file di log raggiunge il valore di soglia configurato. Se un file di logesiste già al momento dell’avvio, i nuovi dati vengono aggiunti a tale file.

Specifica della frequenza di cancellazione dei buffer dei file dilog

I file di log vengono scritti in flussi di dati memorizzati in buffer. Se si effettua ilmonitoraggio dei file di log in tempo reale, si potrebbe voler modificare lafrequenza con la quale il server forza una ripulitura dei buffer dei file di log.

Per impostazione predefinita, i file di log vengono cancellati ogni 20 secondi:[logging]flush-time = 20

Se si specifica un valore negativo, la ripulitura verrà applicata dopo la scrittura diogni record.


Formato di log HTTP comune (per request.log)Ogni risposta (con esito positivo o negativo) inviata dal server Access Managerviene registrata con l’immissione di una riga nel file request.log mediante ilformato di log HTTP comune riportato di seguito:host - authuser [date] request status bytes

dove:

host Specifica l’indirizzo IP del computer che ha effettuato la richiesta.

authuser Questo campo assume il valore dell’intestazione Da: della richiestaHTTP ricevuta. Il valore “unauth” viene utilizzato per un utentenon autenticato.

date Specifica la data e l’ora della richiesta.

request Specifica la prima riga della richiesta, nel modo in cui arriva dalclient.

status Specifica il codice di stato HTTP inviato alla macchina richiedente.

bytes Specifica il numero di byte inviati alla macchina richiedente.Questo valore, che può equivalere a una dimensione di contenutonon filtrato oppure a una dimensione zero, viene configurato con ilparametro log-filtered-pages.

Visualizzazione del file request.logIl file request.log riporta registrazioni standard di richieste HTTP, ad esempioinformazioni su URL richiesti e informazioni sul client (ad esempio, l’indirizzo IP)che compongono la richiesta stessa.

Di seguito viene riportata una versione di esempio di un file request.log:130.15.1.90 - - [26/Jan/2002:17:23:33 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:23:47 -0800] ”GET /icons HTTP/1.0" 302 93130.15.1.90 - - [26/Jan/2002:17:23:59 -0800] "GET /icons/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:24:04 -0800] "GET /~am/a_html/ HTTP/1.0" 403 77130.15.1.90 - - [26/Jan/2002:17:24:11 -0800] "GET /~am/ HTTP/1.0" 403 77

Visualizzazione del file agent.logIl file agent.log registra il contenuto dell’intestazione User_Agent: della richiestaHTTP. Questo log rivela informazioni sul browser del client, ad esempioarchitettura e numero di versione, per ciascuna richiesta.

Di seguito viene riportata una versione di esempio di un file agent.log:Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)Mozilla/4.01 [en] (WinNT; U)

Visualizzazione di referer.logIl file referer.log registra l’intestazione Riferimento: della richiesta HTTP. Perciascuna richiesta, il log registra il documento che conteneva il collegamento aldocumento richiesto.

Il log utilizza il seguente formato:riferimento -> oggetto


Queste informazioni sono utili per la traccia di collegamenti esterni a documentipresenti nel proprio spazio Web. Il log rivela che l’origine indicata da riferimentocontiene un collegamento a un oggetto pagina. Questo log consente di eseguire latraccia di vecchi collegamenti e stabilire chi ha creato collegamenti ai propridocumenti.

Di seguito viene riportata una versione di esempio di un file referer.log:http://manuel/maybam/index.html -> /pics/tivoli_logo.gifhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.htmlhttp://manuel/maybam/ -> /pddl/index.htmlhttp://manuel/maybam/pddl/index.html ->/pics/tivoli_logo.gifhttp://manuel/maybam/ -> /pddl/index.html

Configurazione del logging HTTP mediante il logging di eventiLa funzione di logging HTTP WebSEAL può essere configurata nella stanza[aznapi-configuration] del file di configurazione webseald.conf utilizzando ilparametro di logging degli eventi logcfg per definire uno o più agenti di log(logger) che raccolgono una specifica categoria di informazioni di log dal pooldegli eventi e indirizzano tali informazioni a una destinazione:[aznapi-configuration]logcfg = <categoria>:{stdout|stderr|file|pipe|remote} [[<param>[=<valore>]][,<param>[=<valore>]]...]

Per dettagli completi sulla configurazione del logging degli eventi, fare riferimentoal capitolo sul “Logging di eventi” del manuale IBM Tivoli Access Manager - Guidaper il responsabile di base.

I valori di categoria adatti per il logging HTTP comprendono:v http

Tutte le informazioni di logging HTTPv http.clf

Informazioni sulla richiesta HTTP in formato log comunev http.ref

Informazioni sull’intestazione del Riferimento HTTPv http.agent

Informazioni sull’intestazione User_Agent HTTPv http.cof

Il formato combinato NCSA cattura le informazioni sulle richieste HTTP (condata/ora) e accoda le stringhe agente e riferimento tra virgolette al formato dilog standard comune.

Le seguenti configurazioni di agente di log vengono abilitate quando i parametri dilogging HTTP predefiniti di WebSEAL vengono abilitati (vedere “Configurazionedella funzione di registrazione HTTP predefinita” a pagina 40). Notare che leconfigurazioni degli agenti di log accettano i valori dei parametri requests-file,referers-file, agents-file, flush-time e max-size della stanza [logging] del file diconfigurazione webseald.conf:

request.log (formato log comune):logcfg = http.clf:file path=<requests-file>,flush=<flush-time>, \rollover=<max-size>,log=clf,buffer_size=8192,queue_size=48


referer.log:logcfg = http.ref:file path=<referers-file>,flush=<flush-time>, \rollover=<max-size>,log=ref,buffer_size=8192,queue_size=48

agent.log (formato log comune):logcfg = http.agent:file path=<agents-file>,flush=<flush-time>, \rollover=<max-size>,log=agent,buffer_size=8192,queue_size=48

Poiché la funzione di logging HTTP predefinita è configurata in una diversa stanza([logging]) rispetto alla configurazione del logging degli eventi([aznapi-configuration]), è possibile che si possano avere due voci duplicate perciascun evento in un file di log quando entrambi i meccanismi di logging sonoabilitati.

Il meccanismo di logging degli eventi fornisce una maggior flessibilità nellaraccolta delle informazioni di log HTTP e nella personalizzazione dell’output.

Registrazione messaggi di funzionalità WebSEALI messaggi di funzionalità WebSEAL di Access Manager vengono controllati dal filedi instradamento WebSEAL di Access Manager. Il file di instradamento è ubicatonella seguente directory:

UNIX:/opt/pdweb/etc/

Windows:C:\Program Files\Tivoli\PDWeb\etc\

Il file di instradamento è un file ASCII che contiene documentazionesupplementare sotto forma di righe di commento. Le voci presenti in questo file diconfigurazione determinano i tipi dei messaggi di funzionalità che vengonoregistrati. Abilitare le voci rimuovendo il carattere di commento (#). Il file diinstradamento include le seguenti voci predefinite:

UNIX:FATAL:STDERR:-ERROR:STDERR:-WARNING:STDERR:-#NOTICE:FILE.10.100:/opt/pdweb/log/notice.log#NOTICE_VERBOSE:FILE.10.100:/opt/pdweb/log/notice.log

Windows:FATAL:STDERR:-ERROR:STDERR:-WARNING:STDERR:-#NOTICE:FILE.10.100:%PDWEBDIR%/log/notice.log#NOTICE_VERBOSE:FILE.10.100:%PDWEBDIR%/log/notice.log

Nota: Su un sistema Windows, la variabile di ambiente speciale PDWEBDIR èimpostata al runtime nella directory di installazione di WebSEAL.

Per impostazione predefinita, quando WebSEAL viene eseguito in primo piano,tutti i messaggi vengono inviati sullo schermo (STDERR).

Per impostazione predefinita, quando WebSEAL viene eseguito in background, imessaggi vengono reindirizzati da STDERR al file di log del server WebSEAL,


come definito nella stanza [logging] del file di configurazione webseald.conf:

Server File diconfigurazione

Ubicazione file di log

Server WebSEAL(webseald)

webseald.conf UNIX:[logging]server-log=/var/pdweb/log/webseald.logWindows:[logging]server-log=C:\Program Files\Tivoli\PDWeb\log\webseald.log

Per abilitare verbose.log, decommentare la riga NOTICE_VERBOSE.

La sintassi di FILE per il messaggio NOTICE controlla il rollover del log e ilriciclaggio del file:FILE.<max-files>.<max-records>

Il valore max-file specifica il numero di file che vengono utilizzati.

Il valore max-records specifica il numero massimo di voci per file.

Nell’esempio precedente, FILE.10.100 significa che esistono 10 file creati, ognunodei quali con un massimo di 100 voci. I file sono denominati:notice.log.1notice.log.2...notice.log.10

I messaggi “ripartono” dal primo file quando l’ultimo file ha raggiunto il propriolimite oppure quando il server viene interrotto e riavviato. Quando un file di logviene riutilizzato, i record esistenti vengono sovrascritti (quindi, cancellati).


Capitolo 3. Configurazione avanzata del server

Il presente capitolo contiene informazioni che descrivono le attività generali diamministrazione e configurazione che l’utente esegue per personalizzare il serverWebSEAL per la propria rete.

Indice degli argomenti:v “Configurazione di una qualità di protezione di livello predefinito” a pagina 47v “Configurazione aggiornamenti e polling del database autorizzazioni” a pagina

48v “Gestione dell’assegnazione dei thread di processo” a pagina 49v “Replica di server WebSEAL front-end” a pagina 52v “Configurazione di istanze multiple del server WebSEAL” a pagina 53v “Configurazione SU (switch user) per i responsabili” a pagina 60v “Configurazione cache di richieste WebSEAL del server” a pagina 67v “Gestione dei caratteri codificati UTF-8” a pagina 70v “Prevenzione della vulnerabilità causata da scripting cross-site” a pagina 71v “Soppressione dell’identità del server” a pagina 72v “Utilizzo di statistiche WebSEAL” a pagina 73v “Utilizzo del programma di utilità di traccia per la cattura di azioni WebSEAL”

a pagina 82

Configurazione di una qualità di protezione di livello predefinitoE’ possibile controllare il livello predefinito della codifica richiesta per accedere aWebSEAL attraverso SSL (HTTPS) mediante la configurazione della qualità diprotezione (QOP). La qualità predefinita di gestione della protezione vienecontrollata mediante parametri nella sezione “GESTIONE QOP SSL” del file diconfigurazione webseald.conf:v Abilitare o disabilitare la gestione QOP con il parametro ssl-qop-mgmt

v Specificare i livelli di codifica consentiti nella stanza [ssl-qop-mgmt-default]

1. Per abilitare la gestione della qualità di protezione:[ssl-qop]ssl-qop-mgmt = yes

2. Per specificare il livello di codifica predefinito per l’accesso HTTPS:[ssl-qop-mgmt-default]# default = ALL | NONE | <livello di codice># ALL (abilita tutti i codici)# NONE (disabilita tutti i codici e utilizza un check sum MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128default = ALL

Notare che è anche possibile specificare un gruppo selezionato di codici:


[ssl-qop-mgmt-default]default = RC4-128default = RC2-128default = DES-168

Configurazione QOP per singoli host e singole retiIl parametro ssl-qop-mgmt = yes abilita anche qualsiasi impostazione presentenelle stanze [ssl-qop-mgmt-hosts] e [ssl-qop-mgmt-networks]. Queste stanzeconsentono la gestione della qualità di protezione mediante specifici indirizzi IPhost/rete/mascherarete.

La stanza [ssl-qop-mgmt-default] elenca i codici utilizzati per tutti gli indirizzi IPche non hanno corrispondenza nelle stanze [ssl-qop-mgmt-hosts] e[ssl-qop-mgmt-networks].

Esempio di sintassi di configurazione per host:[ssl-qop-mgmt-hosts]# <ip-host> = ALL | NONE | <livello-codice># ALL (abilita tutti i codici)# NONE (disabilita tutti i codici e utilizza un check sum MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128xxx.xxx.xxx.xxx = ALLyyy.yyy.yyy.yyy = RC2-128

Esempio di sintassi di configurazione per rete/maschera di rete:[ssl-qop-mgmt-networks]# <rete/maschera di rete> = ALL | NONE | <livello-codice># ALL (abilita tutti i codici)# NONE (disabilita tutti i codici e utilizza un check sum MD5 MAC)# DES-40# DES-56# DES-168# RC2-40# RC2-128# RC4-40# RC4-128xxx.xxx.xxx.xxx/255.255.255.0 = RC4-128yyy.yyy.yyy.yyy/255.255.0.0 = DES-56

Le stanze [ssl-qop-mgmt-hosts] e [ssl-qop-mgmt-networks] vengono forniteesclusivamente per compatibilità retroattiva. Si raccomanda di non utilizzarle perla configurazione Access Manager.

Configurazione aggiornamenti e polling del database autorizzazioniIl server dei criteri Access Manager (pdmgrd) gestisce il database dei criteri diautorizzazione principale e mantiene le informazioni di ubicazione relative ad altriserver Access Manager nel dominio protetto. Un responsabile Access Manager può,in qualsiasi momento, apportare modifiche ai criteri di sicurezza nel dominioprotetto. Il server dei criteri effettua le necessarie modifiche al database diautorizzazione principale ogni volta che le modifiche ai criteri di sicurezzavengono implementate.


Quando il server dei criteri effettua una modifica al database di autorizzazioneprincipale, può inviare una notifica di tale modifica a tutti i database di replicapresenti nel dominio protetto che supportano singoli programmi di rafforzamentodei criteri (ad esempio WebSEAL). Il programma di rafforzamento dei criteri devequindi richiedere un effettivo aggiornamento del database dal database diautorizzazione principale.

WebSEAL, come gestore delle risorse e programma di rafforzamento dei criteri,dispone di tre opzioni per ottenere informazioni sulle modifiche al database delleautorizzazioni:v Rilevare (listening) notifiche di aggiornamento provenienti dal server dei criteri

(opzione configurabile e abilitata per valore predefinito).v Controllare (polling) il database autorizzazioni principale a intervalli regolari

(opzione configurabile e disabilitata per valore predefinito).v Abilitare entrambe le funzioni di listening e polling.

La stanza [aznapi-configuration] del file di configurazione webseald.conf contieneparametri per la configurazione dell’ascolto di notifiche di aggiornamento e delpolling di database.

Il percorso per il database dei criteri di autorizzazione di replica locale diWebSEAL è definito dal parametro db-file:[aznapi-configuration]db-file = /var/pdweb/db/webseald.db

Configurazione ascolto notifiche di aggiornamentoIl parametro listen-flags abilita e disabilita l’ascolto delle notifiche diaggiornamento da parte di WebSEAL. Per impostazione predefinita, l’ascolto èabilitato. Per abilitare la funzione di ascolto, immettere “disable”.[aznapi-configuration]listen-flags = enable

Il parametro tcp-port configura la porta TCP per il listener:[aznapi-configuration]tcp-port = 12056

Il parametro udp-port configura la porta TCP per il listener:[aznapi-configuration]udp-port = 0

Configurazione polling del database autorizzazioniE’ possibile configurare WebSEAL in modo che esegua regolarmente il polling deldatabase di autorizzazioni principale per rilevare informazioni di aggiornamento. Ilparametro cache-refresh-interval può essere impostato su “default”, “disable” o suun intervallo specifico espresso in secondi. L’impostazione “default” equivale a 600secondi. Per impostazione predefinita, la funzione di polling è disabilitata.[aznapi-configuration]cache-refresh-interval = disable

Gestione dell’assegnazione dei thread di processov “Configurazione dei thread di processo di WebSEAL” a pagina 50v “Assegnazione di thread di processo per junction (equità junction)” a pagina 50

Capitolo 3. Configurazione avanzata del server 49

Configurazione dei thread di processo di WebSEALIl numero dei thread di processo configurati specifica il numero di richieste inentrata simultanee che possono essere trattate da un server. Le altre connessioni inarrivo quando tutti i thread di processo sono impegnati verranno sistemate nelbuffer fino a quando un thread di processo non si renderà disponibile.

L’utente può impostare il numero di thread disponibili per servire connessioni inentrata su WebSEAL. La configurazione del numero di thread di processo deveavvenire con attenzione, a causa del possibile impatto sulle prestazioni.

Questo parametro di configurazione non impone un limite massimo al numero diconnessioni simultanee. Questo parametro specifica semplicemente il numero dithread resi disponibili al servizio di una coda di lavoro potenzialmente illimitata.

La scelta di un numero ottimale di thread di processo dipende dalla quantità e daltipo di traffico della propria rete.

Incrementando il numero di thread, generalmente, si riduce il tempo medionecessario per completare le richieste. Tuttavia, l’incremento del numero di threadinfluenza altri fattori che potrebbero avere un effetto inverso sulle prestazioni delserver.

WebSEAL mantiene un pool di thread di processo e un elenco generico dei threadper la gestione delle richieste provenienti da client che utilizzano TCP o SSL.Questo meccanismo avanzato permette a WebSEAL di consumare un minornumero di risorse del sistema durante la gestione di carichi elevati.

E’ possibile configurare la dimensione del pool di thread di processo impostando ilparametro worker-threads nella porzione di stanza [server] del file diconfigurazione webseald.conf.[server]worker-threads = 50

Nota: Si raccomanda di modificare questo parametro solo per risolvere unproblema di prestazioni.

Assegnazione di thread di processo per junction (equitàjunction)

E’ possibile configurare l’assegnazione di thread di processo WebSEAL utilizzatiper elaborare richieste su junction multipli su base globale o per-junction. Ilmeccanismo di configurazione mantiene un’“equa” distribuzione dei thread diprocesso su tutti i junction e impedisce lo sfruttamento intensivo del pool di threaddi processo da parte di un singolo junction.

Informazioni secondarieWebSEAL attinge dal proprio pool di thread di processo per elaborare richiestemultiple. Il numero di thread di processo disponibili per WebSEAL è specificatodal parametro worker-threads nel file di configurazione webseald.conf.

E’ possibile regolare il valore di worker-threads per servire in modo migliore lapropria particolare implementazione WebSEAL. Quando nessun thread di processoè disponibile per la gestione di richieste in entrata, l’utente noterà che il serverWebSEAL non risponde.


I thread di processo vengono utilizzati per gestire richieste in entrata perapplicazioni che risiedono su server back-end di junction multipli. Tuttavia, il pooldi thread di processo può rapidamente esaurirsi se una particolare applicazioneback-end è inaspettatamente lenta durante la risposta e l’elaborazione di un elevatovolume di richieste. Uno sfruttamento elevato del pool di thread di processo daparte di questo tipo di applicazione rende WebSEAL incapace di rispondere allerichieste di servizi sui restanti server applicativi di junction.

E’ possibile configurare limiti globali o per-junction al numero di thread diprocesso utilizzati per servire applicazioni su junction multipli. Questi limiticonsentono il prevalere di un’“equità” per tutti i junction ed impediscono che unaqualsiasi applicazione si appropri di più thread di processo di quanti ad essaspettano.

Assegnazione globale di thread di processo per junctionDue parametri ubicati nella stanza [junction] del file di configurazionewebseald.conf controllano l’assegnazione globale di thread di processo su tutti ijunction di un particolare server WebSEAL. Il valore utilizzato per questi parametriviene espresso come percentuale in un intervallo da 0 a 100. Il valore predefinito di100 (%) indica che non è impostato alcun limite.v worker-thread-soft-limit

Questo parametro agisce come segnalazione prima che venga raggiunto il limite“hard”. Quando worker-thread-soft-limit viene superato, i messaggi diavvertenza vengono inviati (ogni 30 secondi) al file di log degli errori diWebSEAL.Ad esempio, quando worker-threads=50, un’impostazione di 60 (%) provocal’emissione di messaggi di avvertenza quando il junction consuma più di 30thread di processo. Tutte le richiestesuperiori ai 30 thread di processo vengonoancora elaborate, fono al raggiungimento del limite “hard”.

v worker-thread-hard-limit

Questo parametro agisce come punto limite per il servizio di richieste su unjunction. Quando il worker-thread-hard-limit viene superato, i messaggi dierrore vengono inviati (ogni 30 secondi) al file di log degli errori di WebSEAL.Inoltre, all’utente viene inviato un messaggio 503 di “Servizio non disponibile”.Ad esempio, quando worker-threads=50, un’impostazione di 80 (%) provocal’emissione di messaggi di errore quando il junction prova a consumare più di40 thread di processo. Tutte le richieste che rappresentano più di 40 thread diprocesso sul junction vengono restituite con un messaggio 503 di “Servizio nondisponibile”.

Queste impostazioni globali si applicano uniformemente a tutti i junctionconfigurati. Quando si configurano questi due parametri, è logico impostare illimite “soft” a un valore inferiore rispetto al limite “hard”.

Assegnazione per junction di thread di processo per i junctionIn alternativa, è possibile limitare il consumo di thread di processo su una base perjunction. Le seguenti opzioni per il comando pdadmin server task createconsentono di specificare limiti hard e soft per i thread di processo su unospecifico junction:v –l <valore-percentuale>

Questa opzione imposta sul junction un valore (percentuale) che definisce illimite soft per il consumo di thread di processo. Come nell’impostazione del


limite soft globale, questa opzione provoca l’emissione di messaggi diavvertenza quando il junction consuma più thread di processo di quanticonsentiti dall’impostazione.

v –L <valore-percentuale>Questa opzione imposta sul junction un valore (percentuale) che definisce illimite hard per il consumo di thread di processo. Come nell’impostazione dellimite hard globale, questa opzione provoca l’emissione di messaggi diavvertenza quando il junction prova a consumare più thread di processo diquanti consentiti dall’impostazione. Inoltre, all’utente viene inviato un messaggio503 di “Servizio non disponibile”.

Ad esempio:pdadmin> server task webseald-<nome-server> create -t tcp -h <nome-host> \-l 60 -L 80 <punto-jct>

Le impostazioni per junction ricoprono sempre le impostazioni globali inwebseald.conf. Impostazioni inappropriate su uno specifico junction potrebberoinfluenzare negativamente il criterio stabilito dalle impostazioni globali.

Note per la risoluzione dei problemiv E’ possibile utilizzare il comando pdadmin server task show per visualizzare il

numero di thread di processo attivi su un junction specifico:pdadmin> server task webseald-<nome-server> show /<punto-jct>

Queste informazioni possono essere utili quando si desidera determinarel’ubicazione di un junction che assorbe una quantità superiore di risorse dithread di processo di quanto stabilito per la propria condivisione.

v Se si specifica un valore per il limite soft maggiore del valore per il limite hardsu un junction specifico, il junction non verrà creato.

v E’ necessario specificare entrambi i valori per i limiti soft e hard (entrambe leopzioni –l e –L) su un junction specifico.

Replica di server WebSEAL front-end

Nota: Le seguenti informazioni sostituiscono il precedente comando pdadminserver modify baseurl, utilizzato in versioni precedenti di Access Manager.

In un ambiente ad alto carico, è vantaggioso replicare i server WebSEAL front-endper fornire un miglior bilanciamento del carico e capacità di fail-over. Quando sieffettua la replica di server WebSEAL front-end, ogni server deve contenereun’esatta copia dello spazio Web, del database di junction e del database dynurl.

Questa versione di Access Manager supporta una procedura di configurazionemanuale per replicare i server WebSEAL front-end. Il comando pdadmin non è piùutilizzato per questa attività.

Nel seguente esempio, “WS1” indica il nome host del server WebSEAL primario.“WS2” è il nome host per il server WebSEAL di replica.1. Installare e configurare WebSEAL su entrambi i server WS1 e WS2.2. Arrestare WebSEAL su WS2.3. Su WS2, cambiare il valore del parametro server-name nel file di

configurazione webseald.conf da “WS2” a “WS1”:


[server]server-name = WS1

4. Riavviare WebSEAL su WS2.

Ora il server WS2 utilizza l’oggetto /WebSEAL/WS1 come base per le valutazioni diautorizzazioni. Il server WS2 può anche rispondere a comandi object list e objectshow relativi ad oggetti ubicati in /WebSEAL/WS1.

Il programma di utilità pdadmin elenca ancora l’oggetto /WebSEAL/WS2 comefacente parte dello spazio oggetti. Tale oggetto è ora inutile e può essere rimosso:pdadmin> object delete /WebSEAL/WS2

Condizioni:v Gestione unificata dello spazio oggetti: Sebbene al responsabile sia visibile una

singola gerarchia di oggetti, tutti i server WebSEAL replicati vengono influenzatidai comandi del responsabile applicati a tale gerarchia di oggetti e tutti i serversono in grado di rispondere a tali comandi.

v Valutazione unificata delle autorizzazioni: Se il server WS2 è configurato comereplica del server WS1, WS2 utilizza /WebSEAL/WS1 come base per le valutazionidi autorizzazione.

v Configurazione unificata: Perché la replica WebSEAL front-end funzionicorrettamente, la configurazione dello spazio Web, del database di junction e deldatabase dynurl deve essere identica su tutti i server.

Configurazione di istanze multiple del server WebSEALAccess Manager fornisce la capacità di configurare istanze multiple di serverWebSEAL su una singola macchina.

Panoramica sulla configurazioneA scopo di configurazione, un’istanza di un server WebSEAL viene definitamediante una combinazione univoca di interfaccia di rete (indirizzo IP) e numerodi porta.

Istanze multiple di WebSEAL possono essere configurate mediante uno deiseguenti metodi per creare combinazioni interfaccia di rete/porta univoche:v Utilizzare una singola interfaccia di rete (indirizzo IP) ed assegnare le istanze

WebSEAL a porte di ascolto HTTP/HTTPS univochev Assegnare istanze WebSEAL a interfacce di rete univoche (schede di interfaccia

di rete fisica o alias di reti logiche) e utilizzare comuni porte di ascoltoHTTP/HTTPS

Nota: In entrambi gli scenari, il valore di porta inter-server specificato dall’opzione–m deve essere unico per tutte le istanze WebSEAL.

Ogni istanza WebSEAL configurata ha un nome univoco, un numero di portainterna univoco (per la comunicazione tra server Access Manager), un’ubicazionedirectory univoca e un file di configurazione univoco. File di configurazionemultipli vengono resi univoci attraverso il nome dell’istanza server preceduto dawebseald-. Ad esempio:/opt/pdweb/etc/webseald-<nome-istanza>.conf

Gli strumenti di configurazione necessari per configurare e deconfigurare istanzemultiple di server WebSEAL comprendono:


v Sistemi UNIX:Il programma di utilità della riga comandi PDWeb_config

Il programma di utilità della riga comandi PDWeb_unconfig

Nota: Il programma di utilità pdconfig può essere utilizzato per creare l’istanzaWebSEAL iniziale. La riga del comando PDWeb_config deve essereutilizzata per creare tutte le ulteriori istanze. Questa descrizione di istanzemultiple presuppone che sia stato configurato un server WebSEALiniziale.

v Sistemi Windows:Il programma di utilità della riga comandi ivweb_setup

Il programma di utilità della riga comandi ivweb_uninst

Configurazione di istanze multiple WebSEAL su UNIXIl programma di utilità PDWeb_config si trova nella seguente directory:/opt/pdweb/sbin/

Sintassi PDWeb_config:# ./PDWeb_config –i <nome-istanza> –m <porta-interna> [–n <interfaccia-rete>]

Argomento Descrizione

nome-istanza Nome univoco per questa istanza. E’ necessario utilizzarequesto nome per deconfigurare l’istanza. La lunghezza ditale nome è limitata a 20 caratteri.

porta-interna Numero di porta univoco per la comunicazione traserver Access Manager. Il valore deve essere superiore a1023. (I valori inferiori o uguali a 1023 sono riservati.)

interfaccia-rete Argomento facoltativo per specificare l’indirizzo IP diun’interfaccia di rete.

Nota: Il valore della porta inter-server specificato dall’opzione –m deve essereunivoco per tutte le istanze WebSEAL.

Configurazione di istanze multiple su porte HTTP/HTTPS univoche:

1. Presupposto: La macchina è configurata con un server WebSEAL iniziale(pdconfig) ed un singolo indirizzo IP o una singola scheda di rete (ad esempio:1.2.3.4).

2. Passare alla directory:# cd /opt/pdweb/sbin

3. Eseguire il comando PDWeb_config per creare e configurare un’istanzaWebSEAL aggiuntiva.In questo scenario, le istanze multiple del server vengono rese univocheattraverso la designazione univoca della porta inter-server e della porta diascolto HTTP/HTTPS sull’interfaccia di rete predefinita. Quindi, non utilizzarel’opzione –n per specificare un’interfaccia di rete. Ad esempio:# ./PDWeb_config –i webseal2 –m 3232

4. Viene visualizzato il pannello di impostazione della configurazione:Controllare la configurazione del server Web:1. Abilita TCP HTTP? Si2. Porta HTTP 803. Abilita HTTPS? Si4. Porta HTTPS 443


5. Directory principale dei documenti Web /opt/pdweb/www-webseal2/docsa. Accetta configurazione e continua con l’installazionex. Esci dall’installazioneSelezionare l’elemento da modificare:

5. Per impostazione predefinita, il server WebSEAL iniziale è in ascolto dellerichieste su *:80 e *:443. Selezionare gli elementi di menu per le porte HTTP eHTTPS e fornire valori di porta univoci non ancora utilizzati da altri server (adesempio, 81 e 444).

Nota: Se si seleziona un valore di porta già utilizzato verrà visualizzato unmessaggio di avvertenza. Quindi, sarà possibile selezionare un differentevalore.

6. Eseguire il comando PDWeb_config per creare e configurare tutte le altreistanze del server WebSEAL (con porte inter-server univoche). Ad esempio:# ./PDWeb_config –i webseal3 –m 3233

7. Dal pannello di impostazione della configurazione, configurare valori di portaHTTP e HTTPS univoci.

Nota: Il numero massimo di istanze WebSEAL consentite è determinato dallelimitazioni della configurazione di sistema, ad esempio spazio su disco eRAM disponibile. Se si eccede una qualsiasi risorsa di sistema, vengonovisualizzati messaggi di errore della configurazione e dimalfunzionamento dell’avvio.

Configurazione di istanze multiple su interfacce di rete logica univoca:

1. Presupposto: La macchina è configurata con un server WebSEAL iniziale(pdconfig) e un singolo indirizzo IP o scheda di rete.

2. Per impostazione predefinita, il server WebSEAL iniziale è in ascolto dellerichieste su *:80 e *:443. E’ necessario assegnare uno specifico indirizzo IP perquesta interfaccia di rete iniziale prima di poter configurare ed eseguire serverWebSEAL supplementari.

Nota: I server WebSEAL supplementari non possono essere avviati se il serverWebSEAL iniziale è in ascolto su *:80 e *:443.

3. Modificare il file di configurazione webseald.conf e specificare l’indirizzo IPadatto per il server WebSEAL iniziale, mediante l’aggiunta del parametro diinterfaccia-rete alla stanza [server]. Ad esempio:[server]network-interface = 1.2.3.4

4. Riavviare il server WebSEAL:# /opt/pdweb/bin/pdweb restart

5. Per ogni ulteriore istanza del server WebSEAL, configurare un’interfaccia direte logica aggiuntiva (alias). Ad esempio (su Solaris versione 2.8):# ifconfig hme0 addif 1.2.3.5 netmask w.x.y.z up# ifconfig hme0 addif 1.2.3.6 netmask w.x.y.z up

Nota: In alternativa, è possibile assegnare ciascuna istanza WebSEAL a unascheda di rete fisica univoca pre-configurata.


7. Eseguire il comando PDWeb_config per creare e configurare un’istanzaWebSEAL aggiuntiva.


In questo scenario, le istanze multiple del server vengono rese univocheattraverso un’interfaccia di rete univoca sulle porte inter-server e di ascoltoHTTP/HTTPS comuni. Quindi, è necessario utilizzare l’opzione –n. Adesempio:# ./PDWeb_config –i webseal2 –m 3232 –n 1.2.3.5

HP-UX (network interface name = lan0:1):# ./PDWeb_config –i webseal2 –m 3232 –n lan0:1

HP-UX utilizza il nome di interfaccia di rete al posto dell’indirizzo IP. Ilprogramma di utilità PDWeb_config verifica che l’interfaccia abbia un validoindirizzo IP.

8. Viene visualizzato il pannello di impostazione della configurazione:Controllare la configurazione del server Web:1. Abilita TCP HTTP? Si2. Porta HTTP 803. Abilita HTTPS? Si4. Porta HTTPS 4435. Directory principale dei documenti Web /opt/pdweb/www-webseal2/docsa. Accetta configurazione e continua con l’installazionex. Esci dall’installazioneSelezionare l’elemento da modificare:

9. Accettare i valori di porta HTTP e HTTPS standard elencati.10. Eseguire il comando PDWeb_config per creare e configurare le ulteriori

istanze del server WebSEAL. Ad esempio:# ./PDWeb_config –i webseal3 –m 3233 -n 1.2.3.6

HP-UX (network interface name = lan0:2):# ./PDWeb_config –i webseal3 –m 3232 –n lan0:2

11. Dal pannello di impostazione della configurazione, accettare i valori di portaHTTP e HTTPS standard elencati.

Nota: Il numero massimo di istanze WebSEAL consentite è determinato dallelimitazioni della configurazione di sistema, ad esempio spazio su disco eRAM disponibile. Se si eccede una qualsiasi risorsa di sistema, vengonovisualizzati messaggi di errore della configurazione e di malfunzionamentodell’avvio.

Configurazione di istanze multiple WebSEAL su Win NT/2000Presupposti:v L’istanza iniziale del server WebSEAL è stata configuratav Le procedure descritte sono adatte per una piattaforma Windows NT/2000

Sintassi ivweb_setup:MSDOS> ivweb_setup -m <password-pdadmin> -i <nome-istanza> \-M <porta-interna> -u {yes|no} -r <porta-http> -U {yes|no} \-R <porta-https> [-n <interfaccia-rete>]

Opzione e Argomento Descrizione

–m <password-pdadmin> Password di amministrazione.

–i <nome-istanza> Nome univoco per questa istanza. E’ necessario utilizzarequesto nome per deconfigurare l’istanza. La lunghezza ditale nome è limitata a 20 caratteri.


Opzione e Argomento Descrizione

–M <porta-interna> Numero di porta univoco per la comunicazione traserver Access Manager. Il valore deve essere superiore a1023. (I valori inferiori o uguali a 1023 sono riservati.)

–u {yes|no} Abilitare/disabilitare accesso HTTP.

–r <porta-http> Numero di porta per accesso HTTP.

–U {yes|no} Abilitare/disabilitare accesso HTTPS.

–R <porta-https> Numero di porta per accesso HTTPS.

–n <interfaccia-rete> Argomento facoltativo per specificare l’indirizzo IP diun’interfaccia di rete.

Nota: Il valore di porta inter-server specificato dall’opzione –M deve essereunivoco per tutte le istanze WebSEAL.

Configurazione di istanze multiple su porte HTTP/HTTPS univoche:

1. Presupporto: Windows è configurato con un server WebSEAL iniziale(pdconfig) e scheda di rete fisoca/indirizzo IP (per questo esempio: 1.2.3.4).

2. Passare alla directory:MSDOS> cd C:\Program Files\Tivoli\Policy Director\PDWeb\bin

3. Eseguire il comando ivweb_setup per creare e configurare un’istanza WebSEALaggiuntiva.In questo scenario, le istanze multiple del server vengono rese univocheattraverso la designazione univoca della porta inter-server e della porta diascolto HTTP/HTTPS su un’interfaccia di rete comune. Quindi, non utilizzarel’opzione –n per specificare ulteriori interfacce di rete. Ad esempio:MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 81 -U yes -R 444

Nota: Se si seleziona un valore di porta già utilizzato verrà visualizzato unmessaggio di avvertenza. Quindi, sarà possibile selezionare un differentevalore.

4. Eseguire il comando ivweb_setup per creare e configurare tutte le altre istanzedel server WebSEAL. Ad esempio:MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 82 -U yes -R 445

Configurazione di istanze multiple su interfacce di rete logica univoca:

1. Presupposto: Windows è configurato con un server WebSEAL iniziale e unasongola scheda di rete o un singolo indirizzo IP.

2. Per impostazione predefinita, il server WebSEAL iniziale è in ascolto dellerichieste su *:80 e *:443. E’ necessario assegnare uno specifico indirizzo IP perquesta interfaccia di rete iniziale prima di poter configurare ed eseguire serverWebSEAL supplementari.

Nota: I server WebSEAL supplementari non possono essere avviati se il serverWebSEAL iniziale è in ascolto su *:80 e *:443.

3. Modificare il file di configurazione webseald.conf e specificare l’indirizzo IPadatto per il server WebSEAL iniziale, mediante l’aggiunta del parametro diinterfaccia-rete alla stanza [server]. Ad esempio:[server]network-interface = 1.2.3.4

4. Riavviare il server WebSEAL dal Pannello di controllo dei servizi.


5. Per ogni ulteriore istanza del server WebSEAL, configurare un’ulterioreinterfaccia di rete logica (alias) utilizzando il pannello di controllo delleconnessioni di rete. Ad esempio (su Windows 2000):a. Pannello di controllo > Collegamenti di reteb. Fare clic con il tasto destro del mouse su Collegamenti area locale e

selezionare Proprietà.c. Selezionare Internet Protocol (TCP/IP)d. Fare clic su Proprietà e selezionare Avanzatee. Dal separatore Impostazioni IP, fare clic su Aggiungif. Immettere un indirizzo IP per la nuova interfaccia di reteg. Immettere una maschera di sottoreteh. Fare clic su Aggiungii. Aprire una finestra prompt di comandi e immettere:

MSDOS> ipconfig -all

Tutte le interfacce di rete dovrebbero apparire come in ascolto.j. Ripetere questi passi per ulteriori interfacce di rete

6. Passare alla directory:MSDOS> cd C:\Program Files\Tivoli\PDWeb\bin

7. Eseguire il comando ivweb_setup per creare e configurare un’istanza WebSEALaggiuntiva.In questo scenario, le istanze multiple del server vengono rese univocheattraverso un’interfaccia di rete univoca sulle porte inter-server e di ascoltoHTTP/HTTPS comuni. Quindi, è necessario utilizzare l’opzione –n. Adesempio:MSDOS> ivweb_setup -m xxxxx –i webseal2 –M 3232 -u yes -r 80 -U yes \-R 443 -n 1.2.3.5

8. Eseguire il comando ivweb_setup per creare e configurare tutte le altre istanzedel server WebSEAL. Ad esempio:MSDOS> ivweb_setup -m xxxxx –i webseal3 –M 3233 -u yes -r 80 -U yes \-R 443 -n 1.2.3.6

Annullamento della configurazione di istanze multipleWebSEAL

Non è possibile annullare la configurazione del server WebSEAL iniziale fino aquando non viene annullata la configurazione di tutte le istanze del server.

UNIX:PDWeb_unconfig -i <nome-istanza>


2. Eseguire il comando PDWeb_unconfig per ogni istanza. Ad esempio:# ./PDWeb_unconfig -i webseal2# ./PDWeb_unconfig -i webseal3

Windows:ivweb_uninst -deconfig -m <password-pdadmin> -i <nome-istanza>

1. Passare alla directory:MSDOS> cd C:\Program Files\Tivoli\PDWeb\bin

2. Eseguire il comando ivweb_uninst per ogni istanza. Ad esempio:


MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal2MSDOS> ivweb_uninst -deconfig -m xxxxxx -i webseal3

Comandi di avvio, arresto, riavvio e stato del serverUNIX:

Il programma di utilità pdweb fornisce capacità di avvio, arresto, riavvio e verificadello stato per il server WebSEAL iniziale e tutte le altre istanze multiple delserver. E’ anche possibile applicare un comando a una specifica istanza del server.pdweb {start|stop|restart|status} [<instance-name>]

Esempi:

Per avviare il server WebSEAL iniziale e tutte le istanze del server configurate:# /usr/bin/pdweb start

Per avviare solo una specifica istanza del server:# /usr/bin/pdweb start webseal3

Per riavviare il server WebSEAL iniziale e tutte le istanze del server configurate:# /usr/bin/pdweb restart

Per arrestare il server WebSEAL iniziale e tutte le istanze del server configurate:# /usr/bin/pdweb stop

Per arrestare solo una specifica istanza del server:# /usr/bin/pdweb stop webseal3

Per visualizzare lo stato di tutti i server configurati:# /opt/PolicyDirector/bin/pd_start statusServer Access ManagerServer Abilitato In esecuzione------------------------------------------pdmgrd yes yespdacld yes yeswebseald yes yeswebseald-webseal2 yes yeswebseald-webseal3 yes yes

Windows:

Il pannello di controllo dei servizi di Windows fornisce informazioni sull’avvio,sull’arresto e sullo stato.

In alternativa, il comando net fornisce capacità di avvio e di arresto per il serverWebSEAL iniziale e per tutte le istanze multiple del server.net {start|stop} <nome-istanza>

Esempi:

Per avviare il server WebSEAL iniziale e tutte le istanze del server configurate(ripetere il comando per ciascuna istanza):MSDOS> net start websealdMSDOS> net start webseal2MSDOS> net start webseal3


Per arrestare il server WebSEAL iniziale e tutte le istanze del server configurate(ripetere il comando per ciascuna istanza):MSDOS> net stop websealdMSDOS> net stop webseal2MSDOS> net stop webseal3

Per visualizzare lo stato di tutti i server configurati:Start > Impostazioni > Pannello di controllo > Servizi

Configurazione SU (switch user) per i responsabiliLa funzionalità SU (switch user) di WebSEAL consente a specifici responsabili diassumere l’identità di un utente membro del dominio protetto Access Manager.L’implementazione switch user è simile al comando su in ambienti UNIX.Nell’ambiente WebSEAL, il responsabile acquisisce le credenziali dell’utente einteragisce con le risorse e le applicazioni back-end nello stesso modo dell’utenteeffettivo.

La funzione switch user può essere utilizzata in un ambiente Help Desk perrisolvere o diagnosticare problemi. Questa funzione può anche essere utilizzata perverificare l’accesso di un utente alle risorse ed eseguire il test di integrazioneapplicazioni.

Le descrizioni seguenti evidenziano le importanti caratteristiche della funzioneswitch user:v La funzione switch user non richiede la password dell’utente.v Il responsabile utilizza una credenziale che rappresenta l’utente effettivo.v La funzione switch user è limitata ai membri del gruppo di uno speciale

responsabile. Un responsabile non può effettuare lo scambio utente con nessunaltro membro di tale gruppo.

v I processi Access Manager, sec_master e altri utenti selezionati possono essereesclusi dalla funzione switch user attraverso l’appartenenza ad un gruppo diesclusione.

v Un modulo HTML speciale viene utilizzato per fornire informazioni switch usered attivare uno speciale meccanismo di autenticazione che restituisce lacredenziale dell’utente specificato senza richedere una password.

v Il responsabile utilizza il programma di utilità pkmslogout per terminare unasessione switch user.

Comprensione del flusso del processo switch userLa seguente sequenza descrive il flusso del processo della funzione switch user:

1. Presupposti: Il responsabile (un membro del gruppo su-admins) è statoautenticato in WebSEAL, è stata stabilita una sessione ed è stata creataun’immissione per il responsabile nella cache di sessione/credenzialiWebSEAL.

2. Il responsabile si collega a un modulo HTML switch user pre-configurato.Questo modulo è accessibile solo da parte dei membri del gruppo su-admins.

3. Il modulo switch user viene completato e restituito con le seguentiinformazioni: nome utente (il responsabile viene “convertito” in questoutente), un URL di destinazione e un metodo di autenticazione.Questa azione determina l’invio di una richiesta POST a /pkmssu.form.

4. Una speciale autenticazione switch user viene eseguita dalla libreria condivisadi switch user incorporata oppure da una libreria CDAS di switch user


personalizzata. La libreria switch user (personalizzata o incorporata)restituisce una valida credenziale per l’utente, senza richiedere l’immissione diuna password.

5. Durante l’autenticazione switch user, WebSEAL controlla i gruppi AccessManager su-admins, securitygroup e su-excluded per assicurarsi che il nomeutente fornito nel modulo switch user non è un membro di uno di questigruppi.

6. Dopo la riuscita dell’autenticazione dell’utente designato, viene creata unanuova struttura dati di cache contenente la credenziale dell’utente.

7. I dati della cache originale del responsabile vengono rimossi dalla voce dellacache di sessione WebSEAL del responsabile e memorizzati in un’ubicazioneseparata. I dati della cache dell’utente prendono il loro posto. Ora la vocedella cache contiene l’ID sessione originale del responsabile e i dati della cachedell’utente (con la credenziale). La credenziale contiene anche un nuovo IDsessione utente che può essere utilizzato per qualsiasi situazione di gestionedella sessione utente. La voce della cache di sessione è indicizzata dalresponsabile mediante lo stesso ID sessione prima dell’operazione switch user.

8. WebSEAL esegue un reindirizzamento (redirect) al browser dell’URL didestinazione fornito nel modulo switch user.

9. La richiesta viene elaborata normalmente, utilizzando la credenzialedell’utente, e si accede all’URL. Il responsabile può continuare ad effettuarealtre richieste. Tutte le decisioni relative alle autorizzazioni per tali richiestesono basate sulla credenziale dell’utente.

10. Il responsabile termina la sessione switch user utilizzando il programma diutilità standard Access Manager /pkmslogout.

11. Una volta terminata la sessione, i dati della cache dell’utente vengonocancellati e i dati della cache originale del responsabile (e la credenziale)vengono ripristinati. Il responsabile ritorna alla pagina originale da cui erastato richiesto il modulo switch user. Il servizio di autorizzazione utilizza lacredenziale originale del responsabile per tutte le successive richieste.

Abilitazione della funzione switch user: riepilogoPer abilitare la funzionalità switch user:

Cache sessione/credenziali WebSEAL

ID sessione Dati cache

1234 - credenziali utente- altri dati utente

vocecacheadmin

- credenziali admin- altri dati admin

ID sessione originaleamministratore

dati cache utenterestituiti dalla

autenticazione SU

dati cache amministratorememorizzati durante il SU

Figura 15. Scambio di dati del responsabile e della cache utente durante l’operazione switchuser


1. Decommentare i meccanismi di autenticazione appropriati in webseald.conf eaggiungere il percorso per la libreria condivisa che gestisce l’operazione switchuser.

2. Utilizzare il programma di utilità pdadmin per aggiungere responsabiliall’account del gruppo su-admins.

3. Utilizzare il programma di utilità pdadmin per aggiungere utenti all’accountdel gruppo su-excluded.

4. Facoltativamente, modificare il modulo switchuser.html per specificare datipre-configurati, ad esempio il metodo di autenticazione e l’URL di destinazione.

5. Facoltativamente, creare altri moduli per convalidare o elaborare i dati dainoltrare a /pkmssu.form.

Configurazione del modulo HTML switch userIl modulo switch user è definito nella stanza [acnt-mgt] del file di configurazionewebseald.conf.v Il parametro switch-user specifica il nome del file. Per impostazione predefinita,

il nome file è switchuser.html:[acnt-mgt]switch-user = switchuser.html

v Il parametro mgt-pages-root specifica l’ubicazione della sottodirectory per ladirectory di localizzazione contenente questo file:[acnt-mgt}mgt-pages-root = lib/html/<LANG>

Su sistemi US English, la directory LANG è chiamata “C”.v Il segmento di percorso lib/html è collegato al valore del parametro server-root

:UNIX:[server]server-root = /opt/pdweb/www

Windows:[server]server-root = C:/Program Files/Tivoli/PDWeb/www

Il modulo switch user può essere modificato per personalizzare aspetto efunzionalità. Il modulo contiene richieste di:v Nome utente (il responsabile viene “commutato” in questo utente)

Questo utente non può essere membro dei gruppi su-excluded, su-admins osecuritygroup.

v URL di destinazione

Questa pagina viene visualizzata dopo un’operazione switch user riuscita. E’possibile configurare questo campo come immissione nascosta contenente unahome page adatta oppure una pagina di conferma della riuscita di switch user.

v Metodo di autenticazione

Il metodo di autenticazione determina il tipo di informazioni utilizzate percreare la credenziale dell’utente. E’ possibile configurare questo campo comeimmissione nascosta. Per un elenco dei parametri validi di metodo diautenticazione, fare riferimento alle note seguenti.

Il modulo switch user predefinito appare come riportato di seguito:


Note del modulo switch user:

v Il modulo è disponibile solo ai membri del gruppo su-admins. Non è richiestoun ACL su questo file. WebSEAL esegue un controllo internamente codificato diappartenenza al gruppo. WebSEAL restituisce un errore 404 “Non trovato”quando il controllo di appartenenza al gruppo ha esito negativo.

v Nome utente, URL di destinazione e metodo di autenticazione sono tutti datinecessari.

v I dati necessari possono essere incorporati nel modulo come campi nascosti.v WebSEAL verifica che tutti i dati necessari siano presenti nel modulo inoltrato.

Se mancano dei dati, il modulo viene restituito al responsabile con un messaggiodescrittivo.

v I valori validi per il metodo di autenticazione includono:su-basu-formssu-certificatesu-token-cardsu-http-requestsu-cdsso

Questi parametri di metodo di autenticazione specificano il meccanismo diautenticazione utilizzato da WebSEAL.

v Entrambi i metodi su-ba e su-forms vengono associati al meccanismo diautenticazione su-password specificato nel file di configurazione webseald.conf.

v I dati del modulo switch user vengono inoltrati all’URL di azione /pkmssu.form.

Abilitazione ed esclusione di utenti da switch userSolo i responsabili membri del gruppo su-admins possono utilizzare la funzioneswitch user e ricevere il modulo HTML switch user. La funzionalità switch user èabilitata per tutti gli utenti membri del gruppo su-admins.

I responsabili possono utilizzare la funzione switch user su qualsiasi accountAccess Manager, ad eccezione di quelli appartenenti a determinati gruppi. E’possibile escludere altri utenti Access Manager dalla funzione switch userinserendoli nel gruppo su-excluded. Inoltre, i membri del gruppo Access Managersecuritygroup sono esclusi dalla funzionalità switch user. Generalmente,sec_master e i processi Access Manager sono membri di securitygroup.

Figura 16. Modulo di dati switch user


Durante la funzione switch user, WebSEAL esegue il controllo su tutti e tre igruppi. Non è possibile, quindi, “commutarsi” in un utente che è membro deigruppi su-admins, su-excluded o securitygroup.

Configurazione del meccanismo di autenticazione switch userLa prima responsabilità del meccanismo di autenticazione switch user (una libreriacondivisa incorporata) è di creare una credenziale che rappresenta l’utente“commutato”, basata sul nome utente e sul metodo di autenticazione forniti, senzala richiesta di immissione di una password. Un meccanismo di autenticazioneCDAS personalizzato deve soddisfare agli stessi requisiti.

I meccanismi di autenticazione switch user vengono specificati nella stanza[authentication-mechanisms] del file di configurazione webseald.conf. Sonosupportati i seguenti meccanismi di autenticazione:[authentication-mechanisms]#su-password = <su-password-library>#su-token-card = <su-token-card-library>#su-certificate = <su-certificate-library>#su-http-request = <su-http-request-library>#su-cdsso = <su-cdsso-library>

Access Manager fornisce una singola libreria switch user che può essere utilizzataper abilitare uno qualsiasi dei precedenti meccanismi in un ambiente predefinito enon personalizzato. La libreria switch user differisce dalle librerie di autenticazionestandard. La libreria specifica un meccanismo di autenticazione che assumel’identità dell’utente (fornita nel modulo switch user) e restituisce una validacredenziale per tale utente, senza richiedere l’immissione di una password.

La libreria condivisa switch user incorporata fornita con Access Manager èchiamata:

Solaris libsuauthn.so

AIX libsuauthn.a

HP-UX libsuauthn.sl

Windows suauthn.dll

La funzionalità switch user supporta anche meccanismi di autenticazione CDASpersonalizzati. Questo supporto è importante dato che un CDAS personalizzatooffre spesso informazioni supplementari per la credenziale dell’utente.

L’utente è responsabile della scrittura di un CDAS switch user personalizzato cherispecchi il comportamento del CDAS esistente durante il supporto del requisito direstituzione di una credenziale senza la richiesta di immissione della passwordutente. Fare riferimento a IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Ogni libreria di autenticazione switch user configurata deve essere denominata inmodo univoco, anche se la libreria predefinita (libsuauthn) è utilizzata per piùmetodi di autenticazione.

EsempioNell’esempio seguente (per una piattaforma Solaris), un ambiente esistentepresenta tre metodi di autenticazione abilitati:1. Autenticazione moduli mediante la libreria incorporata libldapauthn

2. Autenticazione certificati mediante la libreria incorporata libsslauthn


3. Autenticazione token mediante un meccanismo CDAS personalizzato

L’ambiente viene espanso per supportare la funzionalità switch user per i tremetodi di autenticazione. Tre parametri di autenticazione supplementari per switchuser devono essere abilitati nel file di configurazione webseald.conf. Inoltre, unanuova libreria CDAS personalizzata deve essere scritta per emulare il CDAS tokenesistente e supportare i requisiti dell’autenticazione switch user:[authentication-mechanisms]passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.socert-ssl = /opt/PolicyDirector/lib/libsslauthn.sotoken-cdas = /opt/PolicyDirector/lib/libcustom.sosu-password = /opt/PolicyDirector/lib/libsuformauthn.sosu-certificate = /opt/PolicyDirector/lib/libsucert.sosu-token-card = /opt/PolicyDirector/lib/libsucustom.so

Ricordare che il metodo di autenticazione su-forms fornito nel modulo switch userè associato al parametro del meccanismo di autenticazione su-password inwebseald.conf. In aggiunta, la libreria libsuauthn fornita è stata ridenominata perentrambi i meccanismi di Moduli e certificato.

Configurazione di un meccanismo switch user CDASUn meccanismo di autenticazione CDAS esistente spesso restituisce informazioniaggiuntive relative all’utente incorporate nella credenziale utente. Se si stautilizzando la funzione switch user in un ambiente del genere, è necessario scrivereun CDAS switch user speciale che emuli il comportamento del proprio CDASesistente durante il supporto del requisito di restituzione di una credenziale senzala richiesta di immissione della password utente.

L’API CDAS Access Manager fornisce una serie di componenti di identità chepossono essere utilizzati per trasmettere informazioni di autenticazione client allalibreria CDAS switch user condivisa. Tali informazioni vengono trasmesseutilizzando un formato di elenco nome/valore, in cui il nome è rappresenta unidentificativo che specifica il tipo di valore.

Le informazioni sono memorizzate nel tipo xnlist_t data. E’ possibile accedere aivalori mediante la funzione di utilità xnvlist_get().

I componenti di identità adatti per un CDAS switch user includono:xauthn_su_methodxauthn_admin_namexauthn_admin_credxauthn_existing_credxauthn_usernamexauthn_qopxauthn_ipaddrxauthn_browser_info

I componenti di identità xauthn_browser_info, xauthn_qop e xauthn_ipaddrrappresentano quelli del responsabile, e non quelli dell’utente “commutato”. Questidati vengono forniti per ogni CDAS che deve eseguire convalide supplementaridell’account del responsabile.

Per informazioni complete e materiale di riferimento relativo alla scrittura di unCDAS personalizzato, fare riferimento a IBM Tivoli Access Manager WebSEALDeveloper’s Reference.


Impatto su altre funzionalità di WebSEAL

Impatto sulla configurazione del timeout della cache di sessioneLa funzionalità dei valori di timeout della durata e dell’inattività della cache disessione WebSEAL configurata non è influenzata dall’operazione switch user. Itimer di durata e inattività sono associati alla voce della cache di sessione delresponsabile e non ai dati di cache che vengono modificati durante un’operazioneswitch user.

Il timer di inattività continua ad essere reimpostato mentre il responsabile eseguerichieste come utente “commutato”. Quando il responsabile termina la sessioneswitch user, l’inattività è ancora valida per la sessione del responsabile ristabilita.

Il valore di inattività non viene esteso a causa di un’operazione switch user. E’possibile che il timeout di durata della voce di cache di sessione possa scaderedurante un’operazione switch user. Se si verifica tale timeout, la cache di sessioneviene cancellata e il responsabile viene scollegato. Il responsabile dovrà eseguire lariautenticazione e iniziare nuovamente l’operazione switch user.

Inserimento di livelli di autenticazione a fasiLa specifica della libreria condivisa può assumere argomenti aggiuntivi nelmodulo:<libreria>&<arg1> <arg2> .... <argx>

E’ possibile indicare livelli di autenticazione a fasi utilizzando l’opzione –l seguitadal numero di livello. Ad esempio:su-password = /opt/PolicyDirector/lib/libsuformauthn.so& -l 1su-certificate = /opt/PolicyDirector/lib/libsucert.so& -l 0su-token-card = /opt/PolicyDirector/lib/libsucustom.so& -l 2

Nota: Per questa versione di Access Manager, il responsabile deve conoscere lapassword dell’utente per eseguire correttamente l’autenticazione a fasi.

Supporto per la riautenticazioneLa funzionalità di riautenticazione WebSEAL viene riconosciuta dall’operazioneswitch user. Se la riautenticazione è richiesta durante un’operazione switch user, ilresponsabile deve autenticarsi come utente “commutato”.

Nota: Per questa versione di Access Manager, il responsabile deve conoscere lapassword dell’utente “commutato” per effettuare correttamente lariautenticazione.

Supporto per la gestione di sessione utenteL’operazione switch user supporta la gestione della sessione utente. Il responsabileha un ID sessione utente univoco. In aggiunta, durante un’operazione switch user,un ID sessione utente univoco è disponibile per l’utente “commutato”. Le attivitàTermine sessioni di un singolo utente e Termine sessioni di tutti gli utenti vengonoeseguite come previsto.

Supporto per tag-valoreLa capacità tag-valore spesso utilizzata da CDAS è riconosciuta e supportata dallafunzionalità switch user.


Audit del responsabile durante switch userE’ possibile effettuare l’audit del responsabile durante un’operazione switch user.La funzionalità switch user aggiunge un attributo esteso alla credenziale dell’utente“commutato” che identifica il responsabile. L’attributo esteso è denominatosu-admin:su-admin = <su-admin-name>

Questo attributo esteso è disponibile per qualsiasi meccanismo di audit.

Configurazione cache di richieste WebSEAL del server

Informazioni secondarieNelle precedenti versioni di WebSEAL che utilizzavano l’autenticazione Moduli,WebSEAL creava una voce di cache per l’URL di una richiesta utente ogni voltache l’autenticazione era richiesta. Dopo una corretta autenticazione, WebSEALinviava un redirect HTTP al browser che comprendeva questo URL. Il browser,quindi, seguiva il redirect nell’ubicazione della risorsa originale.

La limitazione di questa implementazione era evidente quando, ad esempio, unarichiesta POST veniva interrotta da un timeout di sessione che richiedeva unprocesso di ri-autenticazione. Poiché WebSEAL memorizzava nella cache solol’URL della richiesta originale, i dati POST (incluso il corpo del messaggio e ilmetodo) venivano persi durante il reindirizzamento HTTP. L’utente doveva,quindi, ricreare la richiesta POST.

Ora WebSEAL memorizza nella cache una serie più completa di dati della richiestae utilizza tali dati di cache per ricreare la richiesta durante il reindirizzamentoHTTP, se un requisito di ri-autenticazione interrompe il completamentodell’elaborazione della richiesta. Questa soluzione avvantaggia particolarmente lerichieste POST e PUT, poiché questi tipi di richiesta possono includere una varietàdi campi informativi.

Flusso del processo di cache del serverQuando un requisito di autenticazione interrompe una richiesta, WebSEALmemorizza nella cache tutte le informazioni necessarie per ricostruire la richiestadurante il reindirizzamento HTTP che segue la ri-autenticazione. I dati dellarichiesta memorizzati nella cache comprendono URL, METODO, Corpo delmessaggio, stringhe di query e tutte le intestazioni HTTP (incluso i cookie). Questidati vengono temporaneamente memorizzati nella cache di sessione/credenziali diWebSEAL.

Dopo un’autenticazione (o una ri-autenticazione) riuscita, WebSEAL invia unredirect HTTP al browser. Il browser segue il reindirizzamento all’URL originalecontenuto nel redirect. WebSEAL intercetta il redirect e ricostruisce la richiestautilizzando i dati nella cache. La richiesta ricostruita viene quindi consegnataall’URL di destinazione.

Il diagramma seguente illustra un tipico flusso del processo di memorizzazionenella cache di una richiesta del server:1. L’utente si collega correttamente (autenticazione Moduli) e inoltra una richiesta

HTTP per una risorsa coinvolgendo un modulo dati generato da CGI.WebSEAL crea un ID sessione per l’utente e lo memorizza nella cache.

2. Il server di applicazioni back-end restituisce il modulo all’utente.


3. Durante il tempo in cui l’utente compila il modulo, il timeout di sessioneconfigurato per l’utente scade. WebSEAL rimuove la voce della cache dicredenziali dell’utente e l’ID sessione.

4. L’utente finalmente inoltra il modulo compilato (POST). WebSEAL non rilevaalcuna voce di cache per l’utente, crea una nuova cache e vi memorizzatemporaneamente le informazioni complete contenute nella richiesta POST.

5. Poiché WebSEAL non trova alcuna credenziale per tale utente, l’utente deveeseguire l’autenticazione. WebSEAL invia all’utente un modulo di login.

6. L’utente restituisce il modulo di login compilato a WebSEAL (POST).L’autenticazione ha avuto esito positivo. Ora la cache contiene le credenzialidell’utente e anche la richiesta.

7. WebSEAL invia nuovamente un redirect HTTP al browser contenente l’URLdella risorsa originariamente richiesta.

8. Il browser segue il reindirizzamento (GET). WebSEAL intercetta il redirect ericostruisce la richiesta originale (modulo) mediante i dati POST presenti nellacache. La richiesta ripristinata (modulo) viene consegnata all’URL didestinazione.

Configurazione di parametri di cache del serverSebbene la memorizzazione cache delle richieste avvenga automaticamente perl’autenticazione Moduli di WebSEAL, è possibile specificare limiti alla dimensionedelle richieste che WebSEAL memorizza nella cache. I parametri request-max-cachee request-body-max-read sono ubicati nella stanza [server] del file diconfigurazione webseald.conf.

Client WebSEALServer delleapplicazioni

Web

nodo

registrazione e richiesta richiesta

modulo applicazione

tim e out di sessi one

inoltro modulo memorizzazionedati richiesta

pagina registrazione moduli

autenticazione

reindirizzamento HTTP

il browser segueil reindirizzamento (GET)

i dati della richiestaoriginale vengono ricevuti

WebSEAL intercetta efornisce i datimemorizzati

1

2

4

5

6

7

8

3

Figura 17. Esempio del flusso di processo di cache di una richiesta WebSEAL


request-max-cache

Il parametro request-max-cache specifica la quantità massima di dati, espressa inbyte, che WebSEAL memorizza nella cache per ciascuna richiesta. Ad esempio:[server]request-max-cache = 8192

Come descritto di seguito, è necessario considerare il valore del parametrorequest-body-max-read quando si specifica request-max-cache.

request-body-max-read

Il parametro request-body-max-read specifica la dimensione massima del corpo dimessaggio della richiesta, in byte, che WebSEAL memorizza nella cache perciascuna richiesta. Questo parametro influenza in modo specifico i tipi di richiesteche contengono dati del corpo del messaggio, quali le richieste POST e PUT. Adesempio:[server]request-body-max-read = 4096

Questo parametro non limita la dimensione massima POST (che è illimitata) per lerichieste che non richiedono autenticazione.

Notare che il valore del parametro request-max-cache deve conformarsicorrettamente al valore di request-body-max-read più la dimensione di tutti glialtri componenti della richiesta. Ad esempio, se si specificano 2048 byte comelimite di cache per i corpi dei messaggi della richiesta e si prevede una dimensionemassima di tutti gli altri componenti della richiesta (intestazioni, cookie) di 4096byte,1. impostare request-body-max-read = 20482. impostare request-max-cache = 2048 + 4096 = 6144

Se le impostazioni di request-body-max-read o request-max-cache vengonosuperate durante una richiesta, WebSEAL interrompe il processo di cache dellarichiesta, restituisce un messaggio di errore Cache di richiesta non riuscita albrowser e riporta l’errore nel file di log. Questo messaggio di errore può esserepersonalizzato. Consultare “Gestione delle pagine di messaggi di errore HTTPpersonalizzate” a pagina 31.

Note e limitazioniv Il valore request-body-max-read influenza anche le richieste di URL dinamici,

dato che la porzione query della richiesta POST è contenuta nel corpo dimessaggio della richiesta.

v Il valore request-body-max-read influenza anche l’autenticazione Moduliinserendo un limite alla dimensione dei dati POST elaborati durantel’autenticazione.

v I parametri request-body-max-read e request-max-cache proteggono WebSEALda tipi di attacco di rifiuto del servizio che provocano da parte di WebSEAL lamemorizzazione nella cache di più dati di quanti esso possa gestire.

v La funzione di cache delle richieste del server non funzionerà correttamente se ilvalore di timeout della sessione utente scade durante il processo di login. In talesituazione, la voce della cache viene persa.

v La cache di richieste del server può causare limitazioni alla capacità del browserdi manipolare la risorsa. Il browser non è in grado di sapere che WebSEAL ha


ricostruito il redirect HTTP. Quindi, la funzione di ricaricamento/aggiornamentoe la capacità di caching del browser potrebbero essere ostacolate.

Gestione dei caratteri codificati UTF-8In base alle specifiche HTTP, i browser sono limitati all’insieme di caratteri che puòessere legalmente utilizzato all’interno di un URL. Questa gamma viene definitaper rappresentare i caratteri stampabili nell’insieme di caratteri ASCII (tra il codiceesadecimale 0x20 e 0x7e). Per lingue diverse dall’inglese, e per altri scopi, icaratteri al di fuori dell’insieme di caratteri ASCII stampabili sono spesso richiestinell’URL. Tali caratteri possono essere codificati utilizzando caratteri stampabili perla trasmissione e l’interpretazione.

Esiste una serie di differenti metodi di codifica per la trasmissione di caratteri al difuori della gamma consentita. Malgrado le specifiche HTTP, esistono anche moltiserver Web commerciali che tollerano ed accettano semplicemente caratteri diversida quelli della gamma legale. WebSEAL, agendo come proxy Web, deve essere ingrado di gestire queste situazioni.

Il metodo di codifica dei caratteri più largamente accettato (“de facto standard”) èUTF-8. Molti dei server Web commerciali correnti possono essere configurati perpermettere la codifica UTF-8.

Il parametro utf8-url-support-enabled nella stanza [server] del file diconfigurazione webseald.conf controlla il modo in cui WebSEAL interpreta gli URLinviati dai browser. Il parametro riconosce tre impostazioni:v yes

WebSEAL riconosce solo la codifica UTF-8 in stringhe di URL e decodifica leinformazioni nell’insieme di caratteri nativi (codepage locale). Altre tecniche dicodifica, come DBCS (double byte character set) e Unicode, non sono accettate.

v no

WebSEAL non riconosce la codifica UTF-8 nelle stringhe URL. Qualsiasiinformazione codificata UTF-8 non viene interpretata correttamente. Sonoaccettate altre tecniche di codifica.

v auto

WebSEAL tenta di distinguere tra UTF-8 e altre forme di codifica dei caratteri(DBCS e Unicode). WebSEAL elabora in modo corretto qualsiasi codifica UTF-8correttamente costruita. Se la codifica non sembra essere UTF-8, il codice vieneelaborato come DBCS o Unicode.

Quando utf8-url-support-enabled è impostato su “yes” (predefinito), WebSEALpresuppone che gli URL possano includere caratteri codificati UTF-8. Tali caratteriUTF-8 vengono quindi convalidati e inseriti nell’account durante la determinazionedei diritti di accesso all’URL. L’URL viene normalizzato (cioé, i caratteri codificativengono convertiti negli equivalenti della codepage locale), e ad esso vieneapplicato il controllo ACL. L’impostazione predefinita non accetta URL concaratteri DBCS o Unicode del formato %uXXXX. Questa rappresenta laconfigurazione consigliata per WebSEAL.

Alcuni server Web e alcune applicazioni esistenti non funzionano correttamentecon WebSEAL se è abilitato il supporto UTF-8, poiché tali applicazioni utilizzanoDBCS (come Shift-JIS) nell’URL oppure altri meccanismi di codifica.


Se questa è la situazione della propria distribuzione, è necessario eseguire le dueseguenti attività:1. Modificare webseald.conf e impostare il nuovo parametro nel modo seguente:

utf8-url-support-enabled = no

2. Assicurarsi che tutti i server di junction NON accettino URL codificati UTF-8.Dal punto di vista della sicurezza, è importante che WebSEAL interpreti nellastessa maniera URL e server di junction.

La strategia di distribuzione consigliata è quindi la seguente:1. A meno che non sia richiesto per altri scopi, selezionare e impostare

immediatamente l’ACL default-webseal delle distribuzioni di produzioneesistenti per NON consentire accessi “r” non autenticati. Ciò limital’esposizione della sicurezza agli utenti che hanno un account valido all’internodel dominio Access Manager.

2. Assicurarsi che il parametro utf8-url-support-enabled sia impostato sul valorepredefinito “yes”.

3. Provare le applicazioni. Se il funzionamento è corretto, utilizzare questaimpostazione.

4. Se un’applicazione non riesce con errori “Richiesta non corretta”, riprovarel’applicazione con il parametro utf8-url-support-enabled impostato su “no”. Sein questo modo funziona, è possibile eseguire la distribuzione con il parametroimpostato su “no”. Tuttavia, è anche necessario assicurarsi che nessun serverWeb di junction sia configurato per accettare URL codificati UTF-8.

Prevenzione della vulnerabilità causata da scripting cross-siteLo scripting cross-site si riferisce a una tecnica utilizzata per provocare lavulnerabilità del server Web mediante l’inserimento di codice doloso negli URL dirichieste Web. WebSEAL fornisce una certa protezione incorporata per questo tipodi vulnerabilità e consente all’utente di raffinare ulteriormente la protezionemediante la configurazione di una funzione di filtro delle stringhe URL.

Nota: Il termine “scripting cross-site”, sebbene accettato comunemente, nondescrive completamente l’insieme di elementi che coinvolgono il codicedoloso inserito.

Informazioni secondarieLo scripting cross-site è un tipo specifico di vulnerabilità del server Web creatoquando una richiesta URL del client include scripting doloso inserito. Ad esempio(Javascript):<script>codice_doloso</script>

Altre tag di scripting che possono essere utilizzate per creare la vulnerabilità sono<OBJECT>, <APPLET> e <EMBED>. Quando un utente fa clic su un collegamentocontenente il codice doloso (oppure lo immette direttamente come URL), lo scriptviene eseguito nel momento in cui l’HTML viene letto dal browser dell’utente.

Ad esempio, un attacco del genere può verificarsi quando un utente fa clic su uncollegamento che contiene il seguente URL:https://<webseal-host>/<script>codice_doloso</script>


In questo esempio, l’oggetto non viene trovato e WebSEAL risponde restituendouna pagina di errore HTML 404 “Impossibile trovare la pagina”. Questa pagina dierrore si verifica perché include l’URL contenente il Javascript doloso. Il browserinterpreta l’URL ed esegue lo script.

Fare riferimento al consultivo CERT seguente per informazioni complete suimeccanismi di scripting cross-site e su misure preventive generali:

http://www.cert.org/advisories/CA-2000-02.html

Configurazione del filtro di stringa URLIl problema dello scripting cross site e del codice doloso inserito vienegeneralmente gestito in due modi.

WebSEAL codifica parentesi ad angolo (<, >) negli URL reindirizzati. La codificapuò essere utile per prevenire la normale interpretazione degli script da parte delbrowser.

Inoltre, è ora possibile aggiungere una nuova stanza al file di configurazionewebseald.conf. La stanza, [illegal-url-substrings], può contenere parametri chespecificano uno o più frammenti di stringa. Ad esempio:[illegal-url-substrings]substring = <scriptsubstring = <appletsubstring = <embed

Se WebSEAL rileva uno dei frammenti di stringa configurati nell’URL richiesto,l’URL viene giudicato illegale e non accettato. WebSEAL restituisce una pagina dierrore 400 “Richiesta non corretta”.

Questo flessibile meccanismo consente all’utente di gestire futuri schemi di attaccoattraverso l’aggiunta di valori aggiuntivi di stringa secondari.

WebSEAL, per impostazione predefinita, filtra le stringhe contenenti <script. Non ènecessario aggiungere manualmente la stanza [illegal-url-substrings] per filtrarequesta particolare stringa. Tuttavia, quando è richiesta una funzione di filtrosupplementare, è necessario creare la stanza ed elencare singolarmente tutte lestringhe secondarie, come nell’esempio precedente.

E’ possibile disabilitare completamente la funzione di filtro delle stringhe URL(incluso il comportamento predefinito) inserendo una stanza [illegal-url-substrings] vuota nel file webseald.conf.

Note funzionali:v Le stringhe secondarie vengono localizzate mediante una ricerca non sensibile ai

caratteri maiuscoli e minuscoliv La funzione di filtro delle stringhe secondarie accetta i caratteri multi-bytev Il meccanismo protegge i server di junction

Soppressione dell’identità del serverLe risposte del server HTTP normalmente contengono l’identità e la versione delserver:


content-type: text/htmldate: Tue, 05 Mar 2002 02:34:18 GMTcontent-length: 515server: WebSEAL/3.9.0last-modified: Thu, 21 Feb 2002 08:03:46 GMTconnection: close

Per ragioni di sicurezza, può essere necessario che WebSEAL debba rimuoverequeste informazioni nelle proprie risposte ai client. Per rimuovere l’identità delserver dalle risposte del server HTTP, impostare il parametro suppress-server-identity della stanza [server] del file di configurazione webseald.conf su “yes”:[server]suppress-server-identity = yes

L’impostazione predefinita è “no”.

Utilizzo di statistiche WebSEALWebSEAL fornisce una serie di moduli software incorporati che, quando abilitati,possono controllare l’attività del server specifico e raccogliere informazioni su taliattività. In qualsiasi momento, è possibile visualizzare le informazioni di statisticheraccolte a partire dall’abilitazione del modulo. In aggiunta, è possibile indirizzarequeste informazioni statistiche ai file di log.

Quando si visualizzano informazioni statistiche, viene mostrata un’“istantanea”delle informazioni a partire dal momento in cui il modulo è stato abilitato. Leinformazioni raccolte dalle statistiche WebSEAL offrono una vista relativadell’attività in registrazione. Se le statistiche vengono catturate ad intervalli regolariin un periodo di tempo, è possibile generare una vista grafica delle relazioni cheintercorrono tra le attività del server.

Sintassi del comando pdadmin statsUtilizzare il comando pdadmin stats per gestire i componenti di statistiche. Questasezione descrive le operazioni valide per il comando pdadmin stats:

Comando pdadmin stats di basepdadmin> server task webseald-<istanza> stats <comando>

Con il comando pdadmin stats è possibile effettuare le seguenti attività:

stats on Abilitare le statistiche in modo dinamico, per componente

stats off Disabilitare le statistiche, per componente o su tutti i componenticontemporaneamente

stats show Elencare i componenti abilitati

stats get Visualizzare i valori delle statistiche correnti per componente o per tutti icomponenti contemporaneamente

stats reset Reimpostare i valori delle statistiche per componente o per tutti icomponenti contemporaneamente

stats list Elencare tutti i componenti di statistiche disponibili

Abilitare le statistiche in modo dinamicoE’ possibile abilitare il report delle statistiche in modo dinamico con il comandopdadmin stats on oppure in modo statico con i parametri di configurazione del filewebseald.conf.


Utilizzare il comando pdadmin stats on per abilitare la raccolta delle statistiche eimpostare la frequenza del report, il conteggio e la destinazione per uncomponente.stats on <componente> [<intervallo> [<conteggio>]] [<logagent>]


componente Il nome del componente di statistiche. Obbligatorio. Le statistichevengono raccolte nella memoria WebSEAL di questo componente. Lestatistiche per tale componente possono anche essere registrate in unfile di log specificando gli argomenti opzionali sul comando.

intervallo L’intervallo di tempo tra i report delle informazioni. Questo argomentoè facoltativo e determina l’invio delle statistiche ad un file di log.Quando questa opzione viene specificata, le statistiche vengono inviate,per impostazione predefinita, al file standard out del server WebSEAL,che corrisponde al file di log WebSEAL. E’ possibile specificare un’altraubicazione di output mediante l’argomento logagent. Se l’intervallo non èspecificato, nessuna statistica verrà inviata a file di log. Tuttavia, ilcomponente di statistiche è ancora abilitato. E’ possibile ottenere reportin modo dinamico in qualsiasi momento, utilizzando pdadmin statsget.

conteggio Il numero di report inviati a un file di log. Questo argomento èfacoltativo e richiede che l’argomento intervallo sia specificato. Seintervallo è specificato senza conteggio, la durata del report è indefinita.Dopo che è stato raggiunto il valore di conteggio, il report in un file dilog viene interrotto. Tuttavia, il componente di statistiche è ancoraabilitato. E’ possibile ottenere report in modo dinamico in qualsiasimomento, utilizzando pdadmin stats get.

logagent Facoltativamente, specifica una destinazione per le informazionistatistiche raccolte per il componente specificato. Fare riferimento alcapitolo sull’“Utilizzo del logging di eventi” della Guida per ilresponsabile di base IBM Tivoli Access Manager per i dettagli completisulla configurazione.

Nota: Per impostazione predefinita, i componenti pdweb.threads, pdweb.doccachee pdweb.jmt sono sempre abilitati e non è possibile disabilitarli.

Vedere anche “Abilitazione delle statistiche in modo statico mediante il logging dieventi” a pagina 81.

Esempio 1:

Questo esempio abilita il componente pdweb.http. Poiché l’opzione intervallo non èspecificata, è possibile ottenere le informazioni di statistiche per questocomponente solo in modo dinamico, utilizzando pdadmin stats get.pdadmin> server task webseald-<istanza> stats on pdweb.http

Esempio 2:

Questo esempio abilita il componente pdweb.http. Poiché l’argomento intervallo èspecificato, le informazioni vengono inviate (per impostazione predefinita) al file dilog standard WebSEAL. Gli argomenti intervallo e conteggio causano l’accumulo, daparte del file di log, di 100 voci che rappresentano report di statistiche ogni 20secondi.pdadmin> server task webseald-<istanza> stats on pdweb.http 20 100


Esempio 3:

Questo esempio abilita il componente pdweb.http. L’argomento logagent utilizza laconfigurazione di logging degli eventi per specificare un file di destinazione per leinformazioni di statistiche. L’argomento intervallo (senza un valore conteggio) inviainformazioni statistiche per questo componente ad un file di log ogni 20 secondi, atempo indeterminato. La grandezza del file di log è controllata dal parametrorollover_size. Fare riferimento al capitolo sull’“Utilizzo del logging di eventi” dellaGuida per il responsabile di base IBM Tivoli Access Manager per i dettagli completisulla configurazione del logging di eventi.pdadmin> server task webseald-<istanza> stats on pdweb.http 20 filepath=/tmp/jmt-stats.log,rollover_size=-1,flush_interval=20

Esempio 4:

Questo esempio illustra una limitazione dinamica della gestione delle statistiche. Ilprimo comando abilita il componente pdweb.http e indirizza le informazioni distatistiche al file A.log. Il secondo comando prova ad attivare un secondo file dilog, B.log. Tuttavia, questa azione determina la disattivazione di A.log durantel’attivazione di B.log.pdadmin> server task webseald-<istanza> stats on pdweb.http 20 file path=/tmp/A.logpdadmin> server task webseald-<istanza> stats on pdweb.http 20 file path=/tmp/B.log

Disabilitazione delle statisticheDisabilitare le statistiche raccolte per un componente o per tutti i componenticontemporaneamente.stats off [<componente>]

Esempio:pdadmin> server task webseald-<istanza> stats off pdweb.sescache

Nota: Per impostazione predefinita, i componenti pdweb.threads, pdweb.doccachee pdweb.jmt sono sempre abilitati e non è possibile disabilitarli.

Visualizzazione dei componenti di statistiche abilitatiElencare tutti i componenti di statistiche abilitati o un componente abilitatospecifico. Se un componente specificato non è abilitato, non viene visualizzatoalcun output.stats show [<componente>]

Esempio 1:pdadmin> server task webseald-<istanza> stats showpdweb.authnpdweb.doccachepdweb.jmtpdweb.sescachepdweb.threads

Esempio 2:pdadmin> server task webseald-<istanza> stats show pdweb.authnpdweb.authn

Richiamo dei valori correnti delle statistiche in modo dinamicoVisualizzare i valori correnti delle statistiche raccolte da un componente o da tutti icomponenti abilitati.stats get [<componente>]


Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.threadsactive:4total:50

Reimpostazione dei valori delle statisticheReimpostare i valori raccolti da un componente abilitato o da tutti i componentiabilitati contemporaneamente.stats reset [<componente>]

Esempio:pdadmin> server task webseald-<istanza> stats reset pdweb.threads

Elenco di tutti i componenti di statistiche disponibiliElencare tutti i componenti disponibili per la raccolta e il report delle statistiche.stats list

Esempio:pdadmin> server task webseald-<istanza> stats listpd.ras.stats.monitorpd.log.EventPool.queuepd.log.file.clfpd.log.file.refpd.log.file.agentpdweb.authnpdweb.authzpdweb.httppdweb.httpspdweb.threadspdweb.jmtpdweb.sescachepdweb.doccachepdweb.jct.1

Componenti di statistiche e tipi di attivitàQuesta sezione descrive i componenti di statistiche disponibili per IBM TivoliAccess Manager WebSEAL.

Componente pdweb.authnIl componente di statistiche pdweb.authn raccoglie informazioni relativeall’autenticazione WebSEAL. La tabella seguente descrive i tipi di informazionidisponibili:

Tipo Descrizione

pass Il numero totale di autenticazioni riuscite

fail Il numero totale di autenticazioni non riuscite

pwd exp Il numero totale di tentativi di autenticazione effettuati con una passwordscaduta

max La durata massima di un singolo processo di autenticazione

avg La durata media di un singolo processo di autenticazione

total La durata totale di tutti i processi di autenticazione

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.authnpass : 2fail : 1


pwd exp : 0max : 0.178avg : 0.029total : 0.382

Componente pdweb.authzIl componente di statistiche pdweb.authz raccoglie informazioni relativeall’autorizzazione WebSEAL. La tabella seguente descrive i tipi di informazionidisponibili:

Tipo Descrizione

pass Il numero totale di richieste di autorizzazione riuscite (a quante risorse èstato possibile accedere)

fail Il numero totale di richieste di autorizzazione non riuscite

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.authzpass : 2fail : 1

Componente pdweb.httpIl componente di statistiche pdweb.http raccoglie informazioni relative allacomunicazione HTTP WebSEAL. La tabella seguente descrive i tipi di informazionidisponibili:

Tipo Descrizione

reqs Il numero totale di richieste HTTP ricevute

max-worker Il tempo massimo utilizzato da un singolo thread di processo perelaborare una richiesta HTTP

total-worker Il tempo totale utilizzato da tutti i thread di processo che elaboranorichieste HTTP

max-webseal Il tempo massimo utilizzato per elaborare una singola richiesta HTTP,misurato all’interno del thread di processo, dopo l’avvenuta lettura delleintestazioni della richiesta ed eliminando l’eccedenza di impostazionedella connessione

total-webseal Il tempo totale utilizzato per elaborare tutte le richieste HTTP, misuratoall’interno dei thread di processo, dopo l’avvenuta lettura delleintestazioni delle richieste ed eliminando l’eccedenza di impostazionedella connessione

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.httpreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

Componente pdweb.httpsIl componente di statistiche pdweb.https raccoglie informazioni relative allacomunicazione HTTPS WebSEAL. La tabella seguente descrive i tipi diinformazioni disponibili:

Tipo Descrizione

reqs Il numero totale di richieste HTTPS ricevute


Tipo Descrizione

max-worker Il tempo massimo utilizzato da un singolo thread di processo perelaborare una richiesta HTTPS

total-worker Il tempo totale utilizzato da tutti i thread di processo che elaboranorichieste HTTPS

max-webseal Il tempo massimo utilizzato per elaborare una singola richiesta HTTPS,misurato all’interno del thread di processo, dopo l’avvenuta lettura delleintestazioni della richiesta ed eliminando l’eccedenza di impostazionedella connessione

total-webseal Il tempo totale utilizzato per elaborare tutte le richieste HTTPS, misuratoall’interno dei thread di processo, dopo l’avvenuta lettura delleintestazioni delle richieste ed eliminando l’eccedenza di impostazionedella connessione

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.httpsreqs : 0max-worker : 0.000total-worker : 0.000max-webseal : 0.000total-webseal : 0.000

Componente pdweb.threadsIl componente di statistiche pdweb.threads raccoglie informazioni relativeall’attività dei thread di processo WebSEAL. Questo componente è sempre abilitatoe non è possibile disabilitarlo. La tabella seguente descrive i tipi di informazionidisponibili:

Tipo Descrizione

active Il numero totale di thread di processo attivi che gestiscono richieste

total Il numero totale di thread di processo configurati

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.threadsactive : 0total : 50

Componente pdweb.jmtIl componente di statistiche pdweb.jmt raccoglie informazioni relative alla tabelladi associazione dei junction WebSEAL. Questo componente è sempre abilitato enon è possibile disabilitarlo. La tabella seguente descrive i tipi di informazionidisponibili:

Tipo Descrizione

hits Il numero totale di richieste che hanno richiesto un’associazione URLattraverso la tabella di associazione dei junction

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.jmthits : 5


Componente pdweb.sescacheIl componente di statistiche pdweb.sescache raccoglie informazioni relativeall’attività della cache di sessione/credenziale WebSEAL. La tabella seguentedescrive i tipi di informazioni disponibili:

Tipo Descrizione

hit Il numero di richieste che hanno determinato un accesso alla cache disessione; cioè, l’utente ha una voce nella cache di sessione e questa voce èstata referenziata con esito positivo

miss Il numero di richieste che hanno mancato un accesso alla cache disessione

add Il numero di voci che sono state aggiunte alla cache di sessione

del Il numero di voci che sono state eliminate dalla cache

inactive Il numero di voci rimosse dalla cache poiché il valore di timeout diinattività è scaduto

lifetime Il numero di voci rimosse dalla cache poiché il valore di timeout delladurata è scaduto

LRU expired Il numero di volte che una voce di “ultimo utilizzo” della cache èscaduta o è stata rimossa per far spazio ad una nuova voce.

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.sescachehit : 0miss : 0add : 0del : 0inactive : 0lifetime : 0LRU expired : 0

Componente pdweb.doccacheIl componente di statistiche pdweb.doccache raccoglie informazioni relativeall’attività di memorizzazione nella cache dei documenti WebSEAL. Questocomponente riporta statistiche per tutti i tipi MIME abilitati nella stanza[content-cache] del file di configurazione webseald.conf. Questo componente èsempre abilitato e non è possibile disabilitarlo.

La tabella seguente descrive i tipi di informazioni globali disponibili per tutti i tipiMIME:

Tipo Descrizione

General Errors Il numero di errori riportati dal componente pdweb.doccache alverificarsi di errori di assegnazione memoria, errori diinizializzazione e valori di intestazione tipo MIME non validi

Uncachable Il numero di istanze quando non è definita alcuna cache per iltipo MIME del documento da memorizzare nella cache

Pending Deletes Il numero di voci contrassegnate per l’eliminazione, ma ancora inuso

Pending Size Il numero di byte utilizzati da voci contrassegnate perl’eliminazione ma ancora in uso

Misses Il numero di volte che un URL viene ricercato nella cache deidocumenti e non viene trovato. Un documento rilevato nellacache elimina la necessità di accedere nuovamente al documentooriginale.


Tipo Descrizione

Cache MIME type Il tipo MIME dei documenti memorizzati in questa cache.

Statistiche dei tipi MIME nella cache:

Tipo Descrizione

Max size La dimensione massima combinata di byte di tutti i documentinella cache.

Max entry size La dimensione massima di per ogni singolo documento nellacache. Se la dimensione del documento supera questo valorecalcolato internamente, il documento non viene inserito nellacache.

Size Il conteggio totale di byte per tutti i documenti che attualmenterisiedono nella cache

Count Il numero corrente di voci nella cache.

Hits Il numero di ricerche effettuate con successo (documenti rilevatinella cache)

Stale hits Il numero di ricerche riuscite che hanno rilevato una voce troppovecchia ed è stata scaricata

Create waits Il numero di volte che richieste successive di un documento sonostate bloccate (messe in attesa) mentre il contenuto del documentoveniva inizialmente memorizzato nella cache

Cache no room Il numero di volte che un documento valido per la cache non puòesservi inserito poiché ci sono troppe voci in creazione nello stessomomento

Additions Il numero di nuove immissioni riuscite nella cache

Aborts Il numero di volte che la creazione di una nuova voce di cacheviene interrotta a causa di problemi oppure che un’intestazioneindicante la voce non può essere memorizzata nella cache

Deletes Il numero di voci della cache cancellate poiché la voce è scadutaoppure la creazione è stata interrotta

Updates Il numero di voci che hanno subito l’aggiornamento della scadenza

Too big errors Il numero di tentativi di memorizzare nella cache documenti chesuperano la dimensione massima di voce (e quindi non possonoessere inseriti nella cache)

MT errors Il numero di volte che più thread provano a creare la stessa vocenella cache (MT=Multi-Threading)

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.doccacheGeneral Errors : 0Uncachable : 0Pending Deletes: 0Pending Size : 0Misses : 0Cache MIME type : text/htmlMax size : 2048000Max entry size : 128000Size : 0Count : 0Hits : 0Stale hits : 0Create waits : 0


Cache no room : 0Additions : 0Aborts : 0Deletes : 0Updates : 0Too big errors : 0MT errors : 0

Componente pdweb.jct.#Il componente di statistiche pdweb.jct.# raccoglie informazioni relative ai junctionWebSEAL. La tabella seguente descrive i tipi di informazioni disponibili:

Tipo Descrizione

[/] Il nome di junction effettivo (elencato come numero nel comando)

reqs Il numero totale di richieste instradate sul junction

max Il tempo massimo consumato in una singola richiesta su questo junction

total Il tempo totale consumato per le richieste su questo junction

Esempio:pdadmin> server task webseald-<istanza> stats get pdweb.jct.1[/]reqs : 0max : 0.000total : 0.000

Abilitazione delle statistiche in modo statico mediante illogging di eventi

Le statistiche possono essere configurate in modo statico nella stanza[aznapi-configuration] del file di configurazione webseald.conf utilizzando ilparametro stats per abilitare l’interfaccia di statistiche e utilizzando il parametro dilogging degli eventi logcfg per indirizzare le informazioni statistiche a unadestinazione:[aznapi-configuration]stats = <componente> [intervallo [conteggio]]logcfg = stats.<componente>:<destinazione>

Fare riferimento a “Abilitare le statistiche in modo dinamico” a pagina 73 perinformazioni sugli argomenti intervallo e conteggio.

Fare riferimento al capitolo sull’“Utilizzo del logging di eventi” della Guida per ilresponsabile di base IBM Tivoli Access Manager per i dettagli completi sullaconfigurazione del logging di eventi.

Esempio 1:

In questo esempio, il parametro stats abilita il componente e tutti gli argomentiintervallo e conteggio. Il parametro logcfg specifica la destinazione per questeinformazioni. Fare riferimento al capitolo sull’“Utilizzo del logging di eventi” dellaGuida per il responsabile di base IBM Tivoli Access Manager per i dettagli completisulla configurazione.[aznapi-configuration]stats = pdweb.jmt 20logcfg = stats.pdweb.jmt:file path=/tmp/jmt.log,rollover_size=-1,flush=20

Esempio 2:


In questo esempio, parametri stats multipli abilitano componenti multipli. Iparametri logcfg multipli specificano destinazioni multiple. Notare che, adifferenza del comando stats on dinamico, è possibile specificare vari file didestinazione per lo stesso componente. Fare riferimento al capitolo sull’“Utilizzodel logging di eventi” della Guida per il responsabile di base IBM Tivoli AccessManager per i dettagli completi sulla configurazione del logging di eventi.[aznapi-configuration]stats = pdweb.jmt 20stats = pdweb.authn 40stats = pdweb.jct.1 50logcfg = stats.pdweb.jmt:file path=/tmp/jmtA.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jmt:file path=/tmp/jmtB.log,rollover_size=-1,flush=20logcfg = stats.pdweb.authn:file path=/tmp/an.log,rollover_size=-1,flush=20logcfg = stats.pdweb.jct.1:file path=/tmp/jct.log,rollover_size=-1,flush=20

Utilizzo del programma di utilità di traccia per la cattura di azioniWebSEAL

Il programma di utilità trace consente di catturare informazioni sulle condizioni dierrore e sul flusso di controllo del programma in WebSEAL Access Manager Base eWebSEAL Access Manager. Queste informazioni vengono memorizzate in un file eutilizzate per scopi di debug. Il programma di utilità trace viene fornitoprincipalmente per assistere il personale di supporto nella diagnosi di problemi chesi verificano con il software Access Manager.

Come utente, alcuni componenti della funzione di traccia WebSEAL potrebberoessere utili. Tuttavia, per la maggior parte si tratta di vantaggi ridotti a mano chenon vengano diagnosticati problemi complessi con l’assistenza del personale disupporto tecnico.

Nota: Utilizzare la funzione di traccia con cautela. Si tratta di uno strumento dautilizzare sotto la direzione del personale di supporto tecnico. I messaggidella traccia sono a volte difficili da comprendere, non sono tradotti epossono seriamente compromettere le prestazioni del sistema.

Sintassi dei comandi trace di basepdadmin> server task webseald-<istanza> trace <comando>

Con il comando pdadmin trace è possibile effettuare le seguenti attività:

trace set Abilitare il livello di traccia e la destinazione dei messaggi di traccia perun componente e i relativi subordinati

trace show Visualizzare il nome e il livello per tutti i componenti di traccia abilitatioppure per uno specifico componente

trace list Elenca tutti i componenti di traccia disponibili

Abilitazione della tracciaUtilizzare il comando pdadmin trace set per abilitare la raccolta di informazioni ditraccia per il componente e il livello specificati.trace set <componente> <livello> [<log-agent>]


componente Il nome del componente di traccia. Obbligatorio. I componenti specificidi WebSEAL hanno il prefisso “pdweb”.



livello Il livello di report. Obbligatorio. L’argomento livello specifica laquantità di dettagli raccolti dal programma di utilità trace. L’intervallova da 1 a 9. Il livello 1 specifica l’output maggiormente dettagliato e illivello 9 specifica l’output meno dettagliato.

logagent Facoltativamente, specifica una destinazione per le informazioni ditraccia raccolte per il componente specificato. Fare riferimento alcapitolo sull’“Utilizzo del logging di eventi” della Guida per ilresponsabile di base IBM Tivoli Access Manager per i dettagli completisulla configurazione.

Visualizzare i componenti di traccia abilitatiElencare tutti i componenti di traccia abilitati o un componente abilitato specifico.Se un componente specificato non è abilitato, non viene visualizzato alcun output.trace show [<componente>]

Esempio:pdadmin> server task webseald-<istanza> trace set pdweb.debug 2pdadmin> server task webseald-<istanza> trace showpdweb.debug 2

Elencare tutti i componenti di traccia disponibiliElencare il componente specificato o tutti i componenti disponibili per raccogliere eriportare informazioni di traccia.trace list [<componente>]

Componenti di traccia WebSEAL

pdweb.debugNota: Il componente pdweb.debug opera solo al livello 2.

Il seguente comando richiama il programma di utilità trace per il componentepdweb.debug al livello 2, e indirizza l’output in un file utilizzando il meccanismodi logging degli eventi per specificare un agente di log file.pdadmin> server task webseald-<istanza> trace set pdweb.debug 2 \file path=/opt/pdweb/log/debug.log

Output di esempio di questo comando, come appare nel file debug.log:/src/wand/wand/log.c:277: -------------- Browser ===> PD --------------Thread_ID:17GET /test/index.html HTTP/1.1Host: bevanUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1Accept-Language: en-usAccept-Encoding: gzip, deflate, compress;q=0.9Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Connection: keep-alive---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD ===> BackEnd --------------Thread_ID:17GET /index.html HTTP/1.1


via: HTTP/1.1 bevan:443host: mokum.santacruz.na.tivoli.comuser-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1accept-language: en-usaccept-charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66accept-encoding: gzip, deflate, compress;q=0.9keep-alive: 300connection: close---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD <=== BackEnd --------------Thread_ID:17content-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

/src/wand/wand/log.c:277: -------------- Browser <=== PD --------------Thread_ID:17HTTP/1.1 200 Document followscontent-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------


Capitolo 4. Criteri di sicurezza WebSEAL

Questo capitolo contiene informazioni che illustrano come configurare epersonalizzare i criteri di sicurezza WebSEAL.

Indice degli argomenti:v “Criteri ACL specifici di WebSEAL”v “Criterio three strikes login” a pagina 87v “Criteri di rafforzamento della password” a pagina 88v “Criterio POP di rafforzamento autenticazione (a fasi)” a pagina 91v “Criterio POP di autenticazione basato su rete” a pagina 96v “Criterio POP di qualità di protezione” a pagina 99v “Gestione di utenti non autenticati (HTTP/HTTPS)” a pagina 99

Criteri ACL specifici di WebSEALLe seguenti considerazioni sulla protezione si applicano al contenitore /WebSEALnello spazio oggetti protetti:v L’oggetto WebSEAL inizia la catena di eredità ACL per l’area WebSEAL dello

spazio oggettiv Se non viene applicato nessun altro ACL esplicito, questo oggetto definisce

(attraverso l’ereditarietà) il criterio di protezione per l’intero spazio Webv Per accedere a qualsiasi oggetto successivo, è necessaria l’autorizzazione

traversa.

Fare riferimento al manuale IBM Tivoli Access Manager - Guida per il responsabile dibase per informazioni complete sui criteri ACL di Access Manager.

/WebSEAL/< host >Questa voce di sottodirectory rappresenta l’inizio dello spazio Web per unaparticolare istanza del server WebSEAL. Le seguenti informazioni sulla protezionesono valide per questo oggetto:v Per accedere a qualsiasi oggetto successivo, è necessaria l’autorizzazione

traversa.v Se non viene applicato alcun ACL esplicito, questo oggetto definisce (mediante

l’ereditarietà) il criterio di protezione per l’intero spazio oggetti.

/WebSEAL/< host >/<file >Questa voce di sottodirectory rappresenta l’oggetto risorsa controllato per l’accessoHTTP. Le autorizzazioni controllate dipendono dall’operazione richiesta.

Autorizzazioni ACL WebSEALLa seguente tabella descrive le autorizzazioni ACL applicabili all’area WebSEALdello spazio oggetti:

Operazione Descrizione

r read Visualizza l’oggetto Web.


Operazione Descrizione

x execute Esegue il programma CGI.

d delete Rimuove l’oggetto Web dallo spazio Web.

m modify Posiziona un oggetto HTTP. (Pubblica un oggetto HTTP nellospazio oggetti WebSEAL.)

l list Necessario al server dei criteri per generare un elencoautomatico delle directory dello spazio Web.

Questa autorizzazione determina anche se un client puòvisualizzare l’elenco del contenuto delle directory quando lapagina predefinita “index.html” non è presente.

g delegation Assegna una fiducia a un server WebSEAL in modo che possaoperare per conto di un client e trasmettere richieste a unserver WebSEAL di junction.

Criterio ACL Default/WebSEALLe voci fondamentali dell’ACL WebSEAL, default-webseal, comprendono:Group iv-admin TcmdbsvarxlGroup webseal-servers TgmdbsrxlUser sec_master TcmdbsvarxlAny-other TrxUnauthenticated T

Al momento dell’installazione, questo ACL predefinito viene collegato all’oggettocontenitore /WebSEAL nello spazio oggetti.

Il gruppo, webseal-servers, contiene una voce per ciascun server WebSEALpresente nel dominio protetto. Le autorizzazioni predefinite consentono ai server dirispondere alle richieste di browser.

L’autorizzazione trasversale consente l’espansione dello spazio Web comerappresentato nel gestore di portale Web. L’autorizzazione di elenco permette algestore di portale Web di visualizzare il contenuto dello spazio Web.

Caratteri validi per i nomi ACLI seguenti caratteri sono validi per la creazione di nomi ACL:v A-Zv a-zv sottolineatura (_)v trattino (-)v barra retroversa (\)v qualsiasi carattere DBCS (double-byte character set)

Per informazioni dettagliate sulla creazione dei nomi ACL, fare riferimento almanuale IBM Tivoli - Guida per il responsabile di base.


Criterio three strikes loginIl criterio di login three strikes, disponibile per installazioni Access Manager basatesu LDAP, consentono di specificare un numero massimo di tentativi di login nonriusciti (n) e un tempo di blocco penale (x), cosicché, dopo “n” tentativi di loginnon riusciti, un utente viene bloccato per “x” secondi (oppure l’account vienedisabilitato).

Il criterio three strikes login è utilizzato per prevenire attacchi alla password delcomputer. Il criterio crea una condizione in cui un utente deve attendere unperiodo di tempo prima di poter effettuare altri tentativi di login non riusciti. Adesempio, un criterio può imporre tre tentativi non riusciti seguiti da una penale di180 secondi. Questo tipo di criterio di login può proteggere da tentativi di logincasuali generati dal computer che si verificano più volte al secondo.

Il criterio three strikes login richiede il contributo di due impostazioni delcomando pdadmin policy:v Numero massimo di tentativi di login non riusciti

policy set max-login-failures

v Impostazione della penale per il superamento dei tentativi non riuscitipolicy set disable-time-interval

L’impostazione del criterio può includere un intervallo di tempo di bloccodell’account oppure una completa disabilitazione dell’account.

Se viene impostato un criterio di login (ad esempio) per tre tentativi di login nonriusciti, seguito da una specifica penale di blocco, al quarto tentativo (corretto onon corretto che sia) verrà visualizzata una pagina di errore riportante chel’account è stato temporaneamente disabilitato per motivi di criteri password.

L’intervallo di tempo viene specificato in secondi; l’intervallo di tempo minimoconsigliato è di 60 secondi.

Se il criterio disable-time-interval è impostato su “disable”, l’account dell’utenteviene bloccato e l’attributo LDAP account valido per tale utente viene impostatosu “no”. Un responsabile riabilita l’account attraverso il gestore di portale Web.

Nota: L’impostazione di disable-time-interval su “disable” provoca un ulterioresovraccarico di gestione. Potrebbero verificarsi ritardi nella replica diinformazioni di account valido al server WebSEAL. Tale situazione dipendedal proprio ambiente LDAP. In aggiunta, alcune implementazioni LDAPpotrebbero subire un degrado delle prestazioni, come risultatodell’operazione di aggiornamento dei dati di account valido. Per questeragioni si consiglia di utilizzare un intervallo di timeout.

Sintassi dei comandiI seguenti comandi pdadmin sono adatti solo per l’utilizzo con un registro LDAP.

Comando Descrizione

policy set max-login-failures {<numero>|unset} [-user <nomeutente>]

policy get max-login-failures [-user <nomeutente>]

Capitolo 4. Criteri di sicurezza WebSEAL 87

Comando Descrizione

Gestisce il criterio che controlla il numero massimo di tentativi dilogin non riusciti possibili prima che venga imposta una penale.Questo comando dipende da una penale impostata nel comandopolicy set disable-time-interval.

Come responsabile, l’utente può applicare questo criterio a unutente specifico oppure applicarlo globalmente a tutti gli utentielencati nel registro LDAP.

L’impostazione predefinita prevede 10 tentativi.

policy set disable-time-interval {<numero>|unset|disable} [-user <nomeutente>]

policy get disable-time-interval [-user <nomeutente>]

Gestisce il criterio di penale che controlla il periodo di tempo didisabilitazione di un account nel caso venga raggiunto il numeromassimo di tentativi di login non riusciti.

Come responsabile, l’utente può applicare questo criterio di penalea un utente specifico oppure applicarlo globalmente a tutti gliutenti elencati nel registro LDAP.

L’impostazione predefinita è 180 secondi.

Criteri di rafforzamento della passwordI criteri di rafforzamento della password, disponibili per installazioni AccessManager basati su LDAP, si riferiscono alle condizioni inserite durante lacostruzione di una password dalle regole dei criteri delle password. AccessManager fornisce due mezzi per il controllo dei criteri di rafforzamento dellepassword:v Cinque comandi pdadmin per i criteri delle passwordv Un PAM (plugable authentication module) che consente all’utente di

personalizzare un criterio di passwordFare riferimento a IBM Tivoli Access Manager WebSEAL Developer’s Reference.

Criteri di rafforzamento password impostati dal programma diutilità pdadmin

I cinque attributi di rafforzamento password implementati attraverso il programmadi utilità pdadmin comprendono:v Lunghezza minima della passwordv Numero minimo di caratteri alfabeticiv Numero minimo di caratteri non alfabeticiv Numero massimo di caratteri ripetutiv Spazio consentito

Questi criteri vengono applicati quando si crea un utente con pdadmin o con ilgestore di portale Web, e quando una password viene modificata mediantepdadmin, il gestore di portale Web oppure il programma di utilità pkmspasswd.

Sintassi dei comandiI seguenti comandi pdadmin sono adatti esclusivamente per l’utilizzo con unregistro LDAP. L’opzione unset disabilita questo attributo di criterio; cioè, il


criterio non viene applicato.

Comando Descrizione

policy set min-password-length {<number>|unset} [-user <nomeutente>]

policy get min-password-length [-user <nomeutente>]

Gestisce il criterio che controlla la lunghezza minima di unapassword.

Come responsabile, è possibile applicare questo criterio a unospecifico utente oppure applicarlo globalmente a tutti gli utentielencati nel registro predefinito.

L’impostazione predefinita è 8.

policy set min-password-alphas {<number>|unset} [-user <nomeutente>]

policy get min-password-alphas [-user <nomeutente>]

Gestisce il criterio che controlla il numero minimo di caratterialfabetici consentiti in una password.


Il valore dell’impostazione predefinita è 4.

policy set min-password-non-alphas {<number>|unset} [-user <nomeutente>]

policy get min-password-non-alphas [-user <nomeutente>]

Gestisce il criterio che controlla il numero minimo di caratteri nonalfabetici (numerici) consentiti in una password.



policy set max-password-repeated-chars {<number>|unset} [-user <nomeutente>]

policy get max-password-repeated-chars [-user <nomeutente>]

Gestisce il criterio che controlla il numero massimo di caratteriripetuti consentiti in una password.



policy set password-spaces {yes|no|unset} [-user <nomeutente>]

policy get password-spaces [-user <nomeutente>]

Gestisce il criterio che controlla se una password può contenerespazi.


L’impostazione predefinita è unset (non impostato).


Valori predefiniti dei parametri di criterioLa seguente tabella elenca i parametri di criterio e i valori predefiniti:

Parametro Valore predefinito

min-password-length 8

min-password-alphas 4

min-password-non-alphas 1

max-password-repeated-chars 2

password-spaces non impostato

Per creare la funzione di criterio di password trovata in precedenti rilasci di AccessManager, applicare l’opzione unset a ciascuno dei cinque parametri di passwordelencati in precedenza.

Esempi di password valide e non valideLa seguente tabella illustra alcuni esempi di password e i risultati di criterio inbase ai valori predefiniti dei cinque parametri pdadmin:

Esempio Risultato

password Non valida: deve contenere almeno un carattere non alfabetico.

pass Non valida: deve contenere almeno 8 caratteri.

passs1234 Non valida: contiene più di due caratteri ripetuti.

12345678 Non valida: deve contenere almeno quattro caratteri alfabetici.

password3 Valida.

Impostazioni specifiche per l’utente e globaliI comandi pdadmin policy possono essere impostati per un utente specifico (conl’opzione - user) oppure globalmente (non utilizzando l’opzione - user). Qualsiasiimpostazione specifica per utente ricopre un’impostazione globale del criterio. E’anche possibile disabilitare (unset) un parametro di criterio, il che significa che ilparametro non contiene alcun valore. Tutti i criteri con l’opzione unset nonvengono controllati né applicati.

Ad esempio:pdadmin> policy set min-password-length 8

pdadmin> policy set min-password-length 4 -user matt

pdadmin> policy get min-password-length

Lunghezza minima password: 8

pdadmin> policy get min-password-length -user matt

Lunghezza minima password: 4

(L’utente matt ha un criterio di lunghezza minima della password di 4 caratteri;tutti gli altri utenti hanno un criterio di lunghezza minima di 8.)pdadmin> policy set min-password-length unset -user matt

(L’utente matt è ora governato dal criterio globale di lunghezza minima dellapassword di 8 caratteri.)


pdadmin> policy set min-password-length unset

(Ora tutti gli utenti, compreso matt, non hanno alcun criterio di lunghezza minimadella password.)

Criterio POP di rafforzamento autenticazione (a fasi)E’ possibile utilizzare POP (protected object policies) per rafforzare determinatecondizioni di accesso su risorse specifiche. Il criterio POP di rafforzamentoautenticazione rende ciò possibile per controllare l’accesso ad oggetti basati sulmetodo di autenticazione.

E’ possibile utilizzare questa funzionalità, conosciuta anche come autenticazione afasi, per assicurare che gli utenti che accedono alle risorse più sensibili utilizzinoun meccanismo di autenticazione rafforzato. Questa condizione può essereapplicata per evitare un accesso improprio a determinate risorse.

Ad esempio, è possibile fornire una protezione maggiore a un’area di junctiondello spazio Web applicando un criterio POP a fasi che richieda un livellorafforzato di autenticazione rispetto a quello utilizzato dal client durante l’ingressoiniziale nel dominio WebSEAL.

Il criterio di rafforzamento dell’autenticazione viene impostato nell’attributo IPEndpoint Authentication Method di un criterio POP.

Configurazione dei livelli per l’autenticazione a fasiLa prima fase nella configurazione di un accesso specifico per autenticazioneconsiste nel configurare i metodi di autenticazione supportati e determinarel’ordine in cui tali metodi devono essere considerati rafforzati.

Ogni client che accede a un server WebSEAL ha un livello di autenticazione, quale“non autenticato” o “password”, che indica il metodo mediante il quale il client haeffettuato l’ultima autenticazione con WebSEAL.

In alcune situazioni potrebbe essere necessario rafforzare i livelli minimo di“sicurezza” dell’autenticazione richiesta per accedere a determinate risorse. Adesempio, in un ambiente, l’autenticazione mediante codice di accesso tokenpotrebbe essere considerata più sicura rispetto all’autenticazione mediante nomeutente e password. Un altro ambiente potrebbe richiedere standard differenti.

Anziché costringere i client a riavviare le proprie sessioni con WebSEAL quandonon rispettano i livelli di autenticazione richiesti, il meccanismo di autenticazione afasi fornisce ai client una seconda possibilità di riautenticazione utilizzando ilmetodo richiesto (livello).

Autenticazione a fasi significa che a un utente non viene immediatamentevisualizzato un messaggio di “accesso negato” quando prova ad accedere ad unarisorsa che richiede un livello di autenticazione “più alto” di quello necessario peril login. Al contrario, ai client viene presentata una nuova richiesta diautenticazione che richiede informazioni a supporto del livello di autenticazionepiù alto. Se i client sono in grado di fornire questo livello di autenticazione, lerichieste originali verranno accettate.

WebSEAL riconosce tre metodi di autenticazione (livelli) da utilizzare nelmeccanismo di autenticazione a fasi:


v unauthenticatedv passwordv token-card

I livelli di autenticazione vengono configurati nella stanza [authentication-levels]del file di configurazione webseald.conf. Inizialmente, sono configurati solo duelivelli:[authentication-levels]level = unauthenticatedlevel = password

In base all’ordine dei metodi nell’elenco, ad ogni metodo viene assegnato un indicedi livello, da 0 a 2.v Il metodo “unauthenticated” deve sempre essere il primo dell’elenco e quindi,

ad esso, viene assegnato un indice di livello 0.v I metodi successivi possono essere sistemati in qualsiasi ordine.

Consultare “Note e limitazioni per l’autenticazione a fasi” a pagina 94.v Per impostazione predefinita, “password” appare al successivo livello, quindi

indice di livello 1.v Per abilitare l’autenticazione a fasi, devono essere presenti almeno due voci.

Nota: Per informazioni dettagliate sull’impostazione dei meccanismi diautenticazione richiesti, fare riferimento a Capitolo 5, “AutenticazioneWebSEAL” a pagina 101.

Abilitazione dell’autenticazione a fasiL’autenticazione a fasi viene implementata attraverso un criterio POP inserito suglioggetti che richiedono un’autorizzazione sensibile all’autenticazione. Si utilizzal’attributo IP Endpoint Authentication Method di un criterio POP.

Il comando pdadmin pop modify set ipauth specifica le reti consentite e il livellodi autenticazione richiesto nell’attributo IP Endpoint Authentication Method.

I livelli di autenticazione configurati possono essere collegati a gamme di indirizziIP. Scopo di questo metodo è di fornire una flessibilità di gestione. Se il filtro degliutenti mediante l’indirizzo IP non è importante, è possibile impostare una singolaimmissione per anyothernw (qualsiasi altra rete). Questa impostazione interesseràtutti gli utenti che effettuano l’accesso, indipendentemente dall’indirizzo IP,richiedendo a tali utenti l’autenticazione al livello specificato. Questo è il metodopiù comune di implementazione dell’autenticazione a fasi.

Sintassi:pdadmin> pop modify <nome-pop> set ipauth anyothernw <indice-livello>

La voce anyothernw viene utilizzata come intervallo di rete che verrà fattocorrispondere a qualsiasi rete non diversamente specificata nel POP. Questometodo è utilizzato per creare una voce predefinita che può negare l’accesso a tuttigli indirizzi IP non corrispondenti, oppure, consentire l’accesso a chiunquerisponda ai requisiti di livello di autenticazione.

Per impostazione predefinita, anyothernw appare in un POP con un indice dilivello di autenticazione di 0. La voce appare come “Any Other Network” nelcomando pop show:


pdadmin> pop show testProtected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0

Esempio1. Configurare livelli di autenticazione in webseald.conf:

[authentication-levels]level = unauthenticatedlevel = token-card

2. Configurare l’attributo POP IP Endpoint Authentication Method:pdadmin> pop modify test set ipauth anyothernw 1

pdadmin> pop show testProtected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: mon, wed, fri:anytime:localIP Endpoint Authentication Method Policy

Any Other Network 1

Questo criterio richiede una fase per il metodo di autenticazione token-card(livello 1) per tutti gli utente che hanno inizialmente effettuato l’accesso come“non autenticati” (livello 0). Tutti gli utenti non autenticati che provano adaccedere a oggetti protetti mediante questo criterio POP ricevono una richiestadi immissione del nome utente e del codice di accesso token.

Vedere anche “Criterio POP di autenticazione basato su rete” a pagina 96.

Modulo di login a fasiWebSEAL presenta un modulo speciale quando il criterio POP a fasi sulla risorsarichiesta costringe l’utente alla riautenticazione. L’ubicazione di tale modulo HTMLè specificata dal parametro stepup-login nella stanza [acnt-mgt] del file diconfigurazione webseald.conf.[acnt-mgt]stepup-login = stepuplogin.html

E’ possibile configurare questo modulo HTML per soddisfare i propri requisiti,nello stesso modo in cui si possono configurare i moduli login.html otokenlogin.html.

Questo file contiene macro, in formato di sequenze %TEXT%, che vengonosostituite dai valori appropriati. Questa sostituzione si verifica all’interno del filemaschera di WebSEAL che elabora le funzioni e consente al modulo di essereutilizzato con entrambi i metodi di autenticazione via password e via token, con lacorretta formattazione. Consente inoltre altre informazioni, quali il messaggio dierrore e il nome di metodo (delle fasi) da fornire per l’utente nel modulo.


Algoritmo di autenticazione a fasiWebSEAL utilizza il seguente algoritmo per elaborare le condizioni presenti in unPOP:1. Controllo del criterio di metodo di autenticazione endpoint IP sul POP.2. Controllo delle autorizzazioni ACL.3. Controllo del criterio ora del giorno sul POP.4. Controllo del criterio di livello di audit sul POP.

Note e limitazioni per l’autenticazione a fasi1. L’autenticazione a fasi è supportata su HTTP e HTTPS.2. Non è possibile cambiare fase dal protocollo HTTP a HTTPS.3. Unauthenticated deve essere sempre il primo metodo nell’elenco dei livelli e

non può trovarsi in nessun altra posizione dell’elenco.4. I metodi possono essere specificati solo una volta nell’elenco dei livelli.

Figura 18. Modulo di login personalizzato per fase nome utente e password

Figura 19. Modulo di login personalizzato per fase codice di accesso token SecurID


5. L’autenticazione mediante certificato non è un metodo supportato perl’autenticazione a fasi.

Nota: L’autenticazione a fasi gestisce i certificati del client come caso speciale.Se un client accede a WebSEAL con un certificato client e WebSEAL èconfigurato per accettare certificati, il client viene trattato come nonautenticato con un indice di livello 0.

Dal metodo: E’ possibile passare a:

unauthenticated password token-card

password token-card

token-card password

6. I livelli di autenticazione sono rappresentati mediante metodi di autenticazione,ad indicare che è impossibile specificare un preciso meccanismo diautenticazione per l’autenticazione a tale livello.I metodi di autenticazione possono essere supportati da più meccanismi diautenticazione, incluso i programmi di autenticazione locali e quelli esternipersonalizzati.WebSEAL segue regole specifiche per determinare il programma diautenticazione da selezionare quando sono state configurate istanze multipledello stesso tipo di metodo di autenticazione.

7. Se esistono tre livelli configurati, i valori di indice validi sono: 0,1,2. Se èconfigurato un qualsiasi altro valore di indice, WebSEAL presenta una paginadi errore ogni volta che viene richiesto un oggetto con tale POP collegato.

8. Una configurazione non corretta dei livelli di autenticazione a fasi nel file diconfigurazione webseald.conf provoca la disabilitazione della funzionalitàall’interno di WebSEAL. Questa situazione può portare ad un comportamentodi autenticazione imprevisto, ad esempio l’emissione della pagina di login dipassword per oggetti protetti da un POP che richiede il metodo diautenticazione mediante codice di accesso token.Dopo la configurazione dei livelli di autenticazione a fasi, controllare il filewebseald.log per i report di eventuali errori di configurazione.

Distinzione tra autenticazione a fasi e multi-factorL’autenticazione e fasi e l’autenticazione multi-factor di Access Manager sono duediversi e distinti meccanismi per il controllo dell’accesso alle risorse. AccessManager fornisce solo la funzionalità di autenticazione a fasi, come illustrato nelpresente capitolo.

L’autenticazione multi-factor costringe l’utente ad autenticarsi utilizzando due opiù livelli di autenticazione. Ad esempio, il controllo dell’accesso su una risorsaprotetta può richiedere che l’utente effettui l’autenticazione con nomeutente/password e anche con nome utente/codice di accesso token.

L’autenticazione a fasi Access Manager fa affidamento su una gerarchiapreconfigurata di livelli di autenticazione e applica uno specifico livello diautenticazione in accordo al criterio impostato su una risorsa. L’autenticazione afasi non forza l’utente ad effettuare l’autenticazione utilizzando livelli multipli diautenticazione per accedere ad una determinata risorsa. Invece, l’autenticazione afasi richiede all’utente l’autenticazione ad un livello almeno uguale a quellorichiesto dal criterio che protegge la risorsa.


Esempio di autenticazione a fasi:

Livelli di autenticazione configurati:v livello di autenticazione 1 = nome utente/passwordv livello di autenticazione 2 = nome utente/codice di accesso token

Il seguente oggetto è protetto da un POP che richiede il livello di autenticazione 1:/WebSEAL/hostA/junction

Il seguente oggetto è protetto da un POP che richiede il livello di autenticazione 2:/WebSEAL/hostA/junction/applicationA

Durante l’autenticazione a fasi, l’autenticazione nome utente/password (livello 1) èrichiesta per accedere a /WebSEAL/hostA/junction.

Tuttavia, l’autenticazione nome utente/codice di accesso token (livello 2) è richiestaper accedere a /WebSEAL/hostA/junction/applicationA. Se l’utente è correntementecollegato con nome utente e password, vengono richieste informazioni su nomeutente e codice di accesso token (fase). Tuttavia, se l’utente si collega inizialmente aWebSEAL con nome utente e codice di accesso token, l’accesso a applicationA èimmediato (presupponendo un controllo ACL positivo).

L’autenticazione multi-factor richiede entrambi i livelli di autenticazione 1 e 2 perl’accesso a applicationA.

Criterio POP di autenticazione basato su reteIl criterio POP di autenticazione basata sulla rete rende possibile il controllodell’accesso agli oggetti in base all’indirizzo IP dell’utente. E’ possibile utilizzarequesta funzionalità per impedire a specifici indirizzi IP (o gamme di indirizzi IP)l’accesso alle risorse del proprio dominio protetto.

E’ anche possibile applicare la configurazione di autenticazione a fasi a questocriterio e richiedere uno specifico metodo di autenticazione per ogni gamma diindirizzi IP specificata.

Il criterio di autenticazione basata su rete viene impostato nell’attributo IPEndpoint Authentication Method di un criterio POP. E’ necessario specificare duerequisiti in questo attributo:v Livelli di autenticazionev Reti consentite

Configurazione dei livelli di autenticazioneWebSEAL riconosce tre metodi di autenticazione da utilizzare nel meccanismo diautenticazione a fasi:v unauthenticatedv passwordv token-card

In base all’ordine dei metodi nell’elenco, ad ogni metodo viene assegnato un indicedi livello, da 0 a 2.


I livelli di autenticazione vengono configurati nella stanza [authentication-levels]del file di configurazione webseald.conf. Inizialmente, sono configurati solo duelivelli:[authentication-levels]level = unauthenticatedlevel = password

E’ possibile utilizzare queste impostazioni predefinite quando si configural’autenticazione basata su rete. In questo caso, “unauthenticated” è il livello 0 e“password” è il livello 1.

Vedere anche “Configurazione dei livelli per l’autenticazione a fasi” a pagina 91.

Specifica di indirizzi IP e intervalliOra è necessario specificare gli indirizzi IP e gli intervalli di indirizzi IP consentitida questo criterio POP.

Il comando pdadmin pop modify set ipauth add specifica sia la rete (o intervallodi reti) sia il livello di autenticazione richiesto nell’attributo IP EndpointAuthentication Method.

Sintassi:pdadmin> pop modify <nome-pop> set ipauth add <rete> <mascherarete> <indice-livello>

I livelli di autenticazione configurati sono collegati agli intervalli di indirizzi IP.Questo metodo è concepito per offrire flessibilità. Se il filtro degli utenti mediantel’indirizzo IP non è importante, è possibile impostare una singola immissione peranyothernw (qualsiasi altra rete). Questa impostazione interessa tutti gli utenti cheeffettuano l’accesso, indipendentemente dall’indirizzo IP, richiedendo a tali utentil’autenticazione al livello specificato.

Sintassi:pdadmin> pop modify <nome-pop> set ipauth anyothernw <indice-livello>

Al contrario, se si desidera ignorare il livello di autenticazione e si desidera solopermettere o rifiutare l’accesso in base all’indirizzo IP, è possibile utilizzare illivello 0 per gli intervalli a cui consentire l’accesso e “forbidden” per quelli a cuirifiutarlo.

La voce anyothernw viene utilizzata come intervallo di rete che corrisponde aqualsiasi rete non diversamente specificata nel POP. Questo metodo è utilizzato percreare una voce predefinita che può negare l’accesso a tutti gli indirizzi IP noncorrispondenti, oppure, consentire l’accesso a chiunque risponda ai requisiti dilivello di autenticazione.

Per impostazione predefinita, anyothernw appare in un POP con un indice dilivello di autenticazione di 0. La voce appare come “Any Other Network” nelcomando pop show:pdadmin> pop show test

Protected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: none


Time of day access: sun, mon, tue, wed, thu, fri, sat:anytime:local

IP Endpoint Authentication Method PolicyAny Other Network 0

Per ulteriori dettagli sull’impostazione dei livelli di autenticazione, fare riferimentoa “Configurazione dei livelli per l’autenticazione a fasi” a pagina 91.

EsempiRichiedere agli utenti dall’intervallo di indirizzi IP 9.0.0.0 e maschera di rete255.0.0.0 l’utilizzo del livello di autenticazione 1 (“password” per impostazionepredefinita):pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

Richiedere ad uno specifico utente di utilizzare il livello di autenticazione 0:pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

Impedire a tutti gli utenti (diversi da quelli specificati negli esempi precedenti) diaccedere all’oggetto:pdadmin> pop modify test set ipauth anyothernw forbidden

Disabilitazione dell’autenticazione a fasi mediante indirizzo IPSintassi:pdadmin> pop modify <pop-name> set ipauth remove <network> <netmask>

Ad esempio:pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0

Algoritmo di autenticazione basata su reteWebSEAL utilizza il seguente algoritmo per elaborare le condizioni presenti in unPOP:1. Controllo del criterio di metodo di autenticazione endpoint IP sul POP.2. Controllo delle autorizzazioni ACL.3. Controllo del criterio ora del giorno sul POP.4. Controllo del criterio di livello di audit sul POP.

Note e limitazioni per l’autenticazione basata su reteL’indirizzo IP utilizzato da WebSEAL per applicare il criterio di autenticazionebasata su rete dovrebbe corrispondere all’indirizzo IP di chi ha originato laconnessione TCP. Se la propria topologia di rete utilizza proxy HTTP, l’indirizzoche appare a WebSEAL potrebbe essere l’indirizzo IP del server proxy.

In tal caso, WebSEAL non è in grado di identificare definitivamente il veroindirizzo IP del client. E’ necessario fare attenzione durante l’impostazione di uncriterio di autenticazione basata su rete per i client di rete che possonodirettamente collegarsi al server WebSEAL.


Criterio POP di qualità di protezioneL’attributo POP di qualità di protezione (QOP - quality of protection) consente dispecificare quale livello di protezione dei dati è richiesto durante l’esecuzione diun’operazione su un oggetto.

Attualmente, questo attributo è adatto esclusivamente in un ambiente WebSEAL.

L’attributo POP di qualità di protezione rappresenta il sostituto per i bit diautorizzazione ACL “P” e “I” che attivavano i requisiti di privacy e integrità nelleprecedenti versioni di Access Manager. Questa vecchia implementazione dellaqualità di protezione era inefficiente e influenzava le prestazioni del sistema.

L’attributo POP della qualità di protezione permette una singola transazione in cuila risposta “yes” alla decisione ACL include anche il livello di qualità dellaprotezione richiesto. Se il gestore risorse (ad es. WebSEAL) non può garantire illivello di protezione richiesto, la richiesta viene rifiutata.pdadmin> pop modify <nome-pop> set qop {none|integrity|privacy}

Livello QOP Descrizione

Privacy E’ richiesta la codifica dei dati (SSL).

Integrity Utilizzare un meccanismo per assicurare che i dati non venganomodificati.

Ad esempio:pdadmin> pop modify test set qop privacy

Gestione di utenti non autenticati (HTTP/HTTPS)WebSEAL accetta richieste provenienti sia da utenti autenticati che non autenticatisu HTTP e HTTPS. WebSEAL quindi si affida al servizio di autorizzazione perapplicare il criterio di protezione per permettere o negare l’accesso alle risorseprotette.

Le seguenti condizioni si applicano agli utenti non autenticati che effettuanol’accesso su SSL:v Lo scambio di informazioni tra l’utente non autenticato e WebSEAL è

crittografato, proprio come se avvenisse con un utente autenticato.v Una connessione SSL tra un utente non autenticato e WebSEAL richiede solo

l’autenticazione del server.

Elaborazione di una richiesta da client anonimo1. Un client anonimo effettua una richiesta a WebSEAL (su HTTP o HTTPS).2. WebSEAL crea una credenziale non autenticata per tale client.3. La richiesta procede, con questa credenziale, all’oggetto Web protetto.4. Il servizio di autorizzazione controlla le autorizzazioni sulla voce non

autenticata dell’ACL per questo oggetto e permette o rifiuta l’operazionerichiesta.

5. L’accesso a questo oggetto dipende dalla voce ACL non autenticata contenentealmeno le autorizzazioni read (r) e traverse (T).

6. Se la richiesta non ottiene la decisione di autorizzazione, il client riceve unmodulo di login (BA o Moduli).


Forzatura del login utenteE’ possibile forzare un utente non autenticato ad effettuare il login impostandocorrettamente le autorizzazioni adatte sulla voce non autenticata del criterio ACLche protegge l’oggetto richiesto.

Le autorizzazioni read (r) e traverse (T) consentono l’accesso non autenticato ad unoggetto.

Per forzare un utente non autenticato ad effettuare il login, rimuoverel’autorizzazione read (r) dalla voce non autenticata del criterio ACL che proteggel’oggetto. L’utente riceve una richiesta di login (basata su BA o Moduli).

Applicazioni di HTTPS non autenticatiEsistono diverse ragioni pratiche per supportare l’accesso non autenticato aWebSEAL su HTTPS:v Alcune applicazioni non richiedono un login personale, ma richiedono dati

sensibili quali indirizzi e numeri di carte di credito. Gli esempi comprendonoacquisti online di biglietti aerei e altri beni.

v Alcune applicazioni richiedono la registrazione di un account con l’aziendaprima di poter procedere con ulteriori transazioni. Nuovamente, i dati sensibilidevono essere trasmessi sulla rete.

Controllo di utenti non autenticati con criteri ACL/POP

Nota: Il tipo di voce “any-authenticated” è equivalente al tipo di voce “any-other”.1. Per permettere ad utenti non autenticati di accedere ad oggetti pubblici,

proteggere il contenuto pubblico mediante un ACL che contiene almeno leautorizzazioni read (r) e traverse (T) per le voci unauthenticated eany-authenticated:unauthenticated Trany-authenticated Tr

Nota: La voce unauthenticated è una maschera (un’operazione a bit “and”) perla voce any-authenticated quando vengono determinate leautorizzazioni. Un’autorizzazione per unauthenticated viene concessasolo se l’autorizzazione appare anche nella voce any-authenticated.Poiché unauthenticated dipende da any-authenticated, ha poco sensoche un ACL contenga unauthenticated senza any-authenticated. Se unACL contiene unauthenticated senza any-authenticated, la rispostapredefinita consiste nel non concedere alcuna autorizzazione aunauthenticated.

2. Per richiedere la crittografia (SSL), proteggere il contenuto con un POP(Protected Object Policy) che specifica privacy come condizione.Consultare “Criterio POP di qualità di protezione” a pagina 99.


Capitolo 5. Autenticazione WebSEAL

Questo capitolo descrive il modo in cui WebSEAL mantiene lo stato della sessionee gestisce il processo di autenticazione. Un’autenticazione riuscita determinaun’identità Access Manager che rappresenta l’utente. WebSEAL utilizza taleidentità per acquisire credenziali per questo utente. Le credenziali vengonoutilizzate dal servizio di autorizzazione per permettere o negare l’accesso allerisorse protette.

Indice degli argomenti:v “Comprensione del processo di autenticazione” a pagina 101v “Gestione dello stato di sessione” a pagina 103v “Panoramica sulla configurazione dell’autenticazione” a pagina 112v “Configurazione dell’autenticazione Base (BA)” a pagina 115v “Configurazione dell’autenticazione moduli” a pagina 117v “Configurazione dell’autenticazione via certificato del client” a pagina 118v “Configurazione dell’autenticazione mediante intestazione HTTP” a pagina 121v “Configurazione dell’autenticazione mediante indirizzo IP” a pagina 123v “Configurazione dell’autenticazione token” a pagina 123v “Supporto MPA (multiplexing proxy agents)” a pagina 124v “Configurazione della riautenticazione basata su criteri di protezione” a pagina

127v “Configurazione della riautenticazione basata sul criterio di inattività della

sessione” a pagina 130

Comprensione del processo di autenticazioneL’autenticazione è un metodo di identificazione di un singolo processo o entità chesta tentando di collegarsi a un dominio protetto.v WebSEAL supporta diversi tipi di autenticazione per impostazione predefinita

che possono essere personalizzati per l’utilizzo con altri metodi.v Il risultato di un’autenticazione riuscita per WebSEAL consiste in un’identità del

registro utenti Access Manager.v WebSEAL utilizza tale identità per ottenere una credenziale per questo utente.v Il servizio di autorizzazione utilizza questa credenziale per permettere o per

negare l’accesso a oggetti protetti dopo la valutazione delle autorizzazioni ACL edelle condizioni POP che governano i criteri per ciascun oggetto.

Nota: ACL = access control list policy POP = protected object policy

Durante l’autenticazione, WebSEAL esamina la presenza, in una richiesta client,delle seguenti informazioni:v Dati di sessione

I dati di sessione sono informazioni che identificano una specifica connessionetra il client e il server WebSEAL. I dati di sessione sono memorizzati con il cliented accompagnano successive richieste effettuate da tale client. Vengono utilizzatiper re-identificare la sessione client nel server WebSEAL ed evitare ilsovraccarico necessario a stabilire una nuova sessione per ogni richiesta.


v Dati di autenticazione

I dati di autenticazione sono informazioni del client che identificanoquest’ultimo sul server WebSEAL. I tipi di dati di autenticazione comprendonocertificati del client, password e codici token.

Quando WebSEAL riceve una richiesta client, WebSEAL ricerca sempre per primacosa i dati di sessione, e poi i dati di autenticazione. La richiesta client iniziale noncontiene mai i dati di sessione.

Tipi di dati di sessione supportatiWebSEAL supporta i seguenti tipi di dati di sessione:1. ID SSL (definito dal protocollo SSL)2. Cookie di sessione specifica del server3. Dati di intestazione BA4. Dati di intestazione HTTP5. indirizzo IP

Quando WebSEAL esamina una richiesta client, ricerca i dati di sessione nell’ordinespecificato in questo elenco.

Metodi di autenticazione supportatiSebbene funzioni indipendentemente dal processo di autenticazione, WebSEALutilizza le credenziali per controllare tutti gli utenti partecipanti al dominioprotetto. Per ottenere le necessarie informazioni di identità per l’acquisizione dellecredenziali, WebSEAL si affida alle informazioni ottenute dal processo diautenticazione.

I seguenti metodi di autenticazione sono supportati da WebSEAL per l’acquisizionedelle credenziali:

Metodo di autenticazione Tipo di connessionesupportato

1. Cookie di failover HTTP e HTTPS

2. Token ID CDSSO HTTP e HTTPS

3. Certificato del client HTTPS

4. Codice di accesso token HTTP e HTTPS

5. Autenticazione Moduli (nome utente e password) HTTP e HTTPS

6. Autenticazione Base (nome utente e password) HTTP e HTTPS

7. Intestazioni HTTP HTTP e HTTPS

8. Indirizzo IP HTTP e HTTPS

Quando WebSEAL esamina una richiesta client, ricerca dati di autenticazionenell’ordine specificato in questa tabella.

I metodi di autenticazione possono essere abilitati e disabilitati indipendentementeper entrambi i trasporti HTTP e HTTPS. Se nessun metodo di autenticazione èabilitato per un particolare trasporto, il processo di autenticazione sarà inattivo peri client che utilizzano tale trasporto.


Gestione dello stato di sessioneUna connessione protetta, o una sessione, tra un client e un server richiede che ilserver abbia la capacità di ricordare, tra le numerose richieste, a chi è collegato. Ilserver deve disporre di alcune informazioni sullo stato della sessione cheidentificano il client associato a ciascuna richiesta.

In questa sezione sono contenuti i seguenti argomenti:v “Panoramica dello stato di sessione” a pagina 103v “Panoramica della cache di sessione GSKit e WebSEAL” a pagina 103v “Configurazione cache ID sessione SSL GSKit” a pagina 104v “Configurazione della cache di sessione/credenziali WebSEAL” a pagina 105v “Mantenimento dello stato con cookie di sessione” a pagina 106v “Individuazione di tipi di dati ID sessione validi” a pagina 108v “Configurazione dei cookie di failover” a pagina 108

Panoramica dello stato di sessioneSenza uno stato di sessione stabilito tra client e server, la comunicazione tra ilclient e il server deve essere rinegoziata per ogni richiesta successiva. Leinformazioni sullo stato della sessione migliorano le prestazioni eliminandochiusure e riaperture ripetute di connessioni client/server. Il client può collegarsiuna volta ed effettuare numerose richieste senza eseguire un separato login perciascuna richiesta.

WebSEAL gestisce comunicazioni HTTP e HTTPS. HTTP è un protocollo “apolide”e non fornisce alcun mezzo di distinzione di una richiesta da un’altra. Il protocollodi trasporto SSL, diversamente, è specificamente progettato per fornire un ID disessione per mantenere le informazioni sullo stato della sessione. La comunicazioneHTTP può essere incapsulata su SSL e diventare HTTPS.

Tuttavia, WebSEAL deve spesso gestire comunicazioni HTTP provenienti da clientnon autenticati. E, a volte, l’ID sessione SSL non rappresenta una soluzione adatta.Quindi, WebSEAL deve utilizzare i seguenti tipi di dati per mantenere lo stato disessione con un client:1. ID SSL2. Cookie di sessione specifica del server3. Dati di intestazione BA4. Dati di intestazione HTTP5. indirizzo IP

Panoramica della cache di sessione GSKit e WebSEALUna cache di sessione consente a un server di memorizzare le informazioni sull’IDsessione da più client. WebSEAL utilizza due tipi di cache di sessione per sistemarei dati sullo stato di sessione HTTPS e HTTP.v Cache di sessione/credenziali WebSEAL

La cache di sessione/credenziali WebSEAL memorizza qualsiasi tipo diinformazioni su ID sessione (vedere l’elenco precedente) più le informazionisulle credenziali ottenute per ciascun client.Le informazioni di credenziali vengono memorizzate nella cache per eliminarequery ripetitive al database del registro utenti durante le verifiche diautorizzazione.

Capitolo 5. Autenticazione WebSEAL 103

v Cache ID sessione SSL GSKitLa cache di sessione GSKit gestisce la comunicazione HTTPS (SSL) quando leinformazioni su ID sessione SSL vengono utilizzate per mantenere lo stato disessione.La cache GSKit mantiene anche le informazioni sullo stato di sessione relativealla connessione SSL tra WebSEAL e il registro utenti LDAP.

Esistono diversi parametri di configurazione disponibili per ogni cache checonsentono di regolarne le prestazioni. Tali parametri vengono riassunti nellaseguente figura:

Configurazione cache ID sessione SSL GSKitLe seguenti attività di configurazione sono disponibili per la cache ID sessione SSLGSKit:v Impostazione del valore di timeout della voce di cachev Impostazione del valore massimo di voci simultanee

Impostazione del valore di timeout della voce di cacheI parametri per l’impostazione del timeout di durata massima per una voce dellacache ID sessione SSL GSKit si trovano nella stanza [ssl] del file di configurazionewebseald.conf. Sono presenti due parametri: uno per connessioni SSL V2(ssl-v2-timeout) e uno per connessioni SSL V3 (ssl-v3-timeout).

Il timeout predefinito della sessione SSL V2 (in secondi) è 100 (con un intervallopossibile da 1 a 100):[ssl]ssl-v2-timeout = 100

Il timeout predefinito della sessione SSL V3 (in secondi) è 7200 (con un intervallopossibile da 1 a 86400):[ssl]ssl-v3-timeout = 7200

Impostazione del valore massimo di voci simultaneeIl parametro ssl-max-entries, ubicato nella stanza [ssl] del file di configurazionewebseald.conf, imposta il numero massimo di voci simultanee presenti nella cacheID sessione SSL GSKit.

WebSEAL

Client

cache GSKParametri di configurazione

- ssl-v2-timeout- ssl-v3-timeout- ssl-cache-max-sessions

Gestisce:- ID sessione SSL

G estisce:- ID sessi one W ebSEAL- Inform azioni credenzi ali

- timeout- inactive-timeout- max-entries

Sessione SSL GSKCache WebSEAL

Cache sessione/credenziali

cache WebSEALParametri di configurazione

Figura 20. Parametri di configurazione della cache di sessione


Questo valore corrisponde al numero di sessioni di login simultanee. Quando ladimensione della cache raggiunge questo valore, le voci vengono rimosse dallacache in base all’algoritmo di ultimo utilizzo, per consentire nuovi login.

Il numero predefinito di sessioni di login simultanee è 4096:[ssl]ssl-max-entries = 4096

Configurazione della cache di sessione/credenziali WebSEALLe seguenti attività di configurazione sono disponibili per la cache disessione/credenziali WebSEAL:v Impostazione del valore massimo di voci simultaneev Impostazione del valore di timeout di durata della voce cachev Impostazione del valore di timeout di inattività della voce cache

Impostazione del valore massimo di voci simultaneeIl parametro max-entries, ubicato nella stanza [session] del file di configurazionewebseald.conf, imposta il numero massimo di voci simultanee presenti nella cachedi sessione/credenziali WebSEAL.

Questo valore corrisponde al numero di sessioni di login simultanee. Quando ladimensione della cache raggiunge questo valore, le voci vengono rimosse dallacache in base all’algoritmo di ultimo utilizzo, per consentire nuovi login.

Il numero predefinito di sessioni di login simultanee è 4096:[session]max-entries = 4096

Impostazione del valore di timeout di durata della voce cacheIl parametro timeout, ubicato nella stanza [session] del file di configurazionewebseald.conf, imposta il valore di timeout della durata massima per tutte lesessioni utente memorizzate nella cache di sessione/credenziali WebSEAL.

WebSEAL memorizza nella cache le informazioni sulle credenziali internamente. Ilparametro di timeout della cache di sessione specifica per quanto tempo i dati sullecredenziali di autorizzazione restano nella memoria di WebSEAL.

Il parametro non rappresenta un timeout di inattività. Il valore è associato a una“durata di credenziale” e non a un “timeout di inattività sessione”. Il suo scopo èdi migliorare la sicurezza forzando la ri-autenticazione dell’utente quando il limitedi timeout specificato viene raggiunto.

Il timeout predefinito della durata di una voce nella cache di sessione (in secondi)è 3600:[session]timeout = 3600

Impostazione del valore di timeout di inattività della voce cacheIl parametro inactive-timeout, ubicato nella stanza [session] del file diconfigurazione webseald.conf, imposta il valore di timeout per l’inattività dellasessione utente.

Il timeout predefinito di inattività della sessione di login (in secondi) è 600:[session]inactive-timeout = 600


Per disabilitare questa funzione di timeout, impostare il valore del parametro su“0”.

Mantenimento dello stato con cookie di sessioneUn metodo di mantenimento dello stato di sessione tra un client e un serverconsiste nell’utilizzo di un cookie per conservare le informazioni di tale sessione. Ilserver impacchetta le informazioni di stato per un particolare client in un cookie ele invia al browser del client. Per ogni nuova richiesta, il the browser identificanuovamente sé stesso re-inviando il cookie (con le informazioni di sessione) alserver.

I cookie di sessione offrono una soluzione per le situazioni in cui il client utilizzaun browser che ri-negozia la propria sessione SSL dopo periodi di tempo moltobrevi. Ad esempio, alcune versioni del browser Microsoft Internet Explorerri-negoziano le sessioni SSL ogni due o tre minuti.

Un cookie di sessione fornisce solo la ri-autenticazione di un client ad un singoloserver per il quale il client era stato autenticato in precedenza entro un breveperiodo di tempo (circa dieci minuti). Il meccanismo si basa su un “cookie delserver” che non può essere trasmesso a nessuna macchina diversa da quella che hagenerato il cookie.

In aggiunta, il cookie di sessione contiene solo un identificativo numerico casualeche viene utilizzato per l’indice nella cache di sessione del server. Non esistonoaltre informazioni esposte nel cookie di sessione. Il cookie di sessione non puòcompromettere i criteri di protezione.

Comprensione dei cookie di sessioneWebSEAL utilizza un cookie di sessione protetto specifico del server. Le seguenticondizioni si applicano a questo meccanismo di cookie:v Il cookie contiene solo informazioni di sessione e non contiene informazioni

sull’identitàv Il cookie risiede solo nella memoria del browser (non viene scritto nel jar dei

cookie del browser sul disco)v Il cookie ha una durata limitatav Il cookie dispone di parametri di dominio e di percorso che ne proibiscono

l’utilizzo da parte di altri server

Abilitazione e disabilitazione dei cookie ID di sessioneIl parametro ssl-id-sessions, ubicato nella stanza [session] del file diconfigurazione webseald.conf, abilita e disabilita i cookie di sessione. Questoparametro controlla se l’ID sessione SSL viene utilizzato per mantenere la sessionedi login tra i client che effettuano l’accesso su HTTPS. Se il parametro è impostatosu “no”, i cookie di sessione vengono utilizzati per la maggior parte dei metodi diautenticazione.[session]ssl-id-sessions = no

Un’impostazione su “no” per questo parametro determina le seguenti condizioniper i client che accedono via HTTPS:1. L’ID sessione SSL non viene mai utilizzato come dato dell’ID di sessione.2. I cookie verranno utilizzati per mantenere sessioni con client che si autenticano

mediante cookie di failover, token ID CDSSO, nome utente e password dimoduli, codice di accesso token e certificati del client.


3. I cookie vengono utilizzati per client Basic Authentication solo quandouse-same-session = yes (vedere la sezione successiva). Diversamente,l’intestazione BA viene utilizzata per i dati di ID sessione.

4. L’intestazione HTTP viene utilizzata come dato di ID sessione per i client che siautenticano mediante intestazioni HTTP

5. L’indirizzo IP viene utilizzato come dato di ID sessione per i client che siautenticano mediante indirizzi IP.

Quando si utilizzano i cookie per mantenere lo stato di sessione, il cookie vieneinviato al browser una sola volta, dopo un login riuscito. Tuttavia, alcuni browserapplicano un limite al numero di cookie che è possibile memorizzarecontemporaneamente. In alcuni ambienti, le applicazioni possono inserire unampio numero di cookie in memoria per ogni dominio sui sistemi client. In questocaso, qualsiasi cookie di sessione WebSEAL configurato o qualsiasi cookie difailover può essere facilmente sostituito con un altro cookie.

Quando si configura WebSEAL per l’utilizzo di cookie di sessione (e,eventualmente, cookie di failover), è possibile impostare il parametroresend-webseal-cookies, ubicato nella stanza [session] del file di configurazionewebseald.conf, per fare in modo che WebSEAL invii il cookie di sessione e ilcookie di failover al browser con qualsiasi risposta. Questa azione serve adassicurare che i cookie di sessione e di failover rimangano nella memoria delbrowser.

Il parametro resend-webseal-cookies ha un’impostazione predefinita su “no”:[session]resend-webseal-cookies = no

Modificare l’impostazione predefinita in “yes” per inviare i cookie di sessioneWebSEAL e i cookie di failover con qualsiasi risposta.

Abilitazione e disabilitazione di stesse sessioniE’ possibile configurare WebSEAL per l’utilizzo di dati ID di stessa sessionequando un client si collega su un tipo di trasporto (ad esempio, HTTP), si scollega,e si ricollega su un altro tipo di trasporto (ad esempio, HTTPS).

Il parametro use-same-session, ubicato nella stanza [session] del file diconfigurazione webseald.conf, abilita e disabilita il riconoscimento dei dati ID distessa sessione. Per impostazione predefinita, questo parametro è impostato su“no”:[session]use-same-session = no

Un’impostazione su “yes” di questo parametro determina le seguenti condizioni:1. I cookie di sessione vengono utilizzati per identificare i seguenti tipi di client

che effettuano collegamenti successivi su un altro trasporto:a. Cookie di failoverb. Certificati del clientc. Token ID CDSSOd. Codice di accesso tokene. Nome utente e password Modulif. Basic Authentication

2. L’intestazione HTTP viene utilizzata per i client che accedono con intestazioniHTTP.


3. L’indirizzo IP è utilizzato per l’accesso di client con indirizzi IP.4. La configurazione ssl-id-sessions viene ignorata; il comportamento risultante è

uguale a quello attuato se ssl-id-sessions fosse stato impostato su “no”.Questa logica è importante poiché i client HTTP non hanno un ID sessione SSLdisponibile come dati di sessione.

5. Poiché i cookie sono disponibili sia per client HTTP che HTTPS, questi nonvengono contrassegnati come cookie protetti.

Individuazione di tipi di dati ID sessione validiI tipi di dati di sessione per un client che effettua l’accesso con un particolaremetodo di autenticazione, sono determinati da specifiche combinazioni deiseguenti parametri di configurazione:v Abilitazione o disabilitazione di cookie di sessione (ssl-id-sessions)v Abilitazione o disabilitazione della possibilità di utilizzare i dati della stessa

sessione quando un client si sposta tra HTTP e HTTPS (use-same-session)

Le seguenti tabelle riepilogano i dati di ID sessione validi per qualsiasiconfigurazione che combina i parametri ssl-id-sessions e use-same-session:

Client HTTPS

Metodo di autenticazione ssl-id-sessions = yes ssl-id-sessions = nouse-same-session = no

use-same-session = yesssl-id-sessions ignored

Cookie di failover ID SSL Cookie Cookie

Certificato ID SSL Cookie Cookie

CDSSO ID SSL Cookie Cookie

Token ID SSL Cookie Cookie

Moduli ID SSL Cookie Cookie

BA ID SSL Intestazione BA Cookie

intestazione HTTP ID SSL intestazione HTTP intestazione HTTP

indirizzo IP ID SSL indirizzo IP indirizzo IP

Client HTTP

Metodo di autenticazione use-same-session = no use-same-session = yes

Cookie di failover Cookie Cookie

CDSSO Cookie Cookie

Token Cookie Cookie

Moduli Cookie Cookie

BA Intestazione BA Cookie

intestazione HTTP intestazione HTTP intestazione HTTP

indirizzo IP indirizzo IP indirizzo IP

Configurazione dei cookie di failoverLa seguente funzione di cookie di failover (per HTTP e HTTPS) è adatta per unclient che si collega a un cluster di server front-end WebSEAL di replica attraversoun meccanismo di bilanciamento del carico. Lo scopo di un cookie di failover èquello di evitare una ri-autenticazione forzata quando il server che detiene lasessione originale con il client diventa improvvisamente indisponibile.


E’ possibile implementare un cluster WebSEAL front-end per fornire un’elevatadisponibilità di risorse per un ampio numero di client. Il meccanismo dibilanciamento del carico intercetta le richieste in arrivo e le distribuisce sui serverfront-end disponibili.

Nel corso di questa spiegazione, fare riferimento al seguente diagramma.

Il client non è consapevole della configurazione del server front-end di replica. Ilmeccanismo di bilanciamento del carico rappresenta il singolo punto di contattoper l’URL richiesto. Tale meccanismo collega un client ad un server disponibile (ades. WS1). Uno stato di sessione viene stabilito con WS1 e tutte le successiverichieste provenienti da tale client vengono inviate a WS1.

Il problema, che può essere risolto mediante cookie di failover, implica unasituazione in cui WS1 diventa disponibile per alcune ragioni (ad esempio,malfunzionamento del sistema o collegamento fuori linea da parte di unresponsabile). Se WS1 diventa indisponibile, il meccanismo di bilanciamento delcarico reindirizza la richiesta a uno degli altri server di replica (WS2 o WS3). Aquesto punto, l’associazione originale sessione-credenziale viene persa. Il clientrisulta nuovo a questo server di sostituzione e viene costretto ad una nuovaautenticazione.

E’ possibile configurare i server WebSEAL di replica per codificare i dati diidentificazione dei client in un cookie specifico per il server. Il cookie vienesistemato sul browser al primo collegamento del client. Se il server WebSEALiniziale diventa temporaneamente indisponibile, il cookie (con i dati di identitàcrittografati) viene presentato al server sostituto.

Il cookie di failover contiene il nome utente, la registrazione data/ora e il metododi autenticazione originale. I server WebSEAL di replica condividono una chiavecomune che è in grado di decifrare le informazioni del cookie. Quando il serverWebSEAL sostituto riceve questo cookie, può utilizzare il nome utente e il metododi autenticazione per rigenerare la credenziale del client, incluso qualsiasi attributoesteso. A questo punto il client può ristabilire una nuova sessione con un serverWebSEAL di replica senza essere costretto alla riautenticazione.

Il punto di riferimento per il cookie è il DNS del meccanismo di bilanciamento delcarico. Questo singolo punto di riferimento è importante poiché il cookie è

Client

Meccanismo dibilanciamento del carico

WS1

WS2

WS3

Server WebSEALfront-end replicati

Risorse diback-end

Figura 21. Scenario di cookie di failover


specifico per il server e non è un cookie specifico di dominio. Il cookie vieneaccettato solo da un server che abbia lo stesso nome DNS del server che ha creatoil cookie. Il client effettua sempre le richieste attraverso il meccanismo dibilanciamento del carico. Quindi, il cookie viene sempre accettato e quinditrasmesso al successivo server disponibile durante un’operazione di failover.

Abilitazione dei cookie di failoverIl parametro failover-auth, ubicato nella stanza [failover] del file di configurazionewebseald.conf, abilita o disabilita cookie di failover specifici del server:v Per abilitare cookie di failover, immettere “http”, “https” oppure “both”.v Per disabilitare i cookie di failover, immettere “none” (predefinito).

Ad esempio:[failover]failover-auth = https

E’ necessario impostare questo parametro su ciascuno dei server front-endWebSEAL.

Per ogni metodo di autenticazione supportato nell’ambiente cluster WebSEAL, èanche necessario abilitare un parametro di metodo di failover equivalente nellastanza [authentication-mechanisms] del file di configurazione webseald.conf. Ogniparametro di metodo di autenticazione di failover punta a una speciale libreria diautenticazione condivisa che imita la libreria di autenticazione condivisa originalee, in aggiunta, recupera qualsiasi attributo esteso originariamente presente nellacredenziale dell’utente.

Sono disponibili i seguenti parametri per il metodo di autenticazione di failover:[authentication-mechanisms]#failover-password = <failover-password-library>#failover-token-card = <failover-tokeb-card-library>#failover-certificate = <failover-certificate-library>#failover-http-request = <failover-http-request-library>#failover-cdsso = <failover-cdsso-library>

WebSEAL fornisce una libreria condivisa di failover standard che funziona per tuttii metodi di autenticazione descritti in precedenza. Questa libreria è denominata:

Solaris libfailoverauthn.so

AIX libfailoverauthn.a

HP-UX libfailoverauthn.sl

Windows failoverauthn.dll

E’ possibile, in alternativa, fornire una libreria CDAS personale che offra lespecifiche capacità di autenticazione richieste dal proprio ambiente.

Ad esempio:1. L’utente effettua l’autenticazione a WS1 attraverso nome utente e password. La

libreria standard libldapauthn aggiunge (mediante un attributo estesoHTTP-Tag-Value sul junction) determinati attributi estesi da LDAP allacredenziale dell’utente.In aggiunta, un modulo CDAS incatenato aggiunge altri attributi estesi allacredenziale dell’utente attraverso la propria libreria cred-ext-attrs.

2. Il server WS1 non funziona e l’utente viene reindirizzato al server WS2.


3. WS2 riceve il cookie di failover dal browser dell’utente e decodifica il cookie.Poiché l’utente si era in origine autenticato mediante il metodo nome utente epassword, la libreria libfailoverauthn si collega al server LDAP e recupera idati standard della credenziale per questo metodo, oltre agli attributi estesiforniti dal meccanismo tag/valore.Quindi, l’identità dell’utente viene trasmessa alla libreria cred-ext-attrspersonale che fornisce i propri attributi estesi aggiuntivi.Ora WS2 ha creato per l’utente la stessa credenziale completa che era statautilizzata da WS1.

Se l’ambiente per questo esempio comprende anche il supporto perl’autenticazione dei certificati, la stanza [authentication-mechanisms] apparirebbecome di seguito illustrato:[authentication-mechanisms]passwd-ldap = /opt/pdweb/lib/libldapauthn.socert-ssl = /opt/pdweb/lib/libsslauthn.sofailover-password = /opt/pdweb/lib/libfailoverauthn.sofailover-certificate = /opt/pdweb/lib/libfailoverauthn.socred-ext-attrs = /usr/lib/custom-ext-attrs-CDAS.so

Codifica e decodifica dei dati di cookiePer proteggere i dati dei cookie, utilizzare il programma di utilità cdsso_key_genfornito da WebSEAL. Questo programma genera una chiave simmetrica checodifica e decodifica i dati presenti nel cookie. Specificare l’ubicazione (percorsoassoluto) del file di chiavi quando si esegue il programma di utilità:

UNIX:# cdsso_key_gen <nomepercorso>

Windows:MSDOS> cdsso_key_gen <nomepercorso>

Eseguire il programma di utilità su uno dei server di replica e copiaremanualmente il file di chiavi in ognuno dei restanti server di replica. Immetterel’ubicazione del file di chiavi nella stanza [failover] del file di configurazionewebseald.conf di ogni server. Se non si specifica un file di chiavi su un server, lafunzionalità del cookie di failover sarà disabilitata per tale server:[failover]failover-cookies-keyfile = <percorso-assoluto>

E’ possibile assegnare al file di chiavi qualsiasi nome appropriato, ad esempiows.key.

Configurazione della durata del cookieIl valore della durata del cookie di failover (in minuti), viene impostato con ilparametro failover-cookie-lifetime:[failover]failover-cookie-lifetime = 60

Abilitazione dei cookie di failover per l’intero dominioE’ possibile configurare l’invio dei cookie di failover a qualsiasi server all’internodello stesso dominio del server WebSEAL impostando il parametroenable-failover-cookie-for-domain su “yes”. Per impostazione predefinita, lafunzionalità del cookie di failover per l’intero dominio è disabilitata:[failover]enable-failover-cookie-for-domain = no


Panoramica sulla configurazione dell’autenticazioneE’ possibile abilitare e disabilitare l’autenticazione per entrambi i client HTTP eHTTPS su una base di metodo.

I meccanismi per tutti i metodi di autenticazione supportati da WebSEAL sonoconfigurati nella stanza [authentication-mechanisms] del file di configurazionewebseald.conf. I parametri dei metodi di autenticazione supportati comprendono:v Programmi di autenticazione locali (incorporati)

Parametri per programmi di autenticazione locali specificano l’adatta libreriacondivisa incorporata (UNIX) o i file DLL (Windows) appropriati.

v Programmi di autenticazione esterni personalizzatiWebSEAL fornisce codice server di maschera che è possibile utilizzare per crearee specificare un server CDAS (Cross Domain Authentication Service) esterno epersonalizzato.Un programma di autenticazione CDAS esterno specifica la libreria condivisapersonalizzata adatta.

Parametri di autenticazione localiI seguenti parametri specificano i programmi di autenticazione incorporati locali:


Autenticazione Base e Moduli

passwd-ldap Accesso del client mediante nome utente e password LDAP.

Autenticazione token

token-cdas Accesso del client mediante nome utente LDAP e codice diaccesso token SecurID.

Autenticazione con certificato del client

cert-ssl Accesso del client mediante certificato del client su SSL.

Autenticazione con Intestazione HTTP e/o Indirizzo IP

http-request Accesso del client mediante intestazione HTTP speciale e/oindirizzo IP.

Autenticazione con Token ID CDSSO

cdsso Autenticazione CDSSO (Cross Domain Single Sign-on).

La stanza [authentication-mechanisms] viene utilizzata per configurare il metododi autenticazione e l’implementazione nel seguente formato:<parametro-metodo-autenticazione> = <libreria-condivisa>

Parametri di autenticazione CDAS esterni personalizzatiI seguenti parametri sono disponibili per specificare librerie condivisepersonalizzate per server CDAS esterni:


passwd-cdas Accesso del client mediante nome utente e password per unregistro di terzi.

token-cdas Accesso del client mediante nome utente e codice di accesso token.

cert-cdas Accesso del client mediante certificato del client su SSL.



http-request Accesso del client mediante intestazione HTTP speciale e/oindirizzo IP.

cred-ext-attrs Utilizzato da CDAS per fornire dati di attributi estesi allacredenziale dell’utente.

Per dettagli sulla creazione e sulla configurazione di una libreria condivisapersonalizzata che implementa un server CDAS, fare riferimento al manuale IBMTivoli Access Manager WebSEAL Developer’s Reference.

Configurazione predefinita per l’autenticazione WebSEALPer impostazione predefinita, WebSEAL è impostato per autenticare client su SSLutilizzando nomi utente e password BA (Basic Authentication) (registro LDAP).

WebSEAL è generalmente abilitato per entrambi gli accessi TCP e SSL. Quindi, unatipica configurazione della stanza [authentication-mechanisms] include il supportoper nome utente e password (registro LDAP) e il supporto per i certificati delclient su SSL.

L’esempio seguente rappresenta la configurazione tipica della stanza[authentication-mechanisms] per Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.socert-ssl = libsslauthn.so

Per configurare altri metodi di autenticazione, aggiungere l’appropriato parametrocon la relativa libreria condivisa (o modulo CDAS).

Configurazione di metodi di autenticazione multipliL’utente modifica la stanza [authentication-mechanism] del file di configurazionewebseald.conf per specificare la libreria condivisa da utilizzare per qualsiasimetodo di autenticazione supportato. Le seguenti condizioni si applicano quandovengono configurati metodi di autenticazione multipli:1. Tutti i metodi di autenticazione possono funzionare indipendentemente l’uno

dall’altro. E’ possibile configurare una libreria condivisa per ogni metodosupportato.

2. Il metodo cert-cdas ricopre il metodo cert-ssl quando entrambi sonoconfigurati. E’ necessario abilitare uno di questi per supportare i certificati delclient.

3. Solo un programma di autenticazione del tipo di password viene effettivamenteutilizzato quando ne sono configurati più di uno. WebSEAL utilizza il seguenteordine di priorità per risolvere la presenza di più programmi di autenticazionepassword configurati:a. passwd-cdas

b. passwd-ldap

4. E’ possibile configurare la stessa libreria personalizzata per due differentimetodi di autenticazione. Ad esempio, è possibile scrivere una libreriacondivisa personalizzata per l’elaborazione sia dell’autenticazione nomeutente/password che dell’autenticazione di intestazione HTTP. Per questoesempio, configurare entrambi i parametri passwd-cdas e http-request con lastessa libreria condivisa. E’ responsabilità dello sviluppatore di mantenere lostato di sessione ed evitare conflitti tra i due metodi.


Richiesta di loginWebSEAL effettua una richiesta di login al client quando esistono le seguenticondizioni:1. Un client non autenticato che ha avuto esito negativo su un controllo di

autorizzazione2. Un client di moduli o Basic Authentication che ha avuto esito negativo su un

controllo di autorizzazione

I seguenti tipi di client presentano un errore di malfunzionamento “403”:1. Quando un controllo di autorizzazione non riesce:

a. Certificato del clientb. Cookie di failoverc. CDSSOd. indirizzo IPe. intestazione HTTP

2. Quando un client effettua l’autenticazione con un metodo disabilitato daWebSEAL

Comandi di logout e modifica passwordAccess Manager fornisce i seguenti comandi per il supporto di client che effettuanol’autenticazione su HTTP o HTTPS.

pkmslogoutI client possono utilizzare il comando pkmslogout per scollegarsi dalla sessionecorrente quando utilizzano un metodo di autenticazione che non fornisce dati diautenticazione con ciascuna richiesta. Ad esempio, pkmslogout non funziona perclient che utilizzano Basic Authentication o l’autenticazione tramite indirizzo IP. Inquesto caso, per scollegarsi è necessario chiudere il browser.

Il comando pkmslogout è adatto per l’autenticazione via certificato del client,codice di accesso token, autenticazione moduli e determinate implementazionidell’autenticazione di intestazione HTTP.

Eseguire il comando nel modo riportato di seguito:https://www.tivoli.com/pkmslogout

Il browser visualizza un modulo di logout definito nel file di configurazionewebseald.conf:[acnt-mgt]logout = logout.html

E’ possibile modificare il file logout.html in base alle proprie necessità.

Il programma di utilità pkmslogout supporta anche pagine di risposta di logoutmultiple quando l’architettura della rete richiede diversi pannelli di uscita per gliutenti che si scollegano da sistemi di back-end distinti.

La seguente espressione identifica uno specifico file di risposte:https://www.tivoli.com/pkmslogout?filename=<custom_logout_file>

dove custom_logout_file rappresenta il nome file della risposta di scollegamento.Questo file deve risiedere nella stessa directory lib/html/C che contiene il filelogout.html predefinito e altri moduli di risposta HTML di esempio.


pkmspasswdE’ possibile utilizzare questo comando per modificare la propria password di loginquando si utilizza l’autenticazione BA (Basic Authentication) o l’autenticazionemoduli. Questo comando è appropriato su HTTP o HTTPS.

Ad esempio:https://www.tivoli.com/pkmspasswd

Per assicurare una massima protezione quando BA si utilizza con WebSEAL,questo comando adotta le seguenti condizioni per un client BA:1. La password viene modificata.2. L’utente client viene scollegato dalla sessione corrente.3. Quando il client effettua una richiesta supplementare, il browser presenta al

client una richiesta BA.4. Il client deve eseguire nuovamente il collegamento per continuare ad effettuare

le richieste.

Questo scenario si applica solo a un client che utilizza Basic Authentication.

Configurazione dell’autenticazione Base (BA)L’autenticazione BA (Basic Authentication) è un metodo standard per fornire unnome utente e una password al meccanismo di autenticazione. BA è definitamediante il protocollo HTTP e può essere implementata su HTTP e su HTTPS.

Per impostazione predefinita, WebSEAL è configurato per l’autenticazione suHTTPS attraverso nome utente e password di BA (Basic Authentication).

Abilitazione e disabilitazione di BA (Basic Authentication)Il parametro ba-auth, ubicato nella stanza [ba] del file di configurazionewebseald.conf, abilita e disabilita il metodo Basic Authentication.v Per abilitare il metodo Basic Authentication, immettere “http”, “https” o “both”.v Per disabilitare il metodo Basic Authentication, immettere “none”.

Ad esempio:[ba]ba-auth = https

Impostazione del nome realmIl nome realm è il testo visualizzato nella casella di dialogo che appare quando ilbrowser richiede dati di login all’utente.

Il parametro di configurazione che imposta il nome realm si trova nella stanza [ba]del file di configurazione webseald.conf.

Ad esempio:[ba]basic-auth-realm = Access Manager


Configurazione del meccanismo Basic AuthenticationIl parametro passwd-ldap specifica la libreria condivisa utilizzata per gestirel’autenticazione attraverso nome utente e password.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libldapauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata ldapauthn.

Meccanismo diautenticazione

Libreria condivisa

Solaris AIX Windows HP-UX

passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

E’ possibile configurare il meccanismo di autenticazione via nome utente epassword immettendo il parametro passwd-ldap con il nome, specifico perpiattaforma, del file di libreria condivisa nella stanza [authentication-mechanism]del file di configurazione webseald.conf. Ad esempio:

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condizioni di configurazioneSe l’autenticazione via moduli è abilitata per un trasporto specifico, le impostazioniBasic Authentication per tale trasporto verranno ignorate.

Figura 22. Prompt di login BA


Configurazione dell’autenticazione moduliAccess Manager fornisce l’autenticazione moduli come alternativa al meccanismostandard Basic Authentication. Questo metodo produce un modulo di login HTMLpersonalizzato di Access Manager anziché la richiesta di login standard risultantedal metodo Basic Authentication.

Quando si utilizza il login basato su moduli, il browser non memorizza nella cachele informazioni su nome utente e password come invece avviene in BasicAuthentication.

Abilitazione e disabilitazione dell’autenticazione moduliIl parametro forms-auth, ubicato nella stanza [forms] del file di configurazionewebseald.conf, abilita e disabilita il metodo di autenticazione via moduli.v Per abilitare il metodo di autenticazione via moduli, immettere “http”, “https” o

“both”.v Per disabilitare il metodo di autenticazione via moduli, immettere “none”.

Ad esempio:[forms]forms-auth = https

Configurazione del meccanismo di autenticazione moduliIl parametro passwd-ldap specifica la libreria condivisa utilizzata per gestirel’autenticazione attraverso nome utente e password.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libldapauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata ldapauthn.


Libreria condivisa


passwd-ldap libldapauthn.so libldapauthn.a ldapauthn.dll libldapauthn.sl

E’ possibile configurare il meccanismo di autenticazione via nome utente epassword immettendo il parametro passwd-ldap con il nome, specifico perpiattaforma, del file di libreria condivisa nella stanza [authentication-mechanism]del file di configurazione webseald.conf. Ad esempio:

Solaris:[authentication-mechanisms]passwd-ldap = libldapauthn.so

Windows:[authentication-mechanisms]passwd-ldap = ldapauthn.dll

Condizioni di configurazioneSe l’autenticazione via moduli è abilitata per un trasporto specifico, le impostazioniBasic Authentication per tale trasporto verranno ignorate.


Personalizzazione dei moduli di risposta HTMLL’autenticazione via moduli richiede, da parte dell’utente, l’utilizzo di un modulodi login personalizzato. Per impostazione predefinita, il modulo di esempiologin.html si trova nella seguente directory:<directory-installazione>/lib/html

E’ possibile personalizzare il contenuto e la forma di questo modulo. Ad esempio:

Per informazioni dettagliate sui moduli HTML disponibili per la personalizzazione,vedere “Gestione delle pagine di gestione account personalizzate” a pagina 34.

Configurazione dell’autenticazione via certificato del clientWebSEAL supporta comunicazioni protette con i client utilizzando certificatidigitali del client su SSL. In questo metodo di autenticazione, le informazioni sulcertificato (ad esempio, il DN (Distinguished Name) vengono associate aun’identità Access Manager.

Informazioni secondarie: Autenticazione reciproca mediantecertificati

Lo scambio di certificati del server e del client su SSL determina un rapporto difiducia tra client e server basato sui certificati. Viene inoltre stabilito un canale dicomunicazioni protetto.

L’incontro dei certificati digitali SSL che avviene durante l’autenticazione reciprocasi svolge in due fasi:v WebSEAL identifica sé stesso ai client SSL con il proprio certificato serverv WebSEAL utilizza il proprio database dei certificati principali CA (Certificate

Authority) per convalidare le richieste in fase di accesso mediante certificati delclient

1. Un client richiede una connessione via SSL ad un server WebSEAL.2. In risposta, WebSEAL invia la propria chiave pubblica attraverso un certificato

firmato del server. Questo certificato è stato in precedenza convalidato daun’autorità di certificazione (CA) terza di fiducia.

3. Il client controlla se l’ente che emette il certificato è garantito e può essereaccettato. Il browser del client generalmente contiene un elenco dei certificatiprincipali di CA di fiducia. Se la firma sul certificato di WebSEAL corrispondea uno di tali certificati principali, il server può essere garantito.

Figura 23. Modulo di login WebSEAL di esempio


4. Se non c’è corrispondenza per la firma, il browser informa il proprio utenteche questo certificato è stato emesso da un’autorità di certificazionesconosciuta. Sarà quindi responsabilità dell’utente di accettare o meno ilcertificato.

5. Se la firma corrisponde ad una voce del database dei certificati principali nelbrowser, le chiavi di sessione vengono negoziate in modo sicuro tra il client eil server WebSEAL.Il risultato finale di questo processo è un canale protetto.

6. A questo punto il client invia il proprio certificato di chiave pubblica al serverWebSEAL.

7. WebSEAL confronta la firma sul certificato del client con una CA conosciuta.Come il browser di un client, il server WebSEAL mantiene nel propriodatabase di chiavi un elenco di certificati principali di CA di fiducia.

8. Se non c’è corrispondenza con la firma, WebSEAL genera un codice di erroreSSL e lo invia al client.

9. Se è presente una corrispondenza, il certificato può essere garantito.10. Access Manager autentica il client utilizzando la libreria condivisa incorporata

in modo da far corrispondere esattamente il Distinguished name (DN) delcampo Oggetto del certificato del client con una voce DN esistente nel registroLDAP, oppure utilizzando un CDAS personalizzato per eseguire unacorrispondenza di identità alternativa.Il risultato di un’autenticazione riuscita è un’identità Access Manager cheviene successivamente utilizzata per creare una credenziale per tale utente. Sitratta della credenziale richiesta al client per partecipare al dominio protetto diAccess Manager.

Il certificato di prova WebSEALAl momento dell’installazione, WebSEAL contiene un certificato serverauto-convalidato di prova. Sebbene questo certificato di prova consenta aWebSEAL di rispondere a una richiesta di browser abilitato SSL, non può essereverificato mediante il browser (che non contiene un appropriato certificato CAprincipale). Poiché la chiave privata per questo certificato predefinito è contenutain qualsiasi distribuzione di WebSEAL, tale certificato non offre una comunicazionesicura.

Per assicurare comunicazioni protette su SSL, è molto importante registrarsi eottenere un certificato del sito server unico da un’autorità di certificazione (CA)garantita. E’ possibile utilizzare il programma di utilità GSKit iKeyman per

Richiesta

Client

Risposta

Server WebSEAL

"L’utente è affidabile”

verisign

www.tivoli.com

ID digitaledel server

belsigncertisignentrustverisign

...

Certificati rootdella CA del browser

Figura 24. Il client convalida il certificato WebSEAL


generare una richiesta di certificato che viene inviata alla CA. iKeyman vieneutilizzato anche per l’installazione e l’etichettatura del nuovo certificato del sito.Utilizzare il parametro webseal-cert-keyfile-label nella stanza [ssl] del file diconfigurazione webseald.conf per designare il certificato come certificato attivo delserver WebSEAL (questa impostazione ricopre qualsiasi certificato designato come“predefinito” nel database dei file di chiavi).

Se sono necessari differenti certificati per altri scenari (ad esempio, per junctionautenticati reciprocamente), è possibile utilizzare il programma di utilità iKeymanper creare, installare e etichettare certificati supplementari.

Consultare “Configurazione dei parametri del database di chiavi” a pagina 37.

Abilitazione e disabilitazione dell’autenticazione mediantecertificato

E’ possibile specificare il modo in cui WebSEAL deve gestire l’autenticazionemediante certificati del client su SSL impostando il parametro accept-client-certs,ubicato nella stanza [certificate] del file di configurazione webseald.conf.

Per impostazione predefinita, WebSEAL non accetta certificati del client:[certificate]accept-client-certs = never

Ulteriori valori per questo parametro comprendono optional e required.

La seguente tabella elenca i valori consentiti per il parametro accept-client-certs:

Valore Descrizione

never Non vengono accettati certificati X.509 di client.

optional Viene richiesto ai client un certificato X.509 e si utilizzal’autenticazione basata su certificato, se il certificato viene fornito.

required Viene richiesto ai client un certificato X.509 e si utilizzal’autenticazione basata su certificato. Se il client non presenta uncertificato, la connessione non viene consentita.

Configurazione del meccanismo di autenticazione mediantecertificato

Il parametro cert-ssl specifica la libreria condivisa per l’associazione delleinformazioni di autenticazione certificato.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libsslauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata sslauthn.


Libreria condivisa


cert-ssl libsslauthn.so libsslauthn.a sslauthn.dll libsslauthn.sl


E’ possibile configurare il meccanismo di autenticazione via certificato immettendoil parametro cert-ssl con il nome, specifico per piattaforma, del file di libreriacondivisa nella stanza [authentication-mechanism] del file di configurazionewebseald.conf.

Solaris:[authentication-mechanisms]cert-ssl= libsslauthn.so

Windows:[authentication-mechanisms]cert-ssl = sslauthn.dll

Durante l’autenticazione di certificato, la libreria condivisa identifica l’utenteAccess Manager facendo corrispondere esattamente il Distinguished name (DN)del campo Oggetto del certificato del client con una voce DN esistente nel registroLDAP.

Condizioni di configurazioneSe la gestione del certificato del client è impostata su “required”, tutte le altreimpostazioni di autenticazione vengono ignorate per i client HTTPS.

Configurazione dell’autenticazione mediante intestazione HTTPAccess Manager supporta l’autenticazione mediante informazioni di intestazioneHTTP personalizzate fornite dal client o da un agente proxy.

Questo meccanismo richiede una funzione di associazione (una libreria condivisa)che associ i dati di intestazione garantiti (pre-autenticati) a un’identità AccessManager. WebSEAL può prendere questa identità e creare una credenziale perl’utente.

WebSEAL presuppone che i dati di intestazione HTTP personalizzati siano statiprecedentemente autenticati. Per questo motivo, si consiglia di implementarequesto metodo in modo esclusivo, senza altri metodi di autenticazione abilitati. E’possibile personalizzare i dati di intestazioni HTTP personalizzati.

Per impostazione predefinita, questa libreria condivisa è creata per associare datida intestazioni Entrust Proxy.

Abilitazione e disabilitazione dell’autenticazione medianteintestazione HTTP

Il parametro http-headers-auth, ubicato nella stanza [http-headers] del file diconfigurazione webseald.conf, abilita e disabilita il metodo di autenticazione diintestazione HTTP.v Per abilitare il metodo di autenticazione di intestazione HTTP, immettere “http”,

“https” o “both”.v Per disabilitare il metodo di autenticazione di intestazione HTTP, immettere

“none”.

Ad esempio:[http-headers]http-headers-auth = https


Specifica dei tipi di intestazioneE’ necessario specificare tutti i tipi di intestazione HTTP supportati nella stanza[auth-headers] del file di configurazione webseald.conf.[auth-headers]header = <header-type>

Per impostazione predefinita, questa libreria condivisa incorporata è codificata inmodo da supportare dati di intestazione Entrust Proxy.[auth-headers]header = entrust-client

E’ necessario personalizzare questo file per autenticare altri tipi di dati diintestazione speciali e, facoltativamente, associare tali dati a un’identità AccessManager. Per le risorse API, fare riferimento al manuale IBM Tivoli Access ManagerWebSEAL Developer’s Reference.

Configurazione del meccanismo di autenticazione diintestazione HTTP

Il parametro http-request specifica la libreria condivisa per l’associazioni delleinformazioni di intestazione per l’autenticazione HTTP.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libhttpauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata httpauthn.


Libreria condivisa


http-request libhttpauthn.so libhttpauthn.a httpauthn.dll libhttpauthn.sl

Per impostazione predefinita, questa libreria condivisa incorporata è codificata perassociare dati di intestazione Entrust Proxy a un’identità Access Manager valida. E’necessario personalizzare questo file per autenticare altri tipi di dati di intestazionespeciali e, facoltativamente, associare tali dati a un’identità Access Manager. Per lerisorse API, fare riferimento al manuale IBM Tivoli Access Manager WebSEALDeveloper’s Reference.

E’ possibile configurare il meccanismo di autenticazione via intestazione HTTPimmettendo il parametro http-request con il nome, specifico per piattaforma, delfile di libreria condivisa nella stanza [authentication-mechanism] del file diconfigurazione webseald.conf.

Ad esempio:

Solaris:[authentication-mechanisms]http-request = libhttpauthn.so

Windows:[authentication-mechanisms]http-request = httpauthn.dll


Condizioni di configurazione1. I cookie di ID sessione non vengono utilizzati per mantenere lo stato se

ssl-id-sessions = no. Per mantenere lo stato viene utilizzato il valore diintestazione unico.

2. Se il client rileva un errore di autorizzazione, il client riceve una pagina di“Accesso vietato” (HTTP 403).

3. Le intestazioni di cookie non possono essere trasmesse al meccanismo diautenticazione di intestazione HTTP.

Configurazione dell’autenticazione mediante indirizzo IPAccess Manager supporta l’autenticazione mediante un indirizzo IP fornito dalclient.

Abilitazione e disabilitazione dell’autenticazione di indirizzo IPIl parametro ipaddr-auth, ubicato nella stanza [ipaddr] del file di configurazionewebseald.conf, abilita e disabilita il metodo di autenticazione mediante indirizzoIP.v Per abilitare il metodo di autenticazione di indirizzo IP, immettere “http”,

“https” o “both”.v Per disabilitare il metodo di autenticazione di indirizzo IP, immettere “none”.

Ad esempio:[ipaddr]ipaddr-auth = https

Configurazione del meccanismo di autenticazione medianteindirizzo IP

L’autenticazione via indirizzo IP richiede una libreria condivisa personalizzata.Utilizzare il parametro http-request per questa libreria condivisa.

Configurazione dell’autenticazione tokenAccess Manager supporta l’autenticazione mediante un codice di accesso tokenfornito dal client.

Abilitazione e disabilitazione dell’autenticazione tokenIl parametro token-auth, ubicato nella stanza [token] del file di configurazionewebseald.conf, abilita e disabilita il metodo di autenticazione via token.v Per abilitare il metodo di autenticazione via token, immettere “http”, “https” o

“both”.v Per disabilitare il metodo di autenticazione via token, immettere “none”.

Ad esempio:[token]token-auth = https

Configurazione del meccanismo di autenticazione via tokenIl parametro token-cdas specifica la libreria condivisa per l’associazione delleinformazioni di autenticazione del codice di accesso token.


v Su UNIX, il file che fornisce la funzione di associazione incorporata è unalibreria condivisa denominata libxtokenauthn.

v Su Windows, il file che fornisce la funzione di associazione incorporata è unaDLL denominata xtokenauthn.


Libreria condivisa


token-cdas libxtokenauthn.so libxtokenauthn.a xtokenauthn.dll libxtokenauthn.sl

Per impostazione predefinita, questa libreria condivisa incorporata è codificata perl’associazione ai dati del codice di accesso token SecurID. E’ possibilepersonalizzare questo file per autenticare altri tipi di dati di token speciali e,facoltativamente, associare tali dati a un’identità Access Manager. Per le risorseAPI, fare riferimento al manuale IBM Tivoli Access Manager WebSEAL Developer’sReference.

E’ possibile configurare il meccanismo di autenticazione token immettendo ilparametro token-cdas con il nome, specifico per piattaforma, del filue di libreriacondivisa nella stanza [authentication-mechanism] del file di configurazionewebseald.conf. La libreria condivisa deve includere l’opzione e l’argomento –r<registry>. Il tipo di registro deve essere specificato come LDAP.

Ad esempio:

Solaris:[authentication-mechanisms]token-cdas = libxtokenauthn.so& -r LDAP

Windows:[authentication-mechanisms]token-cdas = xtokenauthn.dll& -r LDAP

Supporto MPA (multiplexing proxy agents)Access Manager fornisce soluzioni per la protezione di reti che utilizzano unagente MPA (Multiplexing Proxy Agent).

Gli agenti proxy standard (SPA) sono gateway che supportano le sessioni per-clienttra cliente il server di origine su SSL o HTTP. WebSEAL può applicarel’autenticazione SSL o HTTP normale a tali sessioni per-client.

I Multiplexing Proxy Agents (MPA) sono gateway conformi all’accesso di clientmultipli. Questi gateway sono a volte conosciuti come gateway WAP quando iclient effettuano l’accesso tramite WAP (Wireless Access Protocol). I gatewaystabiliscono un singolo canale autenticato con il server di origine e “incanalano”tutte le richieste e le risposte client su questo canale.

A WebSEAL, le informazioni su questo canale inizialmente appaiono come richiestemultiple provenienti da un client. WebSEAL deve distinguere tra l’autenticazionedel server MPA e l’ulteriore autenticazione di ciascun singolo client.


Poiché WebSEAL mantiene una sessione autenticata per MPA, devesimultaneamente mantenere sessioni separate per ogni client. Quindi, i dati disessione e il metodo di autenticazione utilizzati per MPA devono esere distinti(differenti) dai dati di sessione e dal metodo di autenticazione utilizzato dal client.

Tipi di dati di sessione e metodi di autenticazione validiIl tipo di dati di sessione utilizzato da MPA per WebSEAL deve essere distinto(differente) dal tipo di dati di sessione utilizzato dal client per WebSEAL. Latabella seguente elenca i tipi di sessione validi per MPA e per il client:

Tipi di sessione validi

MPA-WebSEAL Client-WebSEAL

ID sessione SSL

Intestazione HTTP Intestazione HTTP

Intestazione BA Intestazione BA

Indirizzo IP

Cookie Cookie

v Il client non può utilizzare un ID sessione SSL come tipo di dati di sessione.v Ad esempio, se MPA utilizza un’intestazione BA per un tipo di dati di sessione,

le scelte del client per il tipo di dati di sessione comprendono solo intestazioneHTTP e cookie.

v Se MPA utilizza un’intestazione HTTP per i dati di sessione, il client puòutilizzare un diverso tipo di intestazione HTTP.

v Il cookie specifico del server contiene solo informazioni sulla sessione e noncontiene informazioni di identità.

v Se il supporto MPA è abilitato, la funzione di ssl-id-sessions cambia.Normalmente, se ssl-id-sessions=yes, solo l’ID sessione SSL viene utilizzato permantenere sessioni per i client HTTPS. Per consentire a MPA di mantenere unasessione con un ID sessione SSL e fare in modo che i client mantengano sessioniutilizzando un altro metodo, questa restrizione viene rimossa. Vedere anche“Individuazione di tipi di dati ID sessione validi” a pagina 108.

Il metodo di autenticazione utilizzato da MPA per WebSEAL deve essere distinto(differente) dal metodo di autenticazione utilizzato dal client per WebSEAL. La

ClientB

MPAGateway

più sessioni su un unico canale SSLMPA viene autenticato con WebSEALMPA è membro del gruppowebseal -m pa-server s

WebSEALServer

ClientA

ClientC

A B C

i client vengono autenticati con WebSEAL

Figura 25. Comunicazione su un gateway MPA


tabella seguente elenca i metodi di autenticazione validi per MPA e per il client:

Tipi di autenticazione validi

MPA-WebSEAL Client-WebSEAL

Basic Authentication Basic Authentication

Moduli Moduli

Token Token

Intestazione HTTP Intestazione HTTP

Certificato

Indirizzo IP

v Ad esempio, se MPA utilizza Basic Authentication, le scelte del client per imetodi di autenticazione comprendono moduli, token e intestazione HTTP.

v I metodi di autenticazione mediante certificati e indirizzo IP non sono validi peressere utilizzati dal client.

v Normalmente, se l’autenticazione moduli (o token) è autenticata per unparticolare trasporto, Basic Authentication viene automaticamente disabilitata pertale trasporto (vedere “Configurazione del meccanismo Basic Authentication” apagina 116. Se il supporto MPA è abilitato, questa restrizione viene rimossa. Ciòconsente a MPA di collegarsi, ad esempio, con moduli (o token) e ai client dicollegarsi mediante Basic Authentication sullo stesso trasporto.

Flusso del processo di autenticazione per MPA e clientmultipli

1. L’amministratore del sistema WebSEAL effettua le seguenti operazionipreliminari:v Abilitare il supporto per MPA (Multiplexing Proxy Agents)v Creare un account Access Manager per lo specifico gateway MPAv Aggiungere tale account MPA al gruppo webseal-mpa-servers

2. I client si collegano al gateway MPA.3. Il gateway traduce la richiesta in una richiesta HTTP.4. Il gateway autentica il client.5. Il gateway stabilisce una connessione tramite WebSEAL con la richiesta del

client.6. MPA effettua l’autenticazione con WebSEAL (utilizzando un metodo diverso

da quello del client) e da ciò deriva un’identità per MPA (che già dispone diun account WebSEAL).

7. WebSEAL verifica l’appartenenza di MPA al gruppo webseal-mpa-servers.8. Una credenziale per MPA viene creata e contrassegnata come tipo speciale

MPA nella cache.Sebbene questa credenziale MPA accompagni ogni futura richiesta del client,non viene utilizzata per i controlli di autorizzazione su tali richieste.

9. A questo punto WebSEAL ha bisogno di identificare ulteriormente ilproprietario della richiesta.MPA è in grado di distinguere i vari client per instradare correttamente lerichieste di login.

10. Il client effettua il logine e si autentica utilizzando un metodo distinto dal tipodi autenticazione utilizzato per MPA.

11. WebSEAL crea una credenziale dai dati di autenticazione del client.


12. Il tipo di dati di sessione utilizzato da ciascun client deve essere distinto daltipo di dati di sessione utilizzato da MPA.

13. Il servizio di autorizzazione permette o rifiuta l’accesso agli oggetti protetti inbase alla credenziale dell’utente e alle autorizzazioni ACL dell’oggetto.

Abilitazione e disabilitazione dell’autenticazione MPAIl parametro mpa, ubicato nella stanza [mpa] del file di configurazionewebseald.conf, abilita e disabilita l’autenticazione MPA:v Per abilitare il metodo di autenticazione MPA, immettere “yes”.v Per disabilitare il metodo di autenticazione MPA, immettere “no”.

Ad esempio:[mpa]mpa = yes

Creazione di un account utente per MPAPer informazioni sulla creazione di account utente, fare riferimento al manuale IBMTivoli Access Manager - Guida di base per il responsabile di sistema.

Aggiunta dell’account MPA al gruppo webseal-mpa-serversPer informazioni sulla gestione di gruppi, fare riferimento al manuale IBM TivoliAccess Manager - Guida di base per il responsabile di sistema.

Limitazioni dell’autenticazione MPAQuesto rilascio di Access Manager supporta esclusivamente un MPA per serverWebSEAL.

Configurazione della riautenticazione basata su criteri di protezioneAccess Manager WebSEAL può costringere un utente ad eseguire un loginsupplementare (riautenticazione) per assicurarsi che un utente che accede ad unarisorsa protetta sia la stessa persona inizialmente autenticata all’avvio dellasessione. La riautenticazione può essere attivata mediante un POP (ProtectedObject Policy) sull’oggetto protetto oppure mediante scadenza del valore ditimeout di inattività della cache di sessione WebSEAL.

Questa sezione illustra la riautenticazione basata sul criterio di protezione, comeimposta da un attributo esteso POP.

Condizioni riguardanti la riautenticazione POPLa riautenticazione forzata fornisce una protezione supplementare per le risorsesensibili nel dominio protetto. La riautenticazione basata sui criteri di protezioneviene attivata da uno specifico attributo esteso contenuto in un POP che proteggel’oggetto risorsa richiesto. Il POP può essere direttamente collegato ad un oggetto,oppure, l’oggetto può ereditare le condizioni del POP da un oggetto principale.

La riautenticazione è supportata dai seguenti metodi di autenticazione WebSEAL:v Autenticazione moduli (nome utente e password)v Autenticazione token

Inoltre, è possibile scrivere un CDAS nome utente/password personalizzato persupportare la riautenticazione.


La riautenticazione presuppone che l’utente si sia collegato inizialmente al dominioprotetto e che sia presente una credenziale valida per tale utente. Durante lariautenticazione, l’utente deve collegarsi utilizzando la stessa identità con la qualeera stata generata la credenziale esistente. Access Manager conserva leinformazioni della sessione originale dell’utente, incluso la credenziale, durante lariautenticazione. La credenziale non viene sostituita durante la riautenticazione.

Durante la riautenticaaione, WebSEAL memorizza nella cache la richiesta che haportato alla riautenticazione. Dopo una riautenticazione riuscita, i dati nella cachevengono utilizzati per ricostruire la richiesta. Consultare “Configurazione cache dirichieste WebSEAL del server” a pagina 67.

Se la riautenticazione non riesce, WebSEAL restituisce nuovamente la richiesta dilogin. Se la riautenticazione ha esito positivo, ma il controllo ACL non riesce pertale risorsa, viene restituito un errore 403 di “Accesso vietato” e all’utente vienerifiutato l’accesso alla risorsa. In entrambi i casi, l’utente non viene mai scollegato.Utilizzando una credenziale ancora valida, l’utente può interrompere il processo diriautenticazione (richiedendo un altro URL) e partecipare ancora al dominioprotetto accedendo ad altre risorse che non richiedono la riautenticazione.

Una configurazione è disponibile per reimpostare il timer di durata della cache disessione WebSEAL. Inoltre, è possibile configurare un intervallo per permettere untempo sufficiente per il completamento del processo di riautenticazione prima chescada il timeout di durata della cache di sessione.

Creazione e applicazione del POP di riautenticazioneLa riautenticazione forzata basata su criteri di protezione viene configuratamediante la creazione di un POP (protected object policy) con uno specialeattributo esteso denominato “reauth”. E’ possibile collegare questo POP a qualsiasioggetto che richieda una protezione extra fornita mediante la riautenticazioneforzata.

Ricordare che tutti gli elementi secondari dell’oggetto a cui si applica il POPereditano allo stesso modo le condizioni del POP. Ciascun oggetto secondariorichiesto richiede una separata riautenticazione.

Utilizzare i comandi pdadmin pop create, pdadmin pop modify e pdadmin popattach. L’esempio riportato di seguito illustra la creazione di un POP denominato“secure” con l’attributo esteso reauth e il suo collegamento a un oggetto(budget.html):pdadmin> pop create securepdadmin> pop modify secure set attribute reauth truepdadmin> pop attach /WebSEAL/hostA/junction/budget.html secure

Chiunque provi ad accedere a budget.html viene forzato alla riautenticazioneutilizzando la stessa identità e lo stesso metodo di autenticazione con i quali erastata generata la credenziale esistente.

Se l’utente che richiede la risorsa non è autenticato, il POP ne forzal’autenticazione. Nessuna riautenticazione è necessaria per tale risorsa dopo unlogin iniziale riuscito.

Dettagli sul programma di utilità di riga comandi pdadmin sono reperibili nelmanuale IBM Tivoli Access Manager - Guida per il responsabile di sistema base.


Configurazione di reimpostazione ed estensione della duratadi cache di sessione

Reimpostazione del valore di durata della cache di sessioneLa cache di sessione dell’utente ha una durata limitata, come specificato dalparametro timeout nella stanza [session] del file di configurazione webseald.conf.Il valore predefinito, in secondi, è 3600 (1 ora):[session]timeout = 3600

Indipendentemente dall’attività o dall’inattività della sessione, la cache di sessioneviene rimossa quando si raggiunge il valore di durata, e a questo punto l’utenteviene scollegato.

Tuttavia, è possibile configurare la durata della cache di sessione in modo dapoterla reimpostare ogni volta che si verifica la riautenticazione. Con questaconfigurazione, la sessione dell’utente non avrà più un singolo valore di duratamassima. Ogni volta che si verifica la riautenticazione, il valore di durata dellacache di sessione viene reimpostato.

E’ possibile configurare la reimpostazione della durata della cache di sessione conil parametro reauth-reset-lifetime nella stanza [reauthentication] del file diconfigurazione webseald.conf:[reauthentication]reauth-reset-lifetime = yes

Il valore predefinito è “no”.

Questo parametro è anche adatto per la riautenticazione dovuta alla scadenza delvalore di timeout di inattività della cache di sessione. Consultare “Configurazionedella riautenticazione basata sul criterio di inattività della sessione” a pagina 130.

Estensione del valore di durata della cache di sessioneE’ possibile che il valore di durata della cache di sessione possa scadere mentre unutente esegue la riautenticazione. Questa situazione si verifica alle seguenticondizioni:v L’utente richiede una risorsa protetta da un POP di riautenticazionev Il valore di durata della cache di sessione dell’utente è molto prossimo alla

scadenza

La durata della cache di sessione può scadere dopo che il modulo di login diriautenticazione è stato inviato all’utente e prima che il modulo di logincompletato venga restituito. Quando il valore di durata della cache di sessionescade, la voce della cache di sessione viene eliminata. Quando il modulo di loginviene restituito a WebSEAL, non esiste più alcuna sessione per tale utente. Inoltre,tutti i dati di richiesta dell’utente presenti nella cache vengono persi.

E’ possibile configurare un’estensione del tempo, o “periodo di grazia”, per ladurata della cache di sessione che dovesse scadere durante la riautenticazione. Ilparametro reauth-extend-lifetime nella stanza [reauthentication] del file diconfigurazione webseald.conf fornisce questa estensione di tempo, in secondi. Adesempio:[reauthentication]reauth-extend-lifetime = 20


Il valore predefinito, “0”, non offre alcuna estensione al valore di timeout dellacache.

Il parametro reauth-extend-lifetime si applica agli utenti che dispongono di voci dicache di sessione esistenti e che necessitano la riautenticazione. Ad esempio:v Utenti che eseguono la riautenticazione dovuta al criterio di protezione POPv Utenti che eseguono la riautenticazione come risultato dell’inattività della cache

di sessionev Utenti che eseguono l’autenticazione a fasi

L’opzione reauth-extend-lifetime deve essere utilizzata insieme all’opzionereauth-reset-lifetime=yes.

Questo parametro è anche adatto per la riautenticazione dovuta alla scadenza delvalore di timeout di inattività della cache di sessione. Consultare “Configurazionedella riautenticazione basata sul criterio di inattività della sessione” a pagina 130.

Configurazione della riautenticazione basata sul criterio di inattivitàdella sessione

Access Manager WebSEAL può costringere un utente ad eseguire un loginsupplementare (riautenticazione) per assicurarsi che un utente che accede ad unarisorsa protetta sia la stessa persona inizialmente autenticata all’avvio dellasessione. La riautenticazione può essere attivata mediante un POP (ProtectedObject Policy) sull’oggetto protetto oppure mediante scadenza del valore ditimeout di inattività della cache di sessione WebSEAL.

Questa sezione illustra la riautenticazione basata sulla scadenza del valore ditimeout di inattività della cache di sessione WebSEAL.

Condizioni riguardanti la riautenticazione per inattivitàLa riautenticazione forzata fornisce una protezione supplementare per le risorsesensibili nel dominio protetto. La riautenticazione basata sul criterio di inattività disessione viene abilitata mediante un parametro di configurazione ed è attivatadalla scadenza del valore di timeout di inattività della cache di sessione.

La riautenticazione è supportata dai seguenti metodi di autenticazione perWebSEAL:v Autenticazione moduli (nome utente e password)v Autenticazione token

Inoltre, è possibile scrivere un CDAS nome utente/password personalizzato persupportare la riautenticazione.

La riautenticazione presuppone che l’utente si sia collegato inizialmente al dominioprotetto e che sia presente una credenziale valida per tale utente. Durante lariautenticazione, l’utente deve collegarsi utilizzando la stessa identità con la qualeera stata generata la credenziale esistente. WebSEAL conserva le informazioni dellasessione originale dell’utente, incluso la credenziale, durante la riautenticazione. Lacredenziale non viene sostituita durante la riautenticazione.

Durante la riautenticaaione, WebSEAL memorizza nella cache la richiesta che haportato alla riautenticazione. Dopo una riautenticazione riuscita, i dati nella cache


vengono utilizzati per ricostruire la richiesta. Consultare “Configurazione cache dirichieste WebSEAL del server” a pagina 67.

La sessione di un utente è normalmente regolata da un valore di inattività disessione e da un valore di durata della sessione. Quando WebSEAL vieneconfigurato per la riautenticazione basata sull’inattività di sessione, la cache disessione dell’utente viene “contrassegnata” ogni volta che scade il valore ditimeout di inattività della sessione. La cache di sessione (contenente la credenzialedell’utente) non viene rimossa. L’utente può continuare ad accedere alle risorsenon protette. Tuttavia, se l’utente richiede una risorsa protetta, WebSEAL invia unarichiesta di login.

Dopo una riautenticazione riuscita, l’“indicatore” di sessione inattiva viene rimossoe il timer di inattività viene reimpostato. Tuttavia, il valore di durata della cache disessione determina comunque la lunghezza massima della sessione. Quando ilvalore di durata scade, la sessione viene terminata indipendentemente dall’attività.

Se la riautenticazione non riesce, WebSEAL restituisce nuovamente la richiesta dilogin. La cache di sessione resta “contrassegnata” e l’utente può continuare comenon autenticato fino alla scadenza del valore di durata della cache di sessione.

Se la riautenticazione ha esito positivo, ma il controllo ACL non riesce per talerisorsa, viene restituito un errore 403 di “Accesso vietato” e all’utente vienerifiutato l’accesso alla risorsa.

Due altre condizioni possono determinare la fine di una sessione dell’utente:l’esplicito scollegamento dell’utente o l’intervento di un responsabile. Consultare“Conclusione delle sessioni utente” a pagina 214.

E’ disponibile una configurazione per reimpostare il timer di durata della cache disessione WebSEAL. Inoltre, è possibile configurare un intervallo per permettere untempo sufficiente per il completamento del processo di riautenticazione prima chescada il timeout di durata della cache di sessione.

Abilitazione della riautenticazione per inattivitàPer configurare WebSEAL in modo da “contrassegnare” le sessioni inattive anzichérimuoverle dalla cache di sessione, impostare il valore del parametroreauth-for-inactive su “yes” nella stanza [reauthentication] del file diconfigurazione webseald.conf:[reauthentication]reauth-for-inactive = yes

Il valore predefinito per questo parametro è “no”.

Configurazione di reimpostazione ed estensione della duratadi cache di sessione

Reimpostazione del valore di durata della cache di sessioneLa cache di sessione dell’utente ha una durata limitata, come specificato dalparametro timeout nella stanza [session] del file di configurazione webseald.conf.Il valore predefinito, in secondi, è 3600 (1 ora):[session]timeout = 3600


Indipendentemente dall’attività o dall’inattività della sessione, la cache di sessioneviene rimossa quando si raggiunge il valore di durata, e a questo punto l’utenteviene scollegato.

Tuttavia, è possibile configurare la durata della cache di sessione in modo dapoterla reimpostare ogni volta che si verifica la riautenticazione. Con questaconfigurazione, la sessione dell’utente non avrà più un singolo valore di duratamassima. Ogni volta che si verifica la riautenticazione, il valore di durata dellacache di sessione viene reimpostato.

E’ possibile configurare la reimpostazione della durata della cache di sessione conil parametro reauth-reset-lifetime nella stanza [reauthentication] del file diconfigurazione webseald.conf:[reauthentication]reauth-reset-lifetime = yes

Il valore predefinito è “no”.

Questo parametro è anche adatto per il criterio di sicurezza per la riautenticazione(POP). Consultare “Configurazione della riautenticazione basata su criteri diprotezione” a pagina 127.

Estensione del valore di durata della cache di sessioneE’ possibile che il valore di durata della cache di sessione possa scadere mentre unutente esegue la riautenticazione. Questa situazione si verifica alle seguenticondizioni:v L’utente richiede una risorsa protetta da un POP di riautenticazionev Il valore di durata della cache di sessione dell’utente è molto prossimo alla

scadenza

La durata della cache di sessione può scadere dopo che il modulo di login diriautenticazione è stato inviato all’utente e prima che il modulo di logincompletato venga restituito. Quando il valore di durata della cache di sessionescade, la voce della cache di sessione viene eliminata. Quando il modulo di loginviene restituito a WebSEAL, non esiste più alcuna sessione per tale utente. Inoltre,tutti i dati di richiesta dell’utente presenti nella cache vengono persi.

E’ possibile configurare un’estensione del tempo, o “periodo di grazia”, per ladurata della cache di sessione che dovesse scadere durante la riautenticazione. Ilparametro reauth-extend-lifetime nella stanza [reauthentication] del file diconfigurazione webseald.conf fornisce questa estensione di tempo, in secondi. Adesempio:[reauthentication]reauth-extend-lifetime = 20

Il valore predefinito, “0”, non offre alcuna estensione al valore di timeout dellacache.

Il parametro reauth-extend-lifetime si applica agli utenti che dispongono di voci dicache di sessione esistenti e che necessitano la riautenticazione. Ad esempio:v Utenti che eseguono la riautenticazione dovuta al criterio di protezione POPv Utenti che eseguono la riautenticazione come risultato dell’inattività della cache

di sessionev Utenti che eseguono l’autenticazione a fasi


L’opzione reauth-extend-lifetime deve essere utilizzata insieme all’opzionereauth-reset-lifetime=yes.

Questo parametro è anche adatto per il criterio di sicurezza per la riautenticazione(POP). Consultare “Configurazione della riautenticazione basata su criteri diprotezione” a pagina 127.


Capitolo 6. Soluzioni CDSSO (cross-domain sign-on)

Quando WebSEAL viene implementato come server proxy per fornire la protezionea un dominio protetto, viene spesso richiesto di fornire soluzioni per single sign-onalle risorse. Questo capitolo illustra due soluzioni CDSSO (cross-domain singlesign-on).

Indice degli argomenti:v “Configurazione autenticazione CDSSO” a pagina 135v “Configurazione single sign-on e-community” a pagina 139

Configurazione autenticazione CDSSOIl CDSSO (Cross-Domain Single Sign-on) di Access Manager fornisce unmeccanismo per il trasferimento di credenziali utente attraverso domini protettimultipli. CDSSO consente agli utenti Web di eseguire un singolo collegamento(single sign-on) e spostarsi senza differenze tra due domini protetti separati. Ilmeccanismo di autenticazione CDSSO non dipende da un Master AuthenticationServer (fare riferimento a SSO e-Community).

CDSSO supporta l’architettura di rete dimensionabile in scala consentendol’integrazione di domini protetti multipli. Ad esempio, una rete esterna aziendaleestesa può essere impostata con due o più domini unici, ciascuno dei quali con ipropri utenti e il proprio spazio oggetti. CDSSO consente lo spostamento di utentitra i domini mediante un singolo collegamento (single sign-on).

Quando un utente effettua una richiesta per una risorsa ubicata in un altrodominio, il meccanismo CDSSO trasferisce un token di identità utente crittografatadal primo dominio al secondo dominio. Il secondo dominio ha ora l’identitàdell’utente (come autenticato nel primo dominio) e l’utente non viene costretto adeseguire un altro login.

Integrazione di una libreria condivisa CDMF personalizzataIn molti scenari CDSSO, l’associazione uno a uno predefinita tra utenti in differentidomini potrebbe non soddisfare tutti i requisiti di distribuzione.

CDMF (Cross-domain Mapping FrameWork) è un’interfaccia di programmazioneche consente di creare una libreria condivisa personalizzata in grado di gestireattributi estesi dell’utente e fornire servizi di associazione per l’identità dell’utente.

L’interfaccia di programmazione CDMF consente una flessibilità nellapersonalizzazione dell’associazione di identità utente e nella gestione degli attributidell’utente.

Flusso del processo di autenticazione per CDSSO con CDMFLa seguente descrizione del flusso di processo è illustrata in Figura 26.1. Qualsiasi utente che intende partecipare in domini multipli deve disporre di un

account valido nel dominio primario e di un’identità che può essere associatain un valido account in ciascuno dei domini remoti di partecipazione.


Un utente non può richiamare la funzionalità CDSSO senza inizialmenteeffettuare l’autenticazione in un dominio protetto iniziale (A) contenentel’account dell’utente.

2. L’utente effettua una richiesta per accedere a una risorsa nel dominio Battraverso un collegamento personalizzato su una pagina Web.Il collegamento contiene un’espressione CDSSO speciale:/pkmscdsso?<URL-destinazione>

Ad esempio:/pkmscdsso?https://www.domainB.com/index.html

3. La richiesta viene prima elaborata dal server WebSEAL nel dominio A.WebSEAL crea un token di autenticazione che contiene l’identità AccessManager dell’utente (nome abbreviato), il dominio corrente (“A”), ulteriori datisull’utente e una registrazione data/ora.I dati supplementari sull’utente vengono ottenuti mediante un richiamo allalibreria condivisa CDMF personalizzata (cdmf_get_usr_attributes). Questalibreria ha la capacità di fornire attributi dell’utente che possono essereutilizzati dal dominio B durante il processo di associazione dell’utente.WebSEAL triple-DES codifica questi dati token con la chiave simmetricagenerata dal programma di utilità cdsso_key_gen. Questo file di chiavi ècondiviso e memorizzato nella stanza [cdsso-peers] del file di configurazionewebseald.conf su entrambi i server WebSEAL del dominio A e del dominio B.Il token contiene una registrazione data/ora configurabile (authtoken-lifetime)che definisce la durata del token. La registrazione data/ora, quandocorrettamente configurata, può impedire attacchi a ripetizione.

4. Il server WebSEAL del dominio A reindirizza la richiesta, più il tokencrittografato, al browser e, quindi, al server WebSEAL del dominio B(reindirizzamento HTTP).

5. Il server WebSEAL del dominio B utilizza la propria versione dello stesso file dichiavi per decodificare e convalidare il token come proveniente dal dominio diriferimento.

6. Il server WebSEAL del dominio B richiama una libreria del meccanismo diautenticazione CDSSO. Questa libreria CDSSO, a sua volta, richiama la libreriaCDMF personalizzata che esegue l’effettiva associazione dell’utente(cdmf_map_usr).La libreria CDMF ritrasmette l’identità dell’utente, e facoltativamente i datisupplementari sugli attributi dell’utente, alla libreria CDSSO. La libreria CDSSOutilizza tali informazioni per creare una credenziale.

7. Il servizio di autorizzazione del dominio B permette o rifiuta l’accesso aglioggetti protetti in base alla credenziale dell’utente e alle specificheautorizzazioni ACL associate agli oggetti richiesti.


Abilitazione e disabilitazione dell’autenticazione CDSSOIl parametro cdsso-auth, ubicato nella stanza [cdsso] del file di configurazionewebseald.conf, abilita e disabilita il metodo di autenticazione CDSSO.v Per abilitare il metodo di autenticazione CDSSO, immettere “http”, “https” o

“both”.v Per disabilitare il metodo di autenticazione CDSSO, immettere “none”.

Ad esempio:[cdsso]cdsso-auth = https

Configurazione del meccanismo di autenticazione CDSSOIl parametro di configurazione cdsso specifica la libreria condivisa codificata perl’associazione delle informazioni di autenticazione.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libcdssoauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata cdssoauthn.


Libreria condivisa


cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

E’ possibile configurare il meccanismo di autenticazione CDSSO immettendo ilparametro cdsso con il nome, specifico per piattaforma, del file di libreriacondivisa nella stanza [authentication-mechanism] del file di configurazionewebseald.conf.

Ad esempio:

WebSEALA

single sign-onClient

Dominio A

/

WebSEALB

Dominio B

/

SSL

CDMF

condivisaLibreria

CDMF

condivisaLibreria

CDSSOLibreria

/pkmscdsso

!

!

!

I client selezionano il collegamento al Dominio B.

WebSEAL B decodifica e convalida il token.

Vengono create le credenziali e il client diventa

!

!

Il CDSSO di WebSEAL A utilizza la libreria CDMFper ichiamare informazioni aggiuntive sull’utente.Quindi crea e invia un token ID codificato insiemealla richiesta.

Il CDSSO di WebSEAL B richiama la libreriacondivisa CDMF per individuare l’identitàdell’utente.

Figura 26. Processo CDSSO (cross-domain single sign-on) con CDMF

Capitolo 6. Soluzioni CDSSO (cross-domain sign-on) 137

Solaris:[authentication-mechanisms]cdsso = libcdssoauthn.so

Windows:[authentication-mechanisms]cdsso = cdssoauthn.dll

Codifica dei dati del token di autenticazioneWebSEAL deve codificare i dati di autenticazione sistemati nel token utilizzandouna chiave generata dal programma di utilità cdsso_key_gen. E’ necessario“sincronizzare” questa chiave condividendo il file di chiavi con tutti i serverWebSEAL in ogni dominio partecipante. Ogni server WebSEAL partecipante inogni dominio deve utilizzare la stessa chiave.

Nota: La creazione e la distribuzione dei file di chiavi non fa parte del processoCDSSO di Access Manager.

Il programma di utilità cdsso_key_gen richiede la specifica dell’ubicazione(percorso assoluto) del file di chiavi quando si esegue il programma di utilitàstesso:

UNIX: # cdsso_key_gen <percorso-assoluto>

Windows: MSDOS> cdsso_key_gen <percorso-assoluto>

Immettere l’ubicazione di questo file di chiavi nella stanza [cdsso-peers] del file diconfigurazione webseald.conf del server WebSEAL partecipante in ogni dominio. Ilformato comprende il nome della macchina WebSEAL e la posizione del file dichiavi:[cdsso-peers]<nome-macchina-webseal> = <ubicazione-file di chiavi>

Esempio di configurazione del dominio A:[cdsso-peers]www.domainB.com = <percorso>/A-B.key

Esempio di configurazione del dominio B:[cdsso-peers]www.domainA.com = <percorso>/A-B.key

Nell’esempio precedente, il file A-B.key verrebbe generato su una macchina (adesempio, WebSEAL A) e manualmente copiato (con attenzione) sull’altra macchina(ad esempio, WebSEAL B).

Configurazione della registrazione data/ora del tokenIl token contiene una registrazione data/ora configurabile che definisce la duratadel token di identità. Una volta scaduta la registrazione data/ora, il token vieneconsiderato non valido e non è più utilizzato. La registrazione data/ora vieneutilizzata per aiutare nella prevenzione da attacchi a ripetizione mediantel’impostazione di un valore sufficientemente breve da impedire la sottrazione deltoken e la sua ripetizione durante la durata.


Il parametro authtoken-lifetime, ubicato nella stanza [cdsso] del file diconfigurazione webseald.conf, imposta il valore della durata del token. Il valore èespresso in secondi. Il valore predefinito è 180:[cdsso]authtoken-lifetime = 180

E’ necessario tenere in conto qualsiasi differenza oraria tra i domini partecipanti.

Espressione dei collegamenti HTML CDSSOI collegamenti HTML alle risorse su un dominio protetto secondario devonocontenere un’espressione CDSSO speciale:/pkmscdsso?<URL-destinazione>

Ad esempio:/pkmscdsso?https://www.domainB.com/index.html

Protezione del token di autenticazioneMentre il token di autenticazione non contiene informazioni di autenticazione(quali nome utente e password), contiene però un’identità utente di fiduciaaccettata nel dominio di ricezione. Lo stesso token deve quindi essere protettocontro accesso fraudolento e ripetizione.

Il token è protetto contro l’accesso fraudolento al di fuori del collegamentoattraverso l’utilizzo di SSL per proteggere le comunicazioni tra i server WebSEAL egli utenti. Il token potrebbe essere sottratto dalla cronologia di browser dell’utente.Il formato data/ora sul token dovrebbe essere abbastanza breve da rendereimprobabile questa sottrazione e la conseguente ripetizione durante la sua durata.

Tuttavia, un token che è scaduto rispetto al proprio formato data/ora è ancoravulnerabile agli attacchi crittografici. Se la chiave utilizzata per codificare questotoken viene scoperta e compromessa, un utente malizioso potrebbe creare i propritoken personali.

Questi token potrebbero poi essere inseriti in un “flusso pseudo-CDSSO”. Esarebbero indistinguibili dai token di autenticazione reali per i server WebSEALche partecipano al dominio CDSSO. Per questa ragione, le chiavi utilizzate perproteggere i token devono essere anche gestite con cura, e cambiateperiodicamente.

Configurazione single sign-on e-communitySSO (single sign-on) e-community è un’altra implementazione dell’autenticazionetra domini in un ambiente Access Manager. Lo scopo dell’autenticazione tradomini è di consentire agli utenti di accedere a risorse su più server in più dominisenza doversi riautenticare.

Una “e-community” è un gruppo di domini distinti (Access Manager o DNS) chepartecipano ad un rapporto commerciale. Questi domini partecipanti possonoessere configurati come parte di un’azienda (magari utilizzando differenti nomiDNS per motivi geografici), oppure come aziende diverse con qualche relazione traloro (ad esempio, la sede aziendale, una compagnia di assicurazioni e un’aziendadi gestione finanziaria).


In qualsiasi scenario, c’é sempre un dominio designato come dominio “home” o“proprietario”. Nel caso di aziende partecipanti, il dominio home è quello chedetiene gli accordi commerciali che governano l’e-community.

In entrambi gli scenari, le informazioni di autenticazione sugli utenti chepartecipano all’e-community (inclusi nomi utenti e password utilizzati perl’autenticazione) vengono conservate nel dominio home. Questa sistemazione offreun singolo punto di riferimento per l’amministrazione, ad esempio tutte lechiamate all’interno dell’e-community fanno riferimento al dominio home.

In alternativa, è possibile utilizzare il gestore di portale Web di Access Managerper delegare la gestione di tali informazioni in modo che i domini partecipantiabbiano la responsabilità dell’amministrazione dei propri utenti.

Il diagramma riportato di seguito illustra un esempio di e-community con duedomini partecipanti: il dominio A (dA.com) e il dominio B (dB.com). In questoesempio, il dominio A rappresenta il dominio home o proprietario. Il dominio B èun dominio partecipante, o “remoto”.

Il dominio home ha il pieno controllo degli utenti, cioè, ne controlla leinformazioni di autenticazione. A prescindere da dove un utente effettua unarichiesta di risorse, il dominio home è sempre quello che in cui l’utente deveautenticarsi.

L’autenticazione si verifica attraverso un server di autenticazione principale (MAS),un server (o una serie di server di replica) ubicato nel dominio home e configuratoper l’autenticazione di tutti gli utenti. Il diagramma rappresenta il MAS comemas.dA.com. Il compito del MAS dovrebbe essere limitato alla fornitura dei servizidi autenticazione. Il MAS non deve contenere risorse disponibili agli utenti.

Client

Dominio A Dominio B

mas.dA.com

WebSEAL 1

WebSEAL 2

WebSEAL MAS WebSEAL 3

WebSEAL 4

ws2.dA.com

ws1.dA.com

ws3.dB.com

ws4.dB.com

Figura 27. Il modello e-community


Dopo che un utente ha effettuato una corretta autenticazione presso il MAS,quest’ultimo genera un token “di convalida”. Questo token viene inviato al serversul quale l’utente effettua la richiesta. Il server tratta questo token “di convalida(vouch for)” come prova della corretta autenticazione dell’utente presso MAS epermette all’utente di partecipare all’e-community.

Il trasferimento di informazioni tra domini e-community viene descritta indettaglio nella sezione “Flusso del processo e-community” a pagina 141.

Funzioni e requisiti dell’e-communityv Il modello supporta l’accesso alle risorse attraverso URL diretti (segnalibri).

Questa funzione contrasta con il modello CDSSO che si affida ad uncollegamento configurato appositamente, pkmscdsso (vedere “Configurazioneautenticazione CDSSO” a pagina 135).

v L’implementazione e-community richiede una configurazione coerente su tutti iserver WebSEAL in tutti i domini partecipanti all’e-community.

v Tutti gli utenti che partecipano all’e-community si autenticano attraverso unsingolo server di autenticazione principale (MAS) ubicato nel dominio home.

v L’implementazione e-community consente l’autenticazione “locale” in dominiremoti se l’utente non dispone di un valido account con MAS (ad esempio, gliutenti appartenenti al dominio B che non partecipano all’e-community tra idomini A e B).All’utente che non ottiene l’autenticazione con il MAS quando richiede unarisorsa situata in un dominio non-MAS (ma partecipante), viene data lapossibilità di effettuare l’autenticazione con il server locale in cui sta per essereeffettuata la richiesta.

v Il MAS (ed eventualmente altri server selezionati nei domini remoti)“convalidano” l’identità autenticata dell’utente.

v Cookie specifici di dominio vengono utilizzati per identificare il server che puòfornire servizi di “convalida”. Ciò consente ai server di un dominio remoto dirichiedere localmente informazioni di “convalida”. Il contenuto codificato deicookie di e-community non comprende informazioni sulla sicurezza esull’identità dell’utente.

v Token speciali vengono utilizzati per trasmettere l’identità dell’utente“convalidato” in forma crittografata. Il token “di convalida” non contiene datieffettivi sull’autenticazione dell’utente. L’integrità viene fornita mediante unachiave segreta condivisa (triple-DES). Il token contiene un valore di timeout (didurata) per limitare l’esistenza della validità del token stesso.

v L’implementazione e-community è supportata su HTTP e HTTPS.v I singoli domini e-community gestiscono le identità dei propri utenti e i privilegi

associati. E’ possibile utilizzare l’API CDMF (Cross-domain Mapping Function)per associare un utente di un dominio remoto a un valido utente del dominiolocale.Se i domini e-community condividono identità di utenti globali, questa funzionedi associazione non è necessaria.

v La configurazione per e-community è impostata nel file webseald.conf di ogniserver WebSEAL partecipante.

Flusso del processo e-communityUna e-community è composta da un server di autenticazione principale WebSEAL(MAS) e da server WebSEAL aggiuntivi ubicati sul dominio home e su dominiremoti. Il MAS può esistere come singola istanza di un server WebSEAL, oppure


come serie di repliche WebSEAL ubicate in un programma di bilanciamento delcarico (tale programma viene identificato come MAS).

Tutti i server WebSEAL partecipanti, locali e remoti, devono essere configurati perl’utilizzo del MAS del dominio home per l’autenticazione iniziale dei client. Questoè un requisito rigido per i server del dominio home e meno rigido per i server deidomini remoti. Ad esempio, alcuni server nei domini remoti possono essereconfigurati per gestire la propria personale autenticazione. Questi server, e lerisorse da loro protette, possono operare indipendentemente dall’e-community,anche se sono ubicati in un dominio partecipante all’e-community.

L’implementazione e-community si basa su un sistema di “convalida”.Normalmente, quando un utente richiede una risorsa da un server WebSEAL con ilquale l’utente non ha stabilito una sessione valida, WebSEAL richiede all’utente leinformazioni di autenticazione. In una configurazione e-community, il serverWebSEAL identifica un server di “convalida” e richiede a tale server la confermache l’utente è autenticato.

Il server di “convalida” dispone di valide informazioni di credenziale per taleutente. Per la prima richiesta dell’utente, il server “convalida” è sempre il MAS. IlMAS continua a servire da server “di convalida” per le risorse ubicate nel dominiohome. Man mano che l’utente continua a richiedere risorse sull’e-community, unsingolo server in ogni dominio remoto può creare la propria credenziale personaleper l’utente (in base ai dati sull’identità dell’utente forniti dal MAS) e assumere asua volta il ruolo di server di “convalida” per le risorse presenti nel propriodominio.

La verifica richiesta dal server di “convalida” assume la forma di un token “diconvalida”. Il server di “convalida” crea il token e lo restituisce al server WebSEALrichiedente. Le informazioni sull’identità dell’utente nel token sono crittografate. Iltoken contiene un limite di durata.

Alla ricezione del token “di convalida”, il server richiedente crea credenziali e unasessione locale per tale utente. L’utente può ora accedere alla risorsa richiesta inbase a normali controlli di autorizzazione. L’utente ha il vantaggio di non doversiriautenticare: questo è un obiettivo del modello e-community.

Procedendo nel flusso del processo e-community, fare riferimento a questodiagramma come promemoria della presente sezione. Il flusso di processo descrivedue possibili scenari di PRIMO accesso (1 e 2). Questi sono seguiti da due possibiliscenari di SUCCESSIVO accesso (3 e 4), immediatamente dopo 2 o 3. Lo scenario 5si verifica in qualsiasi momento dopo l’accesso iniziale.


Server “Vouch For”

v Il MAS è sempre utilizzato per autenticare un utente che accede a una qualsiasiparte dell’e-community per la prima volta.Il MAS dovrebbe essere eseguito esclusivamente come server di autenticazione enon come fornitore di risorse. Il MAS non dovrebbe essere configurato peroperare come server di autenticazione principale e, contemporaneamente,proteggere le risorse. Questa raccomandazione riguarda concetti di prestazione enon è un requisito della sicurezza.

v Il MAS rappresenta sempre il server “di convalida” per il dominio home (ildominio A in questo esempio).

v Un cookie e-community specifico di dominio viene utilizzato per identificare ilserver “di convalida” per tutti gli altri server all’interno di un determinatodominio. Il server “di convalida” è il primo server in un dominio che richiedeun token “di convalida” al MAS. Il server “di convalida” fornisce informazionidi “convalida” per l’utente all’interno del dominio. Le successive richieste diservizi di “convalida” in un determinato dominio remoto possono essere fattelocalmente da questo server anziché accedere al MAS esterno al dominio. Neldominio home, il cookie e-community identifica il MAS come server “diconvalida”.

(1) PRIMO accesso e-community: WebSEAL 1 (Dominio A)

v L’utente richiede una risorsa protetta da WebSEAL 1 (all’interno dello stessodominio del MAS). Il browser non contiene cookie e-community per questodominio. WebSEAL 1 non ha credenziali memorizzate nella cache per questoutente.

v La configurazione di WebSEAL 1 ha l’autenticazione e-community abilitata especifica l’ubicazione del MAS. WebSEAL 1 reindirizza il browser a uno specialeURL “di convalida” sul MAS.

v Il MAS riceve la richiesta “di convalida” e, non trovando credenziali per taleutente, richiede a quest’ultimo di effettuare il login.

v Dopo un corretto login, il MAS crea una credenziale per l’utente, la memorizzanella cache, e reindirizza nuovamente il browser all’URL richiesto in origine suWebSEAL 1, con un token “di convalida” crittografato. Inoltre, un cookie

Client

Dominio A Dominio B

mas.dA.com

ws1.dA.com

ws2.dA.com

WebSEAL MAS

ws3.dB.com

ws4.dB.com

WebSEAL 3

WebSEAL 4

WebSEAL 2

WebSEAL 1

Figura 28. Flusso di processo e-community


e-community specifico del dominio A, viene sistemato sul browser peridentificare il server “di convalida” per questo dominio (in questo caso, il MAS).Se il tentativo di login non riesce, il MAS restituisce un token “di convalida” cheindica uno stato di errore. Questo token è progettato per essere indistinguibiledal token “di convalida” di uno stato riuscito. Il server richiedente reagisce a untoken di stato di errore come se l’utente avesse fallito l’autenticazione locale.

v WebSEAL 1 decodifica il token e crea la propria credenziale per l’utente.

Nota: L’associazione di identità non dovrebbe essere richiesta all’interno dellostesso dominio. Se tale associazione è richiesta, WebSEAL 1 deveutilizzare il CDMF (Cross-domain Mapping Framework).

v Il servizio di autorizzazione permette o rifiuta la richiesta.

(2) PRIMO accesso e-Community: WebSEAL 3 (Dominio B)

v L’utente richiede una risorsa protetta da WebSEAL 3 (dominio remoto B). Ilbrowser non contiene cookie e-community per questo dominio. WebSEAL 3 nondispone di credenziali per l’utente nella cache.

v La configurazione di WebSEAL 3 ha l’autenticazione e-community abilitata especifica l’ubicazione del MAS. WebSEAL 3 reindirizza il browser a uno specialeURL “di convalida” sul MAS.

v Il MAS riceve la richiesta “di convalida” e, non trovando credenziali per taleutente, richiede a quest’ultimo di effettuare il login.

v Dopo un corretto login, il MAS crea una credenziale per l’utente, la memorizzanella cache, e reindirizza nuovamente il browser all’URL richiesto in origine suWebSEAL 3, con un token “di convalida” crittografato. Inoltre, un cookiee-community specifico del dominio A, viene sistemato sul browser peridentificare il server “di convalida” per questo dominio (in questo caso, il MAS).Se il tentativo di login non riesce, il MAS restituisce un token “di convalida” cheindica uno stato di errore. Questo token è progettato per essere indistinguibiledal token “di convalida” di uno stato riuscito. Il server richiedente reagisce a untoken di stato di errore come se l’utente avesse fallito l’autenticazione locale.

v WebSEAL 3 decodifica il token e crea la propria credenziale per l’utente.v WebSEAL 3 crea e imposta un secondo cookie e-community (valido per il

dominio B) sul browser, identificando WebSEAL 3 come server “di convalida”per il dominio B.


(3) SUCCESSIVO accesso e-community: WebSEAL 2 (Dominio A)

v L’utente richiede una risorsa protetta da WebSEAL 2 (all’interno dello stessodominio del MAS). Il browser contiene un cookie e-community del dominio Ache identifica il MAS come server “di convalida”. WebSEAL 2 riceve questocookie. WebSEAL 2 non ha credenziali memorizzate nella cache per questoutente.

v La configurazione di WebSEAL 2 ha l’autenticazione e-community abilitata especifica l’ubicazione del MAS. La presenza del cookie e-community deldominio A ricopre la configurazione di WebSEAL 2 per l’ubicazione del MAS. Ilcookie fornisce a WebSEAL 2 l’identità del server “di convalida”. (Se è avvenutoprima lo scenario 2, potrebbe anche esserci un cookie di dominio B mantenutosul browser che non viene inviato a un server di dominio A.)

v WebSEAL 2 reindirizza il browser verso un URL “di convalida” speciale sulserver “di convalida” del dominio A identificato nel cookie (in questo caso ilMAS, poiché WebSEAL 2 si trova nel dominio A).


v Il MAS riceve la richiesta “di convalida” e trova le credenziali per tale utentenella cache (questo si è verificato nello scenario 1 e 2).

v Il MAS reindirizza il browser all’URL richiesto in origine su WebSEAL 2, con untoken “di convalida” crittografato.

v WebSEAL 2 decodifica il token e crea la propria credenziale per l’utente.v Il servizio di autorizzazione permette o rifiuta la richiesta.

(4) SUCCESSIVO accesso e-community: WebSEAL 4 (Dominio B)

v L’utente richiede una risorsa protetta da WebSEAL 4 (dominio remoto B). Se èavvenuto prima lo scenario 2, il browser contiene un cookie e-community didominio B che identifica WebSEAL 3 come server “di convalida”. WebSEAL 4non dispone di credenziali per l’utente nella cache.

v La configurazione di WebSEAL 4 ha l’autenticazione e-community abilitata especifica l’ubicazione del MAS. La presenza di un cookie e-community deldominio B ricopre la configurazione di WebSEAL 4 per l’ubicazione del MAS. Ilcookie fornisce a WebSEAL 4 l’identità del server “di convalida”. (Se è avvenutoprima lo scenario 1, potrebbe esserci un cookie di dominio A mantenuto sulbrowser che non viene inviato a un server di dominio B. Invece, verrà utilizzatal’ubicazione del MAS configurata. WebSEAL 4 diventerebbe quindi il server “diconvalida” per il dominio B.)

v Se lo scenario 2 si è verificato prima, WebSEAL 4 reindirizza il browser a unURL “di convalida” speciale sul server “di convalida” del dominio B identificatonel cookie del dominio B (in questo caso WebSEAL 3).

v WebSEAL 3 riceve la richiesta “di convalida” e trova le credenziali per taleutente nella cache (questo si è verificato nello scenario 2).

v WebSEAL 3 reindirizza il browser all’URL richiesto in origine su WebSEAL 4,con un token “di convalida” crittografato.

v WebSEAL 4 decodifica il token e crea la propria credenziale per l’utente.v Il servizio di autorizzazione permette o rifiuta la richiesta.

(5) ALTRO accesso e-community: WebSEAL 2 (Dominio A)

v L’utente si collega a WebSEAL 2 (dominio A) con una richiesta. Se si è verificatolo scenario 3, WebSEAL 2 dispone nella cache di credenziali per l’utente.


Scollegamento dall’e-community

v Se l’utente si scollega chiudendo il browser, tutte le sessioni SSL e tutti i cookiee-community vengono eliminati.

v Se l’utente si scollega attraverso la pagina /pkmslogout, la sessione SSL e ilcookie e-community per tale dominio vengono eliminati.

Comprensione del cookie e-communityv Il cookie e-community è un cookie specifico di dominio impostato da un server

WebSEAL, archiviato nella memoria del browser dell’utente e trasmesso ad altriserver WebSEAL (nello stesso dominio) in successive richieste.

v Il cookie specifico di dominio contiene il nome del server “di convalida”,l’identità e-community, un’ubicazione (URL) del server “di convalida” e unvalore di durata. Il cookie non contiene informazioni sull’utente o sullasicurezza.


v Il cookie e-community consente ai server partecipanti a un dominio di richiederelocalmente informazioni di “convalida”. Il cookie e-community del dominio incui risiede il MAS gioca invece un ruolo meno significativo.

v Il cookie ha un valore di durata (timeout) impostato nel file di configurazionewebseald.conf. Questo valore specifica per quanto tempo un server remoto è ingrado di fornire informazioni di “convalida” per l’utente. Quando la durata delcookie scade, l’utente deve essere reindirizzato al MAS per effettuarel’autenticazione.

v Il cookie viene eliminato dalla memoria quando il browser viene chiuso. Sel’utente si scollega da un dominio specifico, il cookie e-community vienesovrascritto come se fosse vuoto. Questa azione ne provoca effettivamente larimozione dal browser.

Comprensione della richiesta e risposta “di convalida”L’operazione “di convalida” e-community richiede l’accesso a una funzionalitàdedicata attraverso due URL appositamente costruiti: la richiesta “di convalida” ela risposta “di convalida”. Questi URL vengono creati durante i reindirizzamentiHTTP “di convalida” e-community in base alle informazioni di configurazionepresenti in webseald.conf.

La richiesta “di convalida”

La richiesta “di convalida” viene attivata quando un utente richiede una risorsa adun server di destinazione (configurato per e-community) che non contiene alcunainformazione di credenziale per tale utente. Il server effettua un reindirizzamentoHTTP al server “di convalida” (il MAS oppure un server identificato in un cookiee-community).

La richiesta “di convalida” contiene le seguenti informazioni:https://<server-di-convalida>/pkmsvouchfor?<nome-ecommunity>&<URL-destinazione>

Il server ricevente controlla il nome-ecommunity per convalidare l’identitàe-community. Il server ricevente utilizza l’URL-destinazione nella risposta “diconvalida” per reindirizzare il browser alla pagina richiesta in origine.

L’URL pkmsvouchfor “di convalida” è configurabile.

Ad esempio:https://mas.dA.com/pkmsvouchfor?companyABC&https://ws5.dB.com/index.html

La risposta “di convalida”

La replica “di convalida” rappresenta la risposta dal server “di convalida” al serverdi destinazione.

La risposta “di convalida” contiene le seguenti informazioni:https://<URL-destinaz>?PD-VFHOST=<server-di-convalida>&PD-VF=<token-crittografato>

Il parametro PD-VFHOST identifica il server che ha eseguito l’operazione “diconvalida”. Il server ricevente (di destinazione) utilizza queste informazioni perselezionare la chiave corretta necessaria per decodificare il token “di convalida”(PD-VF). Il parametro PD-VF rappresenta il token “di convalida” crittografato.

Ad esempio:


https://w5.dB.com/index.html?PD-VFHOST=mas.dA.com&PD-VF=3qhe9fjkp...ge56wgb

Comprensione del token “di convalida”Per poter beneficiare del singolo collegamento su più domini (CDSSO -cross-domain single sign-on), alcune informazioni sull’identità dell’utente devonoessere trasmesse tra i vari server. Questi dati sensibili vengono gestiti utilizzandoun reindirizzamento che include le informazioni di identità crittografate comeparte dell’URL. Questi dati crittografati vengono chiamati token “di convalida”.v Il token contiene lo stato positivo o negativo “di convalida”, l’identità dell’utente

(se c’è stato esito positivo), il nome completo del server che ha creato il token,l’identità e-community e un valore sul momento della creazione.

v Il possessore di un valido token “di convalida” può utilizzare questo token perstabilire una sessione (e una serie di credenziali) con un server, senza doversiesplicitamente autenticare su tale server.

v Il token è crittografato mediante una chiave segreta triple-DES condivisa, inmodo che è possibile verificarne l’autenticità.

v Le informazioni del token crittografato non sono memorizzate sul browser.v Il token viene trasmesso una sola volta. Il server ricevente utilizza queste

informazioni per creare credenziali utente nella propria cache. Il server utilizzatali credenziali per future richieste fatte dall’utente durante la stessa sessione.

v Il token ha un valore di durata (timeout) che è impostato nel file diconfigurazione webseald.conf. Questo valore può essere molto breve (secondi)per ridurre il rischio di un attacco di ripetizione.

Codifica del token “di convalida”WebSEAL deve codificare i dati di autenticazione sistemati nel token utilizzandouna chiave generata dal programma di utilità cdsso_key_gen. E’ necessario“sincronizzare” questa chiave condividendo il file di chiavi con tutti i serverWebSEAL in ogni dominio partecipante. Ogni server WebSEAL partecipante inogni dominio deve utilizzare la stessa chiave.

Nota: La creazione e la distribuzione di file di chiavi non fa parte del processoe-community di Access Manager. E’ necessario copiare manualmente e inmodo sicuro le chiavi per ciascun server partecipante.

Il programma di utilità cdsso_key_gen richiede la specifica dell’ubicazione(percorso assoluto) del file di chiavi quando si esegue il programma di utilitàstesso:

UNIX:# cdsso_key_gen <percorso-assoluto>

Windows:MSDOS> cdsso_key_gen <percorso-assoluto>

L’ubicazione della chiave utilizzata per proteggere i token inviati tra serverall’interno dello stesso dominio (home e remoto) viene immessa come valore delparametro intra-domain-key nella stanza [e-community-sso] del file diconfigurazione webseald.conf.[e-community-sso]intra-domain-key = <percorso-assoluto>


L’ubicazione dei file di chiavi utilizzati per proteggere i token inviati tra il MAS e iserver in domini remoti viene immessa nella stanza [inter-domain-keys]. Altriserver nello stesso dominio di MAS non richiedono inter-domain-keys. Il MAS è ilsolo server che ha bisogno di comunicare con server in domini remoti.[inter-domain-keys]<nome-dominio> = <percorso-assoluto><nome-dominio> = <percorso-assoluto

Configurazione di una e-communityQuesta sezione rivede tutti i parametri di configurazione richiesti perun’implementazione e-community. Questi parametri si trovano nel file diconfigurazione webseald.conf. E’ necessario configurare con attenzione questo fileper ciascun server partecipante all’e-community.

e-community-sso-auth

Questo parametro abilita o disabilita l’autenticazione e-community. I valoricomprendono “http”, “https”, “both” o “none”. Ad esempio:[e-community-sso]e-community-sso-auth = both

I valori “http”, “https” e “both” specificano il tipo di comunicazione utilizzata daipartecipanti e-community. Il valore “none” disabilita la e-community per questoserver. L’impostazione predefinita è “none”.

master-http-port

Se e-community-sso-auth abilita l’autenticazione e-community HTTP e il server diautenticazione principale è in ascolto di richieste HTTP su una porta diversa dallaporta HTTP standard (porta 80), il parametro master-http-port identifica la portanon-standard. Questo parametro viene ignorato se il server corrisponde al server diautenticazione principale. Per impostazione predefinita, questo parametro èdisabilitato.[e-community-sso]master-http-port = <numero-porta>

master-https-port

Se e-community-sso-auth abilita l’autenticazione e-community HTTPS e il server diautenticazione principale è in ascolto di richieste HTTPS su una porta diversa dallaporta HTTP standard (porta 443), il parametro master-http-port identifica la portanon-standard. Questo parametro viene ignorato se il server corrisponde al server diautenticazione principale. Per impostazione predefinita, questo parametro èdisabilitato.[e-community-sso]master-https-port = <numero-porta>

e-community-name

Questo parametro identifica il nome di unificazione dell’e-community per tutti iserver partecipanti in tutti i domini partecipanti. Ad esempio:[e-community-sso]e-community-name = companyABC

Il valore e-community-name deve corrispondere per tutti i server WebSEAL in tuttii domini che partecipano all’e-community.


intra-domain-key

Questo parametro identifica l’ubicazione del file di chiavi utilizzato per codificare edecodificare i token scambiati all’interno del dominio di questo server. Adesempio:[e-community-sso]intra-domain-key = /abc/xyz/key.file

E’ necessario generare questo file di chiavi in una ubicazione e quindi copiarlomanualmente (e con attenzione) nella specifica ubicazione su titti gli altri serverWebSEAL del dominio.

is-master-authn-server

Questo parametro identifica se questo server rappresenta il MAS oppure no. Ivalori includono “yes” o “no”. Ad esempio:[e-community-sso]is-master-authn-server = yes

WebSEAL multipli possono essere configurati per agire come server diautenticazione principali (MAS) e, quindi, inseriti in un programma dibilanciamento del carico. In questo scenario, il programma di bilanciamento delcarico viene “riconosciuto” come MAS da tutti gli altri server WebSEALdell’e-community.

master-authn-server

Se il parametro is-master-authn-server è impostato su “no”, questo parametro deveessere decommentato e specificato. Il parametro identifica il nome di dominiocompleto del MAS (il server di autenticazione principale). Ad esempio:[e-community-sso]master-authn-server = mas.dA.com

vf-token-lifetime

Questo parametro imposta il valore di timeout di durata (in secondi) del token “diconvalida”. Questo valore viene confrontato con l’ora di creazione presente sulcookie. Il valore predefinito è di 180 secondi. E’ necessario tenere in conto qualsiasidifferenza oraria di account tra i domini partecipanti. Ad esempio:[e-community-sso]vf-token-lifetime = 180

vf-url

Questo parametro specifica l’URL “di convalida”. Il valore deve iniziare con unabarra (/). Il valore predefinito è /pkmsvouchfor. Ad esempio:[e-community-sso]vf-url = /pkmsvouchfor

E’ anche possibile esprimere un URL esteso:vf-url = /ecommA/pkmsvouchfor

ec-cookie-lifetime

Questo parametro specifica la durata massima (in minuti) del cookie e-communitydel dominio. Il valore predefinito è di 300 minuti. Ad esempio:


[e-community-sso]ec-cookie-lifetime = 300

Chiavi di inter-dominio

L’ubicazione dei file di chiavi necessari per codificare e decodificare i token inviatitra il MAS e i server partecipanti situati in domini remoti è specificata nella stanza[inter-domain-keys]. E’ necessario specificare nomi di dominio completi per iserver e nomi di percorso assoluti per le ubicazioni dei file di chiavi.

L’esempio seguente fornisce al MAS (dominio A) file di chiavi per lacomuinicazione con due domini remoti:[inter-domain-keys]dB.com = /abc/xyz/key.fileBdC.com = /abc/xyz/key.fileC

In questo esempio, key.fileB identifica il file di chiavi utilizzato tra il dominio A eil dominio B. key.fileC identifica il file di chiavi utilizzato tra il dominio A e ildominio C.

Ogni server remoto dovrebbe avere una copia del file di chiavi adatto utilizzato dalMAS. Per scambiare token con il MAS (dominio A), tutti i server del dominio Brichiedono copie di key.fileB.[inter-domain-keys]dA.com = /efg/hij/key.fileB

Per scambiare token con il MAS (dominio A), tutti i server del dominio Crichiedono copie di key.fileC.[inter-domain-keys]dA.com = /efg/hij/key.fileC

Configurazione del meccanismo di autenticazione CDSSOLa configurazione e-community richiede che venga abilitato il meccanismo diautenticazione cdsso. Questo meccanismo è necessario quando il server richiedentecrea credenziali utente dalle informazioni di identità contenute nel token “diconvalida”. Il parametro di configurazione cdsso specifica la libreria condivisacodificata per l’associazione delle informazioni di autenticazione.v Su UNIX, il file che fornisce la funzione di associazione incorporata è una

libreria condivisa denominata libcdssoauthn.v Su Windows, il file che fornisce la funzione di associazione incorporata è una

DLL denominata cdssoauthn.


Libreria condivisa


cdsso libcdssoauthn.so libcdssoauthn.a cdssoauthn.dll libcdssoauthn.sl

E’ possibile configurare il meccanismo di autenticazione CDSSO immettendo ilparametro cdsso con il nome, specifico per piattaforma, del file di libreriacondivisa nella stanza [authentication-mechanism] del file di configurazionewebseald.conf.

Ad esempio:

Solaris:


[authentication-mechanisms]cdsso = libcdssoauthn.so

Windows:[authentication-mechanisms]cdsso = cdssoauthn.dll


Capitolo 7. Junction WebSEAL

La connessione tra un server WebSEAL e il server di applicazioni back-end Web èconosciuta come junction WebSEAL, oppure junction. Un junction WebSEAL è unaconnessione TCP/IP tra un server WebSEAL front-end e un server di applicazioniWeb back-end. I junction consentono a WebSEAL di proteggere le risorse Webubicate su server back-end.

E’ possibile creare junction WebSEAL con il programma di utilità di riga comandipdadmin oppure mediante il gestore di portale Web. Questo capitolo tratta indettaglio le molte opzioni per la configurazione di junction WebSEAL.

Indice degli argomenti:v “Panoramica sui junction WebSEAL” a pagina 153v “Utilizzo di pdadmin per creare junction” a pagina 155v “Configurazione di un junction WebSEAL base” a pagina 156v “Junction SSL autenticati reciprocamente” a pagina 158v “Creazione di junction proxy TCP e SSL” a pagina 161v “Junction WebSEAL-WebSEAL su SSL” a pagina 162v “Modifica di URL a risorse di back-end” a pagina 162v “Opzioni di junction supplementari” a pagina 169v “Note tecniche per l’utilizzo di junction WebSEAL” a pagina 178v “Utilizzo di query_contents con server di terzi” a pagina 179

Panoramica sui junction WebSEALE’ possibile creare i seguenti tipi di junction WebSEAL:v WebSEAL-server back-end su connessione TCPv WebSEAL-server back-end su connessione SSLv WebSEAL-server back-end su connessione TCP via server proxy HTTPv WebSEAL-server back-end su connessione SSL via server proxy HTTPSv WebSEAL-WebSEAL su connessione SSL

Quando si decide di creare un junction, considerare i due seguenti concetti:1. Decidere dove effettuare il junction (montaggio) del server di applicazioni Web

nello spazio oggetti WebSEAL.2. Scegliere il tipo di junction.

Ubicazione e formato del database di junctionLe informazioni sui junction WebSEAL sono ora memorizzate in file di databaseformato XML. L’ubicazione della directory del database di junction è definita nellastanza [junction] del file di configurazione webseald.conf. La directory è correlataalla root del server WebSEAL (parametro server-root nella stanza [server]):[junction]junction-db = jct

v Ciascun junction è definito in un file separato con un’estensione .xml.


v Utilizzare il programma di utilità pdadmin per creare e gestire junction eopzioni.

v Il formato XML consente manualmente di creare, modificare, duplicare edeffettuare il backup di file di junction.

Applicazione del controllo accesso superficiale: riepilogo1. Utilizzare il programma di utilità pdadmin o il gestore di portale Web per

creare un junction tra WebSEAL e il server back-end.2. Inserire un criterio ACL appropriato sul punto di junction per fornire un

controllo non approfondito al server back-end.

Applicazione del controllo accesso raffinato: riepilogo1. Utilizzare il programma di utilità pdadmin o il gestore di portale Web per

creare un junction tra WebSEAL e il server back-end.WebSEAL non è in grado di “vedere” e comprendere automaticamente un filesystem di terzi. E’ necessario informare WebSEAL dello spazio oggetti di terziutilizzando una speciale applicazione, denominata query_contents, che effettual’inventario dello spazio Web di terzi e ne riporta la struttura e il contenuto aWebSEAL.

2. Copiare il programma query_contents nel server di terzi.3. Applicare il criterio ACL ad oggetti appropriati nello spazio oggetti unificato.

Indicazioni per la creazione di junction WebSEALLe seguenti indicazioni riassumono le “regole” relative ai junction:v E’ possibile aggiungere un junction in qualsiasi punto dello spazio oggetti

WebSEAL primariov E’ possibile effettuare il junction di più server back-end di replica nello stesso

punto di montaggioI server back-end di replica multipli montati sullo stesso punto di junctiondevono essere dello stesso tipo, TCP o SSL

v I criteri ACL vengono ereditati su junction verso server di terziv Il nome del punto di junction deve essere univoco e non corrispondere ad

alcuna directory dello spazio Web del server WebSEAL locale. Ad esempio, seWebSEAL dispone di risorse del formato /path/..., non creare un punto dijunction con il nome /path.

v Il punto di junction non dovrebbe corrispondere ad alcuna directory dello spazioWeb del server back-end se le pagine HTML provenienti da tale servercontengono programmi (come Javascript o applet) con URL relativi al server pertale directory. Ad esempio, se le pagine del server back-end contengonoprogrammi con un URL del formato /path/..., non creare un punto di junctioncon il nome /path.

v Non creare junction WebSEAL multipli che puntano allo stesso server o allastessa porta dell’applicazione back-end. Questo tipo di configurazione puòprovocare un imprevedibile controllo dell’accesso alle risorse e, quindi, nonrappresenta una strategia di configurazione di Access Manager consigliata osupportata.Ogni junction WebSEAL deve essere protetto mediante un insieme univoco diACL. Tuttavia, il criterio ACL di ogni nuovo junction creato ricopre i criteri deijunction creati in precedenza e collegati allo stesso server o alla stessa porta diback-end. Successivi junction protetti con ACL più permissivi possonocompromettere precedenti junction protetti con ACL meno permissivi. WebSEAL


e il modello di autorizzazione Access Manager non possono garantire uncontrollo dell’accesso protetto con questo tipo di implementazione di junction.

v WebSEAL supporta HTTP 1.1 sui junction.

Ulteriori riferimenti per i junction WebSEALPer una panoramica dei concetti sui junction WebSEAL, fare riferimento a“Comprensione dei junction WebSEAL” a pagina 13.

Per informazioni complete sulle opzioni dei comandi di junction, fare riferimento aAppendice B, “Riferimento junction WebSEAL” a pagina 237.

Utilizzo di pdadmin per creare junctionPrima di utilizzare pdadmin, è necessario collegarsi a un dominio protetto comeutente responsabile sec_master.

Ad esempio:

UNIX:# pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>

Windows:MSDOS> pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>

Per creare junction WebSEAL, viene utilizzato il comando pdadmin server taskcreate:pdadmin> server task <ID-server> create <opzioni>

Il componente ID-server di questo comando rappresenta una combinazione delserver Access Manager utilizzato da tale comando e del nome host del serverAccess Manager.<server-Access-Manager>-<nome-host>

Sintassi per un singolo server WebSEAL:

Per Access Manager WebSEAL, Access-Manager-server è webseald e il nome-hostcorrisponde al nome della macchina server WebSEAL:pdadmin> server task webseald-<nome-host> create <opzioni>

Il server WebSEAL iniziale installato su una macchina è sempre citato dopo ilnome della macchina. Ad esempio, se il nome della macchina è cruz,l’identificazione del server per una singola installazione di WebSEAL è:webseald-cruz

Sintassi per istanze multiple di WebSEAL:

Capitolo 7. Junction WebSEAL 155

Se si installano istanze multiple del server WebSEAL sulla stessa macchina,Access-Manager-server rappresenta il nome configurato dell’istanza del serverWebSEAL, seguito da webseald, seguito a sua volta dal nome host:<nome-istanza>-webseald-<nome-host>

Ad esempio, se i nomi configurati per due istanze supplementari di WebSEALsono webseal2 e webseal3, le identificazioni del server saranno:webseal2-webseald-cruzwebseal3-webseald-cruz

Utilizzare il comando server list per verificare l’identificazione del server:pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Configurazione di un junction WebSEAL baseWebSEAL supporta junction TCP standard (HTTP) e SSL protetti (HTTPS) traWebSEAL e server di applicazioni back-end Web.

Il junction tra WebSEAL e il server back-end è indipendente dal tipo diconnessione (e dal relativo livello di protezione) tra il client e il server WebSEAL.

Le opzioni di comando obbligatorie necessarie per creare un junction WebSEAL dibase utilizzando pdadmin comprendono:v Il nome host del server di applicazione back-end (opzione –h)v Tipo di junction: tcp, ssl, tcpproxy, sslproxy, locale (opzione –t)v Il punto di junction (punto di montaggio)pdadmin> server task webseald-<nome-istanza> create –t <tipo> –h \<nome-host> <punto-jct>

Ad esempio:pdadmin> server task webseald-cruz create -t tcp -h doc.tivoli.com /pubs

Nota: Un consiglio per il “miglior utilizzo” è di utilizzare sempre il nome didominio completo del server back-end quando si specifica l’argomento perl’opzione –h.

Creazione di junction di tipo TCPUn junction WebSEAL su una connessione TCP fornisce le proprietà di base di unjunction ma non fornisce comunicazioni protette sul junction.


Per creare un junction TCP protetto e aggiungere un server iniziale, utilizzare ilcomando create con l’opzione –t tcp:pdadmin> server task webseald-<nome-istanza> create –t tcp –h <nome-host> \[–p <porta>] <punto-jct>

Il valore di porta predefinito per un junction TCP (se non specificato) è 80.

Creazione di junction di tipo SSLI junction SSL funzionano esattamente come i junction TCP, con il valore aggiuntoche tutte le comunicazioni tra WebSEAL e il server back-end sono crittografate.

I junction SSL consentono transazioni protette end-to-end browser-applicazione; èpossibile utilizzare SSL per proteggere comunicazioni dal client a WebSEAL e daWebSEAL al server back-end. IL server back-end deve essere abilitato HTTPSquando si utilizza un junction SSL.

Per creare un junction SSL protetto e aggiungere un server iniziale, utilizzare ilcomando create con l’opzione –t ssl:pdadmin> server task webseald-<nome-istanza> create –t ssl –h <nome-host> \[–p <porta>] <punto-jct>

Il valore di porta predefinito per un junction SSL (se non specificato) è 443.

Verifica del certificato del server back-endQuando un client effettua una richiesta di una risorsa sul server back-end,WebSEAL, nel suo ruolo di server di sicurezza, esegue la richiesta da parte del

NodoWebSEAL

Client

Dominio protetto

Webapplicazioni

Server delleHTTP

/

/mnt

TCP

Figura 29. Junction TCP non protetto (HTTP)

NodoWebSEAL

Client

Dominio protetto

WebapplicazioniServer delle

HTTPS

/

/mntSSLTCP

Figura 30. Junction SSL protetto (HTTPS)


client. Il protocollo SSL specifica che quando viene effettuata una richiesta al serverback-end, tale server deve fornire prova della propria identità attraverso ilcertificato del server.

Quando WebSEAL riceve questo certificato dal server back-end, deve verificarnel’autenticità confrontando il certificato con un elenco di certificati CA principalimemorizzati nel proprio database dei certificati.

Access Manager utilizza l’implementazione IBM Global Security Kit (GSKit) di SSL.E’ necessario utilizzare il programma di utilità GSKit iKeyman per aggiungere ilcertificato principale della CA che ha convalidato il certificato del server back-endnel file di chiavi dei certificati di WebSEAL (pdsvr.kdb).

Esempi di junction SSLHost junction sales.tivoli.com sul punto di junction /sales su SSL:pdadmin> server task webseald-<nome-istanza> create –t ssl –h \sales.tivoli.com /sales

Nota: Nell’esempio precedente, l’opzione –t ssl impone la porta predefinita 443.

Host junction travel_svr sulla porta 4443 sul punto di junction /travel su SSL:pdadmin> server task webseald-<nome-istanza> create –t ssl –p 4443 \–h travel_svr /travel

Aggiunta di server back-end supplementari a un junctionPer aumentare l’elevata disponibilità delle risorse protette da Access Manager, èpossibile congiungere più server back-end di replica allo stesso punto di junction.v Server back-end multipli uniti sullo stesso punto devono avere versioni di

WebSEAL identiche e spazi di documenti Web identici.v Server back-end multipli uniti sullo stesso punto devono utilizzare lo stesso tipo

di connessione (TCP o SSL).v WebSEAL utilizza un algoritmo di minimo impegno per determinare quale

server back-end di replica ha il minor numero di connessioni di richieste einoltra qualsiasi nuova richiesta a tale server.

Creare il junction iniziale. Ad esempio:pdadmin> server task webseald-cruz create -t tcp -h server1 /sales

Aggiungere un server back-end di replica supplementare. Ad esempio:pdadmin> server task webseald-cruz add -h server2 /sales

Junction SSL autenticati reciprocamenteWebSEAL supporta l’autenticazione reciproca tra un server WebSEAL e un serverback-end su un junction SSL (–t ssl o –t sslproxy). Di seguito viene riepilogata lafunzione supportata per l’autenticazione reciproca su SSL (le opzioni di comandosono elencate dove necessario):1. WebSEAL autentica il server back-end (processo SSL normale)v WebSEAL convalida il certificato del server dal server back-end. Vedere

“WebSEAL convalida il certificato del server di back-end” a pagina 159.v WebSEAL verifica il Distinguished Name (DN) contenuto nel certificato (–D)

(facoltativo, ma fortemente consigliato). Vedere “Corrispondenza DN(Distinguished name)” a pagina 159.

2. Il server back-end autentica WebSEAL (due metodi)


v Il server back-end convalida il certificato client da WebSEAL (–K). Vedere“WebSEAL effettua l’autenticazione con il certificato del client”.

v Il server back-end convalida le informazioni sull’identità di WebSEALnell’intestazione BA Basic Authentication) (–B, –U, –W). Vedere “WebSEALeffettua l’autenticazione con l’intestazione BA” a pagina 160.

Le opzioni di comando che controllano l’autenticazione reciproca su SSL fornisconole seguenti funzioni:v E’ possibile specificare il metodo di autenticazione del certificato client o BA.v E’ possibile applicare il metodo di autenticazione su base per-junction.

Considerazioni speciali sulla combinazione delle opzioni –b (per gestireinformazioni BA) con l’autenticazione reciproca su SSL sono riportate in “Gestionedei dati sull’identità del client attraverso junction” a pagina 160

WebSEAL convalida il certificato del server di back-endWebSEAL verifica un certificato del server back-end in accordo al protocollo SSLstandard. Il server di back-end invia il proprio certificato del server a WebSEAL.WebSEAL convalida il certificato del server confrontandolo con un elencopredefinito di certificati CA (Certificate Authority) principali.

I certificati dell’Autorità di certificazione (CA) che formano la catena di fiducia peril certificato del server applicativo (dalla CA firmataria fino al certificato principaleincluso) devono essere inclusi nel database di chiavi in uso su WebSEAL.

Il programma di utilità iKeyman viene utilizzato per creare e gestire il databasedei certificati di CA principali.

Corrispondenza DN (Distinguished name)E’ possibile migliorare la verifica dei certificati del server attraverso lacorrispondenza DN (Distinguished Name). Per abilitare la corrispondenza DN delserver, è necessario specificare il DN del server back-end quando si crea il junctionSSL a tale server. Sebbene la corrispondenza DN sia una configurazione opzionale,si raccomanda di implementare questa funzione con l’autenticazione reciproca suijunction SSL.

Durante la verifica dei certificati del server, il DN contenuto nel certificato vieneconfrontato con il DN definito dal junction. La connessione al server back-end nonriesce se i due DN non corrispondono.

Per abilitare la corrispondenza DN del server, specificare il DN del server back-endquando si crea il junction SSL utilizzando l’opzione –D “<DN>”. Per conservare glispazi interni, racchiudere la stringa DN tra virgolette. Ad esempio:–D “/C=US/O=Tivoli/OU=SecureWay/CN=Access Manager”

L’opzione –D è adatta solo quando viene utilizzata con l’opzione –K o –B.

WebSEAL effettua l’autenticazione con il certificato del clientUtilizzare l’opzione –K per abilitare l’autenticazione WebSEAL sul server back-enddi junction attraverso il certificato del client.–K “<key-label>”

Le condizioni per questo scenario comprendono:


v Il server back-end viene impostato per richiedere la verifica dell’identità diWebSEAL mediante un certificato client.

v WebSEAL viene configurato (webseald.conf) per l’utilizzo di uno specificocertificato client per l’autenticazione con il server back-end (ssl-keyfile-label).

v E’ fortemente consigliata la configurazione del junction per la corrispondenzaDN (–D).

L’opzione –K utilizza un argomento che specifica l’etichetta-chiave del certificatorichiesto come memorizzata nel database di chiavi GSKit. Utilizzare il programmadi utilità iKeyman per aggiungere nuovi certificati al database di chiavi. Utilizzareil parametro ssl-keyfile-label del file di configurazione webseald.conf perconfigurare l’etichetta-chiave.

E’ necessario apporre gli apici intorno all’argomento etichetta-chiave. Ad esempio:–K “cert1_Tiv”

Consultare “Configurazione dei parametri del database di chiavi” a pagina 37.

WebSEAL effettua l’autenticazione con l’intestazione BAUtilizzare l’opzione –B –U “<nomeutente>” –W “<password>” per abilitarel’autenticazione WebSEAL attraverso BA (Basic Authentication).–B –U “<nomeutente>” –W “<password>”

Le condizioni per questo scenario comprendono:v Il server back-end viene impostato per richiedere la verifica dell’identità di

WebSEAL mediante un’intestazione BA.v Non configurare il junction con alcuna opzione –b. (Internamente, tuttavia,

l’opzione –B utilizza –b filter.)v WebSEAL viene configurato per trasmettere le proprie informazioni di identità

in un’intestazione BA per l’autenticazione presso il server back-end.v Si raccomanda anche di configurare il junction per la corrispondenza DN (–D).

E’ necessario apporre le virgolette intorno agli argomenti nome utente e password.Ad esempio:–U “WS1” –W “abCde”

Gestione dei dati sull’identità del client attraverso junctionUn junction può essere impostato per specificare informazioni sull’identità delclient in intestazioni BA. L’opzione –b consente quattro possibili argomenti: filter,supply, ignore, gso. Informazioni dettagliate su questi argomenti sono reperibili in“Configurazione di intestazioni BA per soluzioni single sign-on” a pagina 185.

L’opzione –b ha un impatto sulle impostazioni junction per l’autenticazionereciproca e quindi è necessario considerare una corretta combinazione delleopzioni.

Utilizzo dell’opzione –bv L’autenticazione WebSEAL attraverso l’intestazione BA non è consentita con

questa opzione. Questa opzione utilizza l’intestazione BA per il nome dell’utenteclient originale e una password “fittizia”.

v L’autenticazione WebSEAL attraverso il certificato client è consentita con questaopzione.


Utilizzo dell’opzione –b ignorev L’autenticazione WebSEAL attraverso l’intestazione BA non è consentita con

questa opzione. Questa opzione utilizza l’intestazione BA per il nome e lapassword dell’utente client originale.


Utilizzo dell’opzione –b gsov L’autenticazione WebSEAL attraverso l’intestazione BA non è consentita con

questa opzione. Questa opzione utilizza l’intestazione BA per le informazioni sunome utente e password fornite dal server GSO.


Utilizzo dell’opzione –b filterv Internamente, l’opzione –b filter viene utilizzata quando l’autenticazione

WebSEAL è impostata per l’utilizzo di informazioni di intestazione BA.L’intestazione BA di WebSEAL è utilizzata per tutte le successive transazioniHTTP. Al server back-end, WebSEAL appare come collegato in ogni momento.


v Se il server back-end richiede un’effettiva identità client (dal browser), èpossibile utilizzare le variabili CGI HTTP_IV_USER, HTTP_IV_GROUP eHTTP_IV_CREDS. Per script e servlet, utilizzare le corrispondenti intestazioniHTTP specifiche di Access Manager: iv-user, iv-groups, iv-creds.

Creazione di junction proxy TCP e SSLE’ possibile creare junction WebSEAL che consentono la comunicazione tratopologie di reti trasversali che utilizzano server proxy HTTP o HTTPS. E’possibile configurare il junction per la gestione di richieste sotto forma dicomunicazioni TCP standard o di comunicazioni SSL protette.

Il comando create richiede uno dei seguenti argomenti sull’opzione type perstabilire un junction su base TCP o su base SSL attraverso un server proxy:v –t tcpproxy

v –t sslproxy

Entrambi i comandi create e add richiedono le seguenti opzioni e i seguentiargomenti per identitificare il server proxy e il server Web di destinazione:

–H <nome-host> Il nome host DNS o l’indirizzo IP del server proxy.

–P <porta> La porta TCP del server proxy.

–h <nome-host> Il nome host DNS o l’indirizzo IP del server Web didestinazione.

–p <porta> La porta TCP del server Web di destinazione. Il valorepredefinito è 80 per junction TCP; 443 per junction SSL.

Esempio di junction proxy TCP (immesso su una riga):pdadmin> server task webseald-<nome-istanza> create –t tcpproxy \–H clipper –P 8081 –h www.ibm.com –p 80 /ibm


Esempio di junction proxy SSL (immesso su una riga):pdadmin> server task webseald-<nome-istanza> create –t sslproxy \–H clipper –P 8081 –h www.ibm.com –p 443 /ibm

Junction WebSEAL-WebSEAL su SSLAccess Manager supporta junction SSL tra un server front-end e un serverWebSEAL back-end. Utilizzare l’opzione –C con il comando create per congiungerei due server WebSEAL su SSL e fornire l’autenticazione reciproca.

Esempio:pdadmin> server task webseald-<nome-istanza> create –t ssl –C –h serverA /jctA

L’autenticazione reciproca avviene in due fasi:v Il protocollo SSL consente al server WebSEAL back-end l’autenticazione presso il

server WebSEAL front-end attraverso il proprio certificato server.v L’opzione –C abilita il server WebSEAL front-end a trasmettere le proprie

informazioni di identità al server WebSEAL back-end in un’intestazione BA(Basic Authentication).

In aggiunta, l’opzione –C abilita la funzionalità dell’opzione –c che consenteall’utente di inserire informazioni su identità del cliente e appartenenza a gruppispecifiche di Access Manager nell’intestazione HTTP della richiesta destinata alserver WebSEAL back-end. I parametri di intestazione includono iv-user, iv-groupse iv-creds. Consultare “Per fornire l’identità client nelle intestazioni HTTP (–c)” apagina 170.

Le seguenti condizioni si applicano ai junction WebSEAL-WebSEAL:v Il junction è adatto solo con il tipo junction –t ssl o –t sslproxy.v Entrambi i server WebSEAL devono condividere un registro LDAP o DCE

comune. Ciò consente al server WebSEAL back-end di autenticare leinformazioni di identità del server WebSEAL front-end.

Modifica di URL a risorse di back-endLe pagine restituite al client dalle applicazioni back-end molto spesso contengonocollegamenti URL a risorse ubicate su tali server di applicazione. E’ importante chetali collegamenti siano costruiti per reindirizzare qualsiasi richiesta alle ubicazionicorrette di queste risorse.

Client WebSEAL WebServer

www.ibm.com

Dominio protetto

-H e -P

Serverproxy

Clipper Internet

-h e -pnodo a /ibm

Figura 31. Esempio di junction proxy


Ad esempio, (per ambienti non-WebSEAL), l’URL immesso da un client per unarisorsa su un server di applicazioni potrebbe apparire come riportato di seguito:http://www.abc.com/file.html

WebSEAL, come proxy front-end inverso, fornisce servizi di protezione ai server diapllicazione back-end attraverso la funzione di junction WebSEAL. Questa funzionedetermina l’accesso delle risorse attraverso differenti espressioni URL.

Ad esempio, (per ambienti WebSEAL), l’URL immesso da un client per la stessarisorsa su un server di applicazione back-end di junction deve apparire comeriportato di seguito:http://webseal.abc.com/jct/file.html

La funzione di junction di WebSEAL modifica le informazioni del server e delpercorso che devono essere utilizzate per accedere alle risorse su sistemi back-enddi junction. Un collegamento a una risorsa su un server back-end di junctionavviene solo se l’URL contiene l’identità del junction.

Per supportare la funzione di junction e mantenere l’integrità degli URL, WebSEALdeve, dove possibile:1. Modificare gli URL (collegamenti) trovati nelle risposte inviate ai client2. Modificare le richieste per risorse risultanti da URL (collegamenti) che

WebSEAL non può modificare

Notare che i meccanismi e le regole di WebSEAL per il filtro e l’elaborazione diURL non si applicano a collegamenti che puntano a risorse esterne all’ambiente dijunction di Access Manager.

Il seguente diagramma riepiloga le soluzioni disponibili per WebSEAL per lamodifica di URL a risorse back-end di junction:

In questa sezione sono contenuti i seguenti argomenti:v “Comprensione dei tipi di percorso utilizzati in URL” a pagina 164v “Filtro degli URL nelle risposte” a pagina 164v “Elaborazione di URL nelle richieste” a pagina 167

Client WebSEAL

Web

applicazioniServer

nodo

Filtro delle rispostedai server di back-end

Elaborazione delle richiesteper le risorse di back-end

1. cookie nodo

2. tabella corrispondenza nodo(per URL relativi al server)

(per URL relativi al server)

1. filtro standard

2. filtro script(per URL assoluti e relativi al server)

(per URL assoluti)

Figura 32. Riepilogo: Modifica di URL a risorse di back-end


Comprensione dei tipi di percorso utilizzati in URLTutte le pagine HTML possono probabilmente contenere URL (collegamenti) adaltre risorse sul server back-end o da altre parti. Le espressioni URL possonoapparire in tre formati:v correlatov correlato al serverv assoluto

URL espressi in formato correlato non richiedono mai alcuna manipolazione daparte di WebSEAL. Per impostazione predefinita, il browser gestisce URL correlatiaggiungendo le corrette informazioni su schema, server e directory (incluso iljunction) all’URL correlato. Le informazioni aggiunte provengono dalla paginaesistente sulla quale risiede il collegamento.

Esempio di espressioni di URL correlati:abc.html ../abc.html./abc.html sales/abc.html

Tuttavia, si presentano difficoltà con i formati di percorso correlati al server eassoluti. I collegamenti alle risorse di back-end espressi in formati assoluti ocorrelati al server avvengono solo se WebSEAL è stato in grado di modificarel’espressione del percorso URL e includere le informazioni di junction.

Esempio di espressioni di URL correlati al server:/abc.html /accounts/abc.html

Esempio di espressioni di URL assoluti:http://www.tivoli.com/abc.html

Nota: Tutti i programmatori di script Web vengono incoraggiati ad utilizzarecollegamenti correlati (e non assoluti o correlati al server) per gli URLgenerati in modo dinamico.

Filtro degli URL nelle risposteQuesta sezione descrive il modo in cui WebSEAL filtra gli URL presenti nellerisposte provenienti da server di applicazione back-end di junction.v “Regole di filtro URL standard per WebSEAL” a pagina 164v “Modifica di URL assoluti con funzione di filtro script” a pagina 165v “La funzione di filtro modifica l’intestazione Content-Length” a pagina 166

Regole di filtro URL standard per WebSEALWebSEAL utilizza una serie di regole standard per filtrare gli URL contenuti nellepagine che rappresentano risposte a richieste del client. Per applicare la funzionedi filtro URL standard, WebSEAL deve essere in grado di “vedere” gli URL sullapagina inviata dal server back-end. WebSEAL non può utilizzare regole di filtrostandard per gli URL incorporati in script.

Per impostazione predefinita, WebSEAL filtra solo i documenti di tipo MIME“text/html” e “text/vnd.wap.wml” che provengono da server di junction. Altri tipiMIME possono essere configurati utilizzando la stanza [filter-content-types] delfile di configurazione webseald.conf.


Gli URL correlati vengono sempre gestiti in modo appropriato dal browser.Tuttavia, WebSEAL deve aggiungere il nome di junction al percorso degli URLassoluti e correlati al server che fanno riferimento alle risorse ubicate su server dijunction.v Gli URL correlati al server indicano una posizione URL in relazione alla root dei

documenti del server di junction, ad esempio:/dir/file.html

Questi URL vengono modificati per riflettere il punto di junction del server dijunction, ad esempio:/jct/dir/file.html

v Gli URL assoluti indicano una posizione URL in relazione a un nome host oindirizzo IP, e una porta di rete, ad esempio:http://<nome-host>[:<porta>]/file.html, oppurehttps://<nome-host>[:<porta>]/file.html

Questi URL vengono modificati in base alla seguente serie di regole:1. Se l’URL è HTTP e l’host/la porta corrisponde a un server TCP di junction,

l’URL viene modificato in modo da essere correlato al server per WebSEAL eriflettere così il punto di junction. Ad esempio:http://<nome-host>[:<porta>]/file.html

diventa:/tcpjct/file.html

2. Se l’URL è HTTPS e l’host/la porta corrisponde an un server SSL di junction,l’URL viene modificato in modo da essere correlato al server per WebSEAL eriflettere così il punto di junction. Ad esempio:https://<nome-host>[:<porta>]/file.html

diventa:/ssljct/file.html

3. Solo gli URL nei tipi di contenuto definiti nella stanza [filter-content-types] delfile di configurazione webseald.conf vengono sottoposti al filtro.

4. Le tag META vengono sempre filtrate per aggiornare le richieste, ad esempio:<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://server/url”>

5. Se una tag BASE contiene un attributo HREF, la tag viene rimossa dallarisposta inviata al client.

I parametri per il filtro di URL attraverso server di junction si trovano nella stanza[filter-url] del file di configurazione webseald.conf. La stanza [filter-url] contieneun elenco di tag HTML che il server WebSEAL filtra o modifica per regolare gliURL assoluti ottenuti attraverso un server di junction.

Tutte le tag HTML comunemente utilizzate sono configurate per impostazionepredefinita. Il responsabile può aggiungere ulteriori tag HTML contenenti URL.

Modifica di URL assoluti con funzione di filtro scriptWebSEAL richiede una configurazione supplementare per gestire l’elaborazione diURL assoluti incorporati in script. I linguaggi script Web comprendono Javascripts,VBscripts, ASP, JSP, ActiveX e altri. Il file di configurazione webseald.conf contieneun parametro che abilita o disabilita la funzione di filtro di URL assolutiincorporati:


[script-filtering]script-filter = no

Per impostazione predefinita, il parametro script-filtering è disabilitato. Perabilitare il filtro di script, impostare:script-filter = yes

Nota: E’ anche necessario utilizzare l’opzione –j per creare il junction al serverback-end.

Il meccanismo script-filter prevede URL assoluti con uno schema, un server e unformato risorsa standard:http://server/risorsa

Il meccanismo script-filter sostituisce le parti schema e server del collegamento conle corrette informazioni sul junction./nome-junction/risorsa

Questa soluzione analizza lo script incorporato nella codifica HTML e, per questo,richiede un’incremento di elaborazione che può influenzare negativamente leprestazioni. Limitare l’utilizzo del parametro script-filter ai junction che richiedonoil supporto per il filtro di URL assoluti incorporati.

Il seguente diagramma illustra questa soluzione di filtro URL:

La funzione di filtro modifica l’intestazione Content-LengthGeneralmente, l’intestazione Content-Length in una risposta proveniente da unserver back-end indica la dimensione del contenuto che sta per essere restituito.Quando WebSEAL filtra URL e aggiunge informazioni di junction al percorso degliURL contenuti nella pagina, la dimensione effettiva della pagina diventa maggioredi quanto indicato in Content-Header.

WebSEAL non ha modo per conoscere la nuova lunghezza del contenuto fino aquando non scrive effettivamente il flusso nel client. A questo punto, è troppo tardiper inserire una nuova intestazione Content-Length. WebSEAL risponde a questasituazione nel modo seguente:1. WebSEAL inserisce il valore dell’intestazione Content-Length originale in una

nuova intestazione denominata X-Old-Content-Length.Ogni applet o applicazione scritta per far riferimento a questa intestazione puòavere accesso al valore originale (pre-filtro) di Content-Length.

Client

WebSEAL

Serverdelle applicazioni

(Javascript )serves

Script contenentel’URL assoluto:

http://server/abc.html

Il client riceve:/jctA/abc.html

Richiesta Richiesta

Il client invia la richiestamediante il collegamento:

/jctA/abc.html

abc.htmlindividuato correttamente

filtro dello script=sìWebSEAL riformatta il collegamento a:

/jctA/abc.html

1

2

3

/jctAcon l’opzione -j

Figura 33. Filtro di URL assoluti


2. WebSEAL registra il valore modificato (post-filtro) di Content-Length nel filerequest.log.

3. L’intestazione Content-Length non appare più.

Elaborazione di URL nelle richiesteUna difficoltà si presenta quando gli URL vengono dinamicamente generati daapplicazioni client (applet) o incorporati in script nella codifica HTML. I linguaggiscript Web comprendono Javascripts, VBscripts, ASP, JSP, ActiveX e altri. Questiapplet e script vengono eseguiti una volta che la pagina è arrivata al browser delclient. WebSEAL non ha mai la possibilità di applicare le proprie regole di filtrostandard a tali URL generati in modo dinamico.

Questa sezione descrive il modo in cui WebSEAL elabora collegamenti clientcorrelati al server generati dinamicamente e trovati in richieste di risorse su serverback-end di junction.v “Gestione di URL correlati al server con cookie junction (-j)” a pagina 167v “Gestione di URL correlati al server mediante associazione di junction” a pagina

168

Nota: Non esiste alcuna soluzione disponibile per la gestione di URL assolutigenerati sul client.

Gestione di URL correlati al server con cookie junction (-j)Gli URL correlati al server generati sul client da applet e script inizialmenteperdono la conoscenza del punto di junction. WebSEAL non può filtrare l’URLperché questo è generato sul client. Durante una richiesta di risorsa effettuata dalclient mediante questo URL, WebSEAL può provare a rielaborare l’URL correlato alserver utilizzando i cookie del junction.

Nel seguente scenario, uno script ubicato sulla pagina richiesta generadinamicamente un’espressione di URL correlato al server all’arrivo sul browser. Seil client richiede la risorsa specificata da questo collegamento, WebSEAL riceve unarichiesta per una pagina locale. Dopo aver fallito il rilevamento della pagina,restituisce un errore “Pagina non trovata” al client.

L’opzione –j fornisce una soluzione basata su cookie per la gestione di URLcorrelati al server che vengono dinamicamente generati da uno script in esecuzionesulla macchina client.

Sintassi generale:pdadmin> server task <nome-server> create ... –j ...

Per ogni pagina richiesta, un cookie :”identificativo-junction” viene inviato alclient. Il cookie contiene la seguente variabile e il seguente valore:IV_JCT_<nome-server-backend> = </nome-junction>

Quando il client effettua una richiesta da questa pagina utilizzando un URLcorrelato al server e generato dinamicamente, WebSEAL (come in precedenza)riceve una richiesta per una risorsa locale. Quando non riesce a localizzare larisorsa, WebSEAL immediatamente riprova la richiesta utilizzando le informazionidi junction fornite dal cookie. Con le corrette informazioni di junctionnell’espressione URL, la risorsa viene localizzata.


Il seguente diagramma illustra questa soluzione per il filtro di URL correlati alserver.

WebSEAL fornisce una soluzione alternativa, non basata su cookie, per la gestionedi URL correlati al server e dinamicamente generati. Consultare “Gestione di URLcorrelati al server mediante associazione di junction” a pagina 168.

Gestione di URL correlati al server mediante associazione dijunctionGli URL correlati al server generati sul client da applet e script inizialmenteperdono la conoscenza del punto di junction. WebSEAL non può filtrare l’URLperché questo è generato sul client. Durante una richiesta di risorsa effettuata dalclient mediante questo URL, WebSEAL può provare a rielaborare l’URL correlato alserver utilizzando l’associazione di junction.

Access Manager fornisce un’alternativa alla soluzione basata su cookie per il filtrodi URL correlati al server generati dinamicamente. E’ possibile creare e attivare unatabella di associazioni di junction che associa risorse di destinazione specifiche anomi di junction.

WebSEAL verifica le informazioni di ubicazione nell’URL correlato al server con idati contenuti nella tabella di associazione junction. Se le informazioni di percorsonell’URL corrispondono a una voce della tabella, WebSEAL indirizza la richiesta aljunction associato a tale ubicazione.

La tabella è un file di testo ASCII denominato jmt.conf. L’ubicazione di questo fileè specificata nella stanza [junction] del file di configurazione webseald.conf:jmt-map = lib/jmt.conf

Il formato per la voce di dati nella tabella è composto dal nome di junction, unospazio e il modello di ubicazione della risorsa. E’ anche possibile utilizzarecaratteri globali per esprimere il modello di ubicazione della risorsa.

Nel seguente esempio del file di configurazione di associazione junction, dueserver back-end sono congiunti a WebSEAL su /jctA e /jctB:#jmt.conf#<nome-junction> <modello-ubicazione-risorsa>/jctA /documents/release-notes.html/jctA /travel/index.html/jctB /accounts/*/jctB /images/weather/*.jpg

Client

WebSEALServer

delle applicazioni(Javascript )serves

Script contenentel’URL relativo al server:

/abc.html

/jctA

con l’opzione -j

Viene eseguito lo script e si creail collegamento: /abc.html

richiesta richiesta

Il client effettua la richiestamediante il collegamento:

/abc.html

abc.htmlindividuato correttamenteCookie inviato

con la richiesta

WebSEAL inoltra di nuovola richiesta come:/jctA/abc.html

1

2

3

/jctA

WebSEAL invia il cookieper identificare il nodo

/jctA

Figura 34. Elaborazione di URL correlati al server


La tabella di associazione jmt.conf originale è un file vuoto. Dopo aver aggiuntodati al file, è necessario utilizzare il comando jmt load per “caricare” i dati inmodo che WebSEAL venga a conoscenza delle nuove informazioni.pdadmin> server task <nome-server> jmt loadLa tabella JMT viene caricata correttamente.

Le seguenti condizioni si applicano alla soluzione di tabella di associazionejunction:v Questa soluzione non richiede l’opzione –j né il cookie di junctionv La tabella di associazione richiede l’impostazione e l’attivazione da parte di un

responsabile della sicurezzav Questa soluzione non gestisce collegamenti creati con URL assolutiv La corrispondenza del modello di ubicazione risorsa deve essere univoca nello

spazio Web locale e nei server di applicazione Web di junctionv Se esiste una voce di modello duplicata nel file, la tabella di associazione non

viene caricata. Tuttavia, WebSEAL continua l’esecuzione.v Se si verifica un errore durante il caricamento della tabella, quest’ultima non è

disponibile. Tuttavia, WebSEAL continua l’esecuzione.v Se la tabella di associazione è vuota oppure è presente un errore nelle voci, la

tabella non viene caricata. Tuttavia, WebSEAL continua l’esecuzione.v Qualsiasi errore che si verifica durante il caricamento della tabella di

associazione determina la presenza di voci di funzionalità nel file di log delserver WebSEAL (webseald.log).

Opzioni di junction supplementariE’ possibile fornire la seguente funzionalità junction aggiuntiva WebSEAL conopzioni supplementari:v “Forzatura di un nuovo junction (–f)” a pagina 169v “Per fornire l’identità client nelle intestazioni HTTP (–c)” a pagina 170v “Specifica di indirizzi IP client nelle intestazioni HTTP (–r)” a pagina 171v “Limitazione della dimensione di intestazioni HTTP generate da WebSEAL” a

pagina 172v “Trasmissione dei cookie di sessione ai server di portale di junction (–k)” a

pagina 173v “Supporto di URL non sensibili al maiuscolo/minuscolo (–i)” a pagina 173v “Supporto di junction di stato (–s, –u)” a pagina 174v “Specifica UUID di server back-end per junction di stato (–u)” a pagina 174v “Junction a file system Windows (–w)” a pagina 177

Forzatura di un nuovo junction (–f)E’ necessario utilizzare l’opzione –f quando si desidera forzare la sovrascrittura diun junction esistente con uno nuovo.

Il seguente esempio (nome istanza server = cruz) illustra questa procedura:1. Effettuare il login a pdadmin:

# pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>


2. Utilizzare il comando server task list per visualizzare tutti i punti di junctioncorrenti:pdadmin> server task webseald-cruz list/

3. Utilizzare il comando server task show per visualizzare i dettagli del junction:pdadmin> server task webseald-cruz show /Punto junction: /Tipo: LocaleLimite hard junction: 0 - utilizzando il valore globaleLimite soft junction: 0 - utilizzando il valore globaleThread di processo attivi: 0Directory principale: /opt/pdweb/www/docs

4. Creare un nuovo junction locale per sostituire il punto di junction corrente(l’opzione -f è necessaria per forzare la sovrascrittura del junction esistente conquello nuovo):pdadmin> server task webseald-cruz create -t local -f -d /tmp/docs /Junction creato su /

5. Elencare il nuovo punto di junction:pdadmin> server task webseald-cruz list/

6. Visualizzare i dettagli di questo junction:pdadmin> server task webseald-cruz show /Punto junction: /Tipo: LocaleLimite hard junction: 0 - utilizzando il valore globaleLimite soft junction: 0 - utilizzando il valore globaleThread di processo attivi: 0Directory root: /tmp/docs

Per fornire l’identità client nelle intestazioni HTTP (–c)L’opzione –c consente di inserire dati specifici di Access Manager sull’identitàclient e sull’appartenenza a gruppi nelle intestazioni HTTP delle richieste destinatea server di junction di terzi. Le informazioni dell’intestazione HTTP abilitano leapplicazioni su server di junction di terzi ad eseguire azioni specifiche dell’utentebasate sull’identità Access Manager del client.

Le informazioni di intestazione HTTP devono essere trasformate dal serverback-end in formato di variabile di ambiente utilizzabile da un servizio situato sulserver back-end. Le informazioni di intestazione vengono trasformate in unformato di variabile di ambiente CGI sostituendo tutti i trattini (-) consottolineature (_) e aggiungendo “HTTP” all’inizio della stringa. Il valoredell’intestazione HTTP diventa il valore della nuova variabile di ambiente.

Campo di intestazione HTTPspecifici per PD

Variabile di ambienteequivalenti

Descrizione

iv-user = HTTP_IV_USER = Il nome lungo o abbreviato del client. Se il client nonè autenticato (sconosciuto), il valore predefinito è“Non autenticato”.

iv-groups = HTTP_IV_GROUPS = Un elenco di gruppi ai quali appartiene il client. E’formato da voci tra apici e separate da virgole.


Campo di intestazione HTTPspecifici per PD

Variabile di ambienteequivalenti

Descrizione

iv-creds = HTTP_IV_CREDS = Struttura di dati non visibili codificati cherappresenta una credenziale Access Manager.Fornisce le credenziali ai server remoti in modo chele applicazioni mid-tier possano utilizzare l’API diautorizzazione per richiamare il servizio diautorizzazione. Fare riferimento a IBM Tivoli AccessManager Authorization C API Developer’s Reference.

Le voci di intestazione HTTP specifiche per Access Manager sono disponibili perprogrammi CGI come variabili di ambiente HTTP_IV_USER, HTTP_IV_GROUPSe HTTP_IV_CREDS. Per prodotti di altre strutture di applicazione, fare riferimentoalla documentazione del prodotto per le istruzioni sull’estrazione di intestazioni darichieste HTTP.

Sintassi di –cL’opzione –c specifica quali dati di intestazione HTTP specifica per AccessManager vengono inviati al server di applicazione di back-end.–c <tipi-intestazione>

L’argomento tipi-intestazione include: all, iv_user, iv_user_l, iv_groups, andiv_creds.


iv_user Fornisce il nome utente (in formato abbreviato) come campo iv-usernell’intestazione HTTP della richiesta.

iv_user_l Fornisce il DN completo dell’utente (in formato lungo) come campoiv-user nell’intestazione HTTP della richiesta.

iv_groups Fornisce l’elenco di gruppi dell’utente come campo iv-groupsnell’intestazione HTTP della richiesta.

iv_creds Fornisce le informazioni sulla credenziale dell’utente come campoiv-creds nell’intestazione HTTP della richiesta.

Nota: Utilizzare iv_user oppure iv_user_l, ma non entrambi.

L’opzione –c all inserisce tutti e tre i tipi di informazione di identitànell’intestazione HTTP (in questo caso viene utilizzato il formato di nomeabbreviato (iv_user )).

Nota: Separare argomenti multipli solo mediante virgole. Non immettere spazi.

Esempi:–c all

–c iv_creds

–c iv_user,iv_groups

–c iv_user_l,iv_groups,iv_creds

Specifica di indirizzi IP client nelle intestazioni HTTP (–r)L’opzione –r consente di inserire informazioni sull’indirizzo IP del client nelleintestazioni HTTP delle richieste destinate a server di applicazione di junction. Le


informazioni dell’intestazione HTTP abilitano le applicazioni su server di junctiondi terzi ad eseguire azioni in base a tali informazioni sull’indirizzo IP.

Le informazioni di intestazione HTTP devono essere trasformate dal serverback-end in formato di variabile di ambiente utilizzabile da un servizio situato sulserver back-end. Le informazioni di intestazione vengono trasformate in unformato di variabile di ambiente CGI sostituendo tutti i trattini (-) consottolineature (_) e aggiungendo “HTTP” all’inizio della stringa. Il valoredell’intestazione HTTP diventa il valore della nuova variabile di ambiente.

Nota: Il valore dell’indirizzo IP non sempre rappresenta l’indirizzo della macchinaclient di origine. Il valore dell’indirizzo IP potrebbe rappresentare l’indirizzodi un server proxy oppure un NAT (network address translator).

Campo di intestazione HTTPspecifico per PD

Variabile di ambienteCGI equivalente

Descrizione

iv-remote-address HTTP_IV_REMOTE_ADDRESS L’indirizzo IP del client. Questo valore potrebberappresentare l’indirizzo IP di un server proxyoppure un NAT (network address translator).

L’opzione –r specifica che l’indirizzo IP della richiesta in arrivo deve essere inviatoal server di applicazione di back-end. L’opzione viene espressa senza alcunargomento.

Limitazione della dimensione di intestazioni HTTP generate daWebSEAL

E’ possibile limitare la dimensione delle intestazioni HTTP generate da WebSEALche vengono inserite nelle richieste a server back-end di junction. Il parametromax-webseal-header-size nella stanza [junction] del file di configurazionewebseald.conf specifica la dimensione massima, in byte, delle intestazioni HTTPgenerate da WebSEAL. Un valore “0” disabilita questa funzione:[junction]max-webseal-header-size = 0

Questo parametro può essere utile se un server di applicazione back-end rifiutaintestazioni HTTP generate da WebSEAL perchè troppo grandi. Ad esempio,un’intestazione iv-creds per un utente appartenente a troppi gruppi potrebbeessere troppo grande.

Quando viene configurato, questo parametro fa in modo che le intestazionigenerate da WebSEAL eccedenti il valore massimo vengano suddivise in piùintestazioni. L’esempio seguente di output da un’applicazione CGI illustra l’effettodella suddivisione delle intestazioni:HTTP_IV_CREDS_1=Version=1, BAKs3DCCBnMMADCCBm0wggZpAgIDkDCCAYUwKzAHTTP_IV_CREDS_2=+0+8eAgI8iAICEdYCAgCkAgFUBAaSVNCJqncMOWNuPXNlY21==HTTP_IV_CREDS_SEGMENTS=2

Se si abilita questa funzione, è necessario modificare l’applicazione di back-endperché possa riconoscere intestazioni suddivise anziché intestazioni HTTP standardspecifiche di WebSEAL.


Trasmissione dei cookie di sessione ai server di portale dijunction (–k)

Un portale Web è un server che offre un’ampia gamma di risorse e servizipersonalizzati. L’opzione –k consente di inviare il cookie di sessione AccessManager (in origine stabilito tra il client e WebSEAL) a un server back-end diportale. Questa opzione esiste attualmente per supportare direttamentel’integrazione di WebSEAL con la soluzione Plumtree Corporate Portal.

Quando un client richiede un elenco di risorse personale dal server di portale,quest’ultimo crea tale elenco accedendo alle risorse ubicate su altri server diapplicazione di supporto, anch’essi protetti da WebSEAL. Il cookie di sessionepermette al server di portale di eseguire un singolo collegamento (SSO) ininterrottoa questi server di applicazione per conto del client.

L’opzione –k, senza argomenti, viene inclusa quando si crea il junction traWebSEAL e il server back-end di portale.

Condizioni da considerare per la configurazione di un server di portale:v Per accedere mediante nome utente e password, è richiesta l’autenticazione

Moduli. Non utilizzare l’autenticazione BA (Basic Authentication).v Il parametro ssl-id-sessions nella stanza [session] del file di configurazione

webseald.conf deve essere impostato su “no”. Per comunicazioni HTTPS, questaimpostazione forza l’utilizzo di un cookie di sessione, anziché l’ID sessione SSL,per mantenere lo stato di sessione.

v Se il server di portale è posto come front-end mediante un cluster WebSEAL,abilitare il cookie di tipo failover. Il cookie di failover contiene informazioni dicredenziale crittografate che consentono l’autenticazione con qualsiasi serverWeb di replica che elabora la richiesta.

Supporto di URL non sensibili al maiuscolo/minuscolo (–i)Per impostazione predefinita, Access Manager tratta gli URL come sensibili almaiuscolo/minuscolo durante l’esecuzione dei controlli sull’accesso. L’opzione –iviene utilizzata per specificare che WebSEAL tratta gli URL come insensibili almaiuscolo/minuscolo durante l’esecuzione delle verifiche di autorizzazione peruna richiesta su un server back-end di junction.

Quando si imposta questa opzione sul junction, WebSEAL non distingue tra letteremaiuscole e minuscole durante l’analisi degli URL. Per impostazione predefinita, iserver Web sono sensibili al maiuscolo/minuscolo.

Sebbene la maggior parte dei server HTTP supporti la specifica HTTP che definiscegli URL come sensibili al maiuscolo/minuscolo, alcuni server HTTP trattano gliURL come non sensibili a questa distinzione.

Ad esempio, su server non sensibili, i due URL seguenti:http://server/sales/index.htm

http://server/SALES/index.HTM

vengono visualizzati come lo stesso URL. Questo comportamento richiede che unresponsabile inserisca gli stessi controlli dell’accesso (ACL) su entrambi gli URL.

Congiungendo un server di terzi con l’opzione –i, WebSEAL tratta gli URLindirizzati a tale server come non sensibili al maiuscolo/minuscolo.


Supporto di junction di stato (–s, –u)La maggior parte delle applicazioni abilitate al Web mantengono uno “stato” peruna sequenza di richieste HTTP provenienti da un client. Questo stato vieneutilizzato, ad esempio, per:v Tracciare il progresso di un utente attraverso i campi di un modulo di

immissione dati generato da un programma CGIv Mantenere il contesto di un utente durante l’esecuzione di una serie di richieste

di informazioni dal databasev Mantenere un elenco di elementi in un’applicazione di carrello della spesa online

in cui un utente esamina casualmente e seleziona elementi da acquistare

I server che eseguono applicazioni abilitate per il Web possono essere replicati permigliorare le prestazioni attraverso la condivisione del carico. Quando il serverWebSEAL fornisce un junction a questi server back-end di replica, deve assicurareche tutte le richieste contenute in una sessione del client vengano indirizzate alserver corretto e non distribuite tra i server back-end di replica in base alle regoledi bilanciamento del carico.

Per impostazione predefinita, Access Manager bilancia il carico dei server diback-end distribuendo le richieste su tutti i server di replica disponibili. AccessManager utilizza un algoritmo di “minimo impiego”. Questo algoritmo indirizzaogni nuova richiesta al server che presenta il minor numero di connessioni incorso.

L’indicatore –s del comando create ricopre questa regola di bilanciamento delcarico e crea un “junction di stato” che assicura alla richiesta di un client di essereinoltrata allo stesso server durante un’intera sessione. Quando avviene la richiestainiziale del client, WebSEAL inserisce un cookie sul sistema del client che contienel’UUID del server back-end designato. Quando il client effettua future richiestedella stessa risorsa, i dati UUID del cookie assicurano che le richieste venganocoerentemente indirizzate allo stesso server di back-end.

L’opzione –s è adatta per un singolo server WebSEAL front-end con multipli serverback-end di junction sullo stesso punto di junction. Notare che una volta creato iljunction iniziale come junction di stato, il comando add viene utilizzato senzal’opzione –s per congiungere i rimanenti server back-end di replica allo stessopunto di junction.

Se lo scenario coinvolge più server WebSEAL front-end, tutti congiunti agli stessiserver back-end, è necessario utilizzare l’opzione –u per specificare correttamenteogni UUID di server back-end ad ogni server WebSEAL front-end. Consultare“Specifica UUID di server back-end per junction di stato (–u)”.

Specifica UUID di server back-end per junction di stato (–u)Quando un nuovo junction viene creato per un server di applicazione Webback-end, WebSEAL normalmente genera un UUID (Unique Universal Identifier)per identificare tale server di back-end. Questo UUID viene utilizzato internamenteanche per mantenere junction di stato (create –s).

Quando avviene la richiesta iniziale del client, WebSEAL inserisce un cookie sulsistema del client che contiene l’UUID del server back-end designato. Quando ilclient effettua future richieste della stessa risorsa, i dati UUID del cookie


assicurano che le richieste vengano coerentemente indirizzate allo stesso server diback-end.

La gestione di junction di stato diventa più complessa quando esistono più serverWebSEAL front-end congiunti a più server back-end. Normalmente, ogni junctiontra un server WebSEAL front-end e un server back-end genera un UUID univocoper il server back-end. Ciò significa che un singolo server back-end avrà undiverso UUID su ciascun server WebSEAL front-end.

Server front-end multipli richiedono un meccanismo di bilanciamento del caricoper distribuire il carico tra i due server. Ad esempio, uno “stato” iniziale potrebbeessere stabilito con un server back-end attraverso il server WebSEAL 1 medianteuno specifico UUID.

Tuttavia, se una futura richiesta dello stesso client viene indirizzata attraverso ilserver WebSEAL 2 dal meccanismo di bilanciamento del carico, lo “stato” nonesisterà più, a meno che il server WebSEAL 2 non utilizzi lo stesso UUID peridentificare lo stesso server back-end. Normalmente, questo caso non si verifica.

L’opzione –u consente di fornire lo stesso UUID di uno specifico server back-end aogni server WebSEAL front-end.

Come esempio, considerare due server WebSEAL front-end di replica, ognuno conun junction di stato per i due server back-end. Quando si crea il junction di statotra il server WebSEAL 1 e il server di back-end 2, un UUID univoco (UUID A)viene generato per identificare il server di back-end 2. Tuttavia, quando vienecreato un junction di stato tra il server WebSEAL 2 e il server di back-end 2, unnuovo e differente UUID (UUID B) viene generato per identificare il server diback-end 2.

WebSEAL

Server delleapplicazioni 1

(UUID1)


(UUID2)

ClientNodi

statefulCookiecon

UUID2

Figura 35. Utilizzo di UUID di server back-end da parte di junction con stato


Uno “stato” stabilito tra un client e il server di back-end 2, attraverso il serverWebSEAL 1 non funzionerà se una successiva richiesta proveniente dal client vieneindirizzata attraverso il server WebSEAL 2.

Applicare il seguente processo per specificare un UUID durante la creazione di unjunction:1. Creare un junction dal server WebSEAL 1 ad ogni server back-end.

Utilizzare create –s e add.2. Elencare l’UUID generato per ogni server back-end durante il Passo 1.

Utilizzare show.3. Creare un junction dal server WebSEAL 2 ad ogni server back-end e specificare

gli UUID identificati nel Passo 2.Utilizzare create –s –u e add –u.

Nell’esempio seguente, il server di back-end 1 è conosciuto da WebSEAL-1 e daWebSEAL-2 come UUID 1. Il server di back-end 2 è conosciuto da WebSEAL-1 e daWebSEAL-2 come UUID 2.

Esempio:Nell’esempio seguente,v WebSEAL-1 è denominato WS1v WebSEAL-2 è denominato WS2v Il server back-end 1 è denominato APP1

WebSEAL-1


Nodistateful

WebSEAL-2

UUID B

Server delleapplicazioni 1UUID A

Figura 36. UUID differenti

WebSEAL-1


(UUID 2)

Nodistateful

Meccanismo dibilanciamento

di carico

WebSEAL-2

Client

Cookiecon

UUID 2


(UUID 1)

Figura 37. Specifica di UUID di server back-end per junction di stato


v Il server back-end 2 è denominato APP2pdadmin> server task webseald-WS1 create –t tcp –h APP1 –s /mntpdadmin> server task webseald-WS1 add –h APP2 /mntpdadmin> server task webseald-WS1 show /mnt

(In questo modo viene rilevato UUID1 e UUID2)pdadmin> server task webseald-WS2 create –t tcp –h APP1 –u <UUID1> –s /mntpdadmin> server task webseald-WS2 add –h APP2 –u <UUID2> /mnt

Quando un client stabilisce una connessione di stato con il server back-end 2,riceve un cookie contenente UUID2. L’esempio precedente assicura che il clientverrà sempre collegato al server back-end 2, indipendentemente dal fatto se lefuture richieste vengono instradate attraverso WebSEAL-1 o WebSEAL-2.

Junction a file system Windows (–w)WebSEAL esegue verifiche di protezione sulle richieste client a server back-end dijunction in base ai percorsi file specificati nell’URL. Un compromesso su questeverifiche di protezione può verificarsi poiché i file system di Win32 consentonodue differenti metodi per accedere a nomi di file lunghi.

Il primo metodo riconosce l’intero nome file. Ad esempio:abcdefghijkl.txt

Il secondo metodo riconosce il vecchio formato di nome file 8.3 per la compatibilitàretroattiva. Ad esempio:abcdef~1.txt

Quando si creano junction in un ambiente Windows, è importante limitare ilcontrollo dell’accesso a una sola rappresentazione di un oggetto e non consentire lapossibilità di “porte secondarie” per superare il meccanismo di protezione.

L’opzione –w su un junction fornisce le seguenti misure di protezione:1. Previene l’utilizzo del formato nome file 8.3

Quando un junction viene configurato con l’opzione –w, un utente non puòevitare un ACL esplicito su un nome di file lungo utilizzando il formatoabbreviato (8.3) del nome file. Il server restituisce un errore “403 Accessovietato” su qualsiasi nome file in formato abbreviato che viene immesso.

2. Non consente l’utilizzo di punti finali in nomi di directory e di fileSe un file o una directory contiene punyi finali, viene restituito un errore 403“Accesso vietato”.

3. Rafforza la insensibilità al maiuscolo/minuscolo impostando l’opzione –i

L’opzione –w richiama automaticamente l’opzione –i. Questa opzione specificache WebSEAL tratta gli URL come insensibili al maiuscolo/minuscolo durantel’esecuzione delle verifiche di autorizzazione per una richiesta su un serverback-end di junction. Dopo una corretta verifica ACL, il carattere originaledell’URL viene ripristinato quando la richiesta viene inviata al server back-end.

Nota: Se si richiede il controllo sulla sensibilità esclusivamente per i nomi file,utilizzare solo l’opzione –i sul junction anziché l’opzione –w.

Esempio:In un ambiente Windows, è possibile accedere al file:\Program Files\Company Inc\Release.Notes


anche attraverso i seguenti percorsi:1. \progra~1\compan~2\releas~3.not

2. \Program Files\Company Inc.\Release.Notes

3. \program files\company inc\release.notes

L’esempio 1 illustra come Windows può creare un alias (per la compatibilità DOS)che non contiene spazi nei nomi file ed è conforme al formato 8.3. L’opzione –wprovoca il rifiuto, da parte di WebSEAL, di questo formato per le verifiche ACL.

L’esempio 2 illustra come Windows può includere punti di estensione finali.L’opzione –w provoca il rifiuto, da parte di WebSEAL, di questo formato per leverifiche ACL.

L’esempio 3 illustra come Windows consente l’insensibilità al maiuscolo/minuscolosul nome file. L’opzione –w richiama l’opzione –i per assicurare una verifica ACLinsensibile al maiuscolo/minuscolo.

Note tecniche per l’utilizzo di junction WebSEALv “Montaggio di server multipli sullo stesso junction” a pagina 178v “Eccezioni nell’applicazione di autorizzazioni sui junction” a pagina 178v “Autenticazione di certificato attraverso junction” a pagina 179

Montaggio di server multipli sullo stesso junctionE’ possibile montare server di replica multipli sullo stesso punto di junction. Sullostesso punto è possibile montare un qualsiasi numero di server.

Tutti i server montati su un punto di junction devono essere repliche (spazi Webriflessi) e devono utilizzare lo stesso protocollo — HTTP o HTTPS. Non montareserver dissimili sullo stesso punto di junction.

Dallo spazio Web del server Access Manager primario, accedere alle pagineappartenenti ai server di junction. L’utente deve essere in grado di accedere aqueste pagine (soggette a autorizzazioni, naturalmente) e le pagine devonoapparire coerenti. Se, occasionalmente, una pagina non viene trovata, oppure seviene occasionalmente modificata, significa che la pagina non è stata replicatacorrettamente.

Verificare che il documento esista e che sia identico nella struttura dei documentidi entrambi i server di replica.

Eccezioni nell’applicazione di autorizzazioni sui junctionAlcune autorizzazioni Access Manager non sono applicabili su un junction. Non èpossibile controllare, ad esempio, l’esecuzione di uno script CGI conl’autorizzazione x, oppure un elenco di directory con l’autorizzazione l. WebSEALnon ha modo di determinare se un oggetto richiesto su un server back-end sia, adesempio, un file di programma CGI, un elenco di directory dinamico oppure unoggetto HTTP regolare.

L’accesso a oggetti attraverso junction, incluso programmi CGI e elenchi didirectory, è controllato solo attraverso l’autorizzazione r.


Autenticazione di certificato attraverso junctionAl momento dell’installazione, WebSEAL è configurato con un certificato di provanon predefinito. Il certificato di prova è indicato come il certificato attivo del serverdal parametro webseal-cert-keyfile-label nella stanza [ssl] del file diconfigurazione webseald.conf.

Se un server di applicazione back-end di junction richiede a WebSEAL diidentificare sé stesso con un certificato del client, è prima necessario creare,installare e etichettare tale certificato mediante il programma di utilità iKeyman.Quindi, configurare il junction utilizzando l’opzione –K <etichetta-chiave>.Consultare “Junction SSL autenticati reciprocamente” a pagina 158

Se il junction non è configurato con –K, GSKit gestisce una richiesta diautenticazione reciproca inviando automaticamente il certificato “predefinito”contenuto nel database dei file di chiavi. Se questa non è la risposta richiesta, ènecessario assicurarsi che non siano presenti certificati contrassegnati come“predefiniti” (mediante un asterisco) nel database dei file di chiavi (pdsrv.kdb).

Riepilogando:v Identificare tutti i certificati richiesti mediante nome di etichetta.v Non contrassegnare alcun certificato del database file di chiavi come

“predefinito”.v Controllare la risposta del certificato del server WebSEAL con il parametro

webseal-cert-keyfile-label.v Controllare la risposta del certificato del client WebSEAL attraverso l’opzione di

junction –K.

Utilizzo di query_contents con server di terziSe si desidera proteggere le risorse dello spazio Web di applicazioni di terziutilizzando il servizio di sicurezza di Access Manager, è necessario fornire aWebSEAL le informazioni sul contenuto dello spazio Web di terzi.

Un programma CGI denominato query_contents fornisce queste informazioni. Ilprogramma query_contents effettua la ricerca nei contenuti dello spazio Web diterzi e fornisce queste informazioni di inventario al gestore di portale Web suWebSEAL. Il programma viene fornito con l’installazione di WebSEAL, ma deveessere installato manualmente sul server di terzi. Sono disponibili diversi tipi difile di programma, a seconda che il server di terzi sia basato su UNIX o suWindows.

Il gestore dello spazio oggetti del gestore di portale Web esegue automaticamentequery_contents ogni volta che la porzione dello spazio oggetti protetti cherappresenta il junction viene espansa nel pannello di gestione dello spazio oggetti.Ora che il gestore di portale Web conosce il contenuto dello spazio di applicazionedi terzi, è possibile visualizzare queste informazioni e applicare maschere dicriterio agli oggetti appropriati.

Installazione dei componenti query_contentsL’installazione di query_contents è generalmente molto semplice. L’installazionecomporta la copia di uno o due file dal server Access Manager al server di terzi ela modifica di un file di configurazione.

La seguente directory Access Manager contiene una maschera del programma:


UNIX: <percorso-installazione>/www/lib/query_contents

Windows: <percorso-installazione>\www\lib\query_contents

Il contenuto della directory include:

File Descrizione

query_contents.exe Programma principale eseguibile per sistemi Win32.Dovrebbe essere installato nella directory cgi-bin delserver Web di terzi.

query_contents.sh Programma principale eseguibile per sistemi UNIX.Dovrebbe essere installato nella directory cgi-bin delserver Web di terzi.

query_contents.c Codice sorgente. Il sorgente viene fornito nel caso sianecessaio modificare il comportamento di query_contents.Nella maggior parte dei casi, ciò non sarà necessario.

query_contents.html File di aiuto in formato HTML.

query_contents.cfg Un file di configurazione di esempio che identifica la rootdi documenti per il server Web.

Installazione di query_contents su server UNIX di terziLocalizzare lo script shell denominato query_contents.sh nella seguente directory:<percorso-installazione>/www/lib/query_contents

1. Copiare query_contents.sh in una directory /cgi-bin funzionante sul serverWeb di terzi.

2. Rimuovere l’estensione .sh.3. Impostare il bit di esecuzione UNIX per l’account di amministrazione del server

Web.

Installazione di query_contents su server Win32 di terziOpzione di junction speciale per Windows:

Quando si richiede e si installa il programma query_contents su un server diapplicazione Web back-end di junction Windows, è necessario utilizzare l’opzione–q durante la creazione del junction su tale server.

Il motivo di questo requisito è che, per impostazione predefinita, WebSEAL ricercail programma, query_contents, nella directory cgi-bin:/cgi-bin/query_contents

Se si modifica il nome del programma query_contents o si modifica l’ubicazionedella relativa directory, è necessario utilizzare l’opzione –q <ubicazione> durantela creazione del junction. L’argomento ubicazione specifica la nuova posizione e ilnome del programma.

Il nome del programma query_contents utilizzato sulla piattaforma Windows èquery_contents.exe. La presenza dell’estensione .exe rende differente il nome delprogramma. Quindi, WebSEAL non può trovare il nome predefinito delprogramma. E’ necessario utilizzare l’opzione e l’argomento –q <ubicazione> percomunicare a WebSEAL il punto in cui trovare il file. Ad esempio:create -t tcp -h <nome-host> ... -q /cgi-bin/query_contents.exe /<nome-junction>


L’opzione –q non è richiesta per un server UNIX poiché il nome e l’ubicazione delprogramma query_contents corrispondono alla condizione predefinita.

Procedura:

Localizzare il programma eseguibile denominato query_contents.exe e il file diconfigurazione denominato query_contents.cfg nella seguente directory:

Windows: <percorso-installazione>\www\lib\query_contents

1. Assicurarsi che il server Web di terzi disponga di una directory CGIconfigurata in modo corretto.

2. A scopo di prova, assicurarsi che un documento valido sia presente nella rootdei documenti del server Web di terzi.

3. Copiare query_contents.exe nella directory CGI del server Web di terzi.4. Copiare query_contents.cfg nella directory Windows.

I valori predefiniti per questa directory sono illustrati nella seguente tabella:

Sistema operativo Directory Windows

Windows 95 e 98 c:\windows

Windows NT 4.x e 2000 c:\winnt

5. Modificare il file query_contents.cfg per specificare in modo corretto ladirectory root dei documenti per il server Web di terzi.Il file attualmente contiene voci di esempio per i server Microsoft InternetInformation Server e Netscape FastTrack. Le righe di questo file che inizianocon un punto e virgola (;) rappresentano commenti e vengono ignorate dalprogramma query_contents.

6. Creare un junction per il server back-end Windows e utilizzare l’opzione –q perspecificare query_contents.exe come file corretto. Ad esempio:pdadmin> server task webseald-<nome-istanza> create -t tcp -h <nome-host> ... \-q /cgi-bin/query_contents.exe /<nome-junction>

Test della configurazione1. Da un prompt MS-DOS sulla macchina Win32, eseguire il programma

query_contents dalla directory CGI, nel modo riportato di seguito:MSDOS> query_contents dirlist=/

Dovrebbe essere visualizzato qualcosa di simile alla seguente emissione:100index.htmlcgi-bin//pics//

Il numero 100 è uno stato di ritorno che indica l’esito positivo. E’ moltoimportante vedere almeno il numero 100 come primo valore (e probabilmentel’unico).

Se invece viene visualizzato un codice di errore, il file di configurazione non sitrova nella posizione corretta oppure non contiene una valida voce di root deidocumenti. Verificare la configurazione del file query_contents.cfg eassicurarsi che la root dei documenti sia presente.

2. Da un browser, immettere il seguente URLhttp://<nome-macchina-win32>/cgi-bin/query_contents.exe?dirlist=/


L’output corrisponde a quello sopra riportato. Se non viene restituito questorisultato, la configurazione CGI del proprio server Web non è corretta. fareriferimento alla documentazione del server per correggere il problema.

Personalizzazione di query_contentsIl compito di query_contents è quello di restituire il contenuto delle directoryincluse in una richiesta URL.

Ad esempio, per ottenere il contenuto della directory principale dello spazio Webdi un server, il browser esegue query_contents su un URL del tipo:http://server-di-terzi/cgi-bin/query_contents?dirlist=/

Lo script query_contents esegue le seguenti azioni:1. Consultare $SERVER_SOFTWARE, una variabile di ambiente CGI standard,

per determinare il tipo di server.In base al tipo di server Web, la variabile $DOCROOTDIR è impostata in unatipica ubicazione di root dei documenti.

2. Consultare la variabile di ambiente $QUERY_STRING dall’URL di richiesta perottenere l’operazione richiesta e richiamare il percorso oggetto.Il valore dell’operazione è memorizzato nella variabile $OPERATION, e ilpercorso oggetto in $OBJPATH. Nell’esempio precedente, $OPERATIONcorrisponde a dirlist e $OBJPATH corrisponde a “/”.

3. Effettua un elenco di directory (ls) sul percorso oggetto e sistema i risultati suoutput standard, per l’utilizzo da parte del server Access Manager. Gli elementiche indicano sottodirectory presentano una doppia barra (//) accodata.L’output tipico è:100index.htmlcgi-bin//pics//

Il numero 100 è uno stato di ritorno che indica l’esito positivo.

Personalizzazione della directory principale dei documentiUNIX:

Per personalizzare query_contents.sh per il proprio server UNIX, può esserenecessario dover modificare l’impostazione della directory root dei documenti.

Se query_contents restituisce una condizione di errore (un numero diverso da 100)e non elenca alcun file, esaminare lo script e modificare la variabile$DOCROOTDIR, se necessario, per rispondere alla configurazione del proprioserver.

Se la directory root dei documenti è specificata correttamente e lo script continua anon funzionare, la specifica dell’ubicazione di cgi-bin potrebbe non essere corretta.Esaminare la variabile $FULLOBJPATH e modificarne il valore in modo dariflettere la corretta ubicazione di cgi-bin.

Windows:

Per personalizzare query_contents.exe per il proprio server Windows, modificareil file query_contents.cfg.


Funzionalità aggiuntiveIl codice sorgente per il programma query_contents (query_contents.c) èdistribuito gratuitamente con Access Manager.

E’ possibile aggiungere ulteriori funzionalità a questo programma per supportarefunzioni speciali di alcuni server Web prodotti da terzi. Queste funzionicomprendono:1. Associazione di directory — in cui una sottodirectory non situata al di sotto

della root dei documenti viene associata nello spazio Web.2. Creazione di uno spazio Web non basato sul file system.

Questo potrebbe essere il caso di un server Web gestito da database.

Protezione di query_contentsIl programma CGI query_contents viene utilizzato da Access Manager pervisualizzare spazi di oggetti del server Web di junction nel gestore di portale Web.E’ molto importante proteggere questo file per impedirne l’esecuzione da parte diutenti non autorizzati.

E’ necessario impostare un criterio di protezione che consenta solo all’identità delserver dei criteri (pdmgrd) l’accesso al programma query_contents. Il seguenteACL di esempio (query_contents_acl) risponde a questo criterio:group ivmgrd-servers Tl

user sec_master dbxTrlcam

Utilizzare il programma di utilità pdadmin per collegare questo ACL all’oggettoquery_contents.sh (UNIX) o query_contents.exe (Windows) sui server di junction.Ad esempio (UNIX):pdadmin> acl attach /WebSEAL/<host>/<nome-junction>/query_contents.sh \query_contents_acl


Capitolo 8. Soluzioni Web single sign-on

Quando WebSEAL viene implementato come server proxy per fornire la protezionea un dominio protetto, viene spesso richiesto di fornire soluzioni per single sign-onalle risorse Web. Questo capitolo illustra le soluzioni single sign-on per lo spazioWeb di una configurazione proxy di WebSEAL. Gli esempi comprendono junction,Global Sign-on e LTPA configurati appositamente.

Indice degli argomenti:v “Configurazione di intestazioni BA per soluzioni single sign-on” a pagina 185v “Utilizzo di GSO (global sign-on)” a pagina 189v “Configurazione SSO (single sign-on) per IBM WebSphere (LTPA)” a pagina 192v “Configurazione dell’autenticazione SSO (single sign-on) di moduli” a pagina

194

Configurazione di intestazioni BA per soluzioni single sign-onQuesta sezione descrive le possibili soluzioni per la creazione di configurazionisingle sign-on su junction WebSEAL mediante le opzioni –b.v “Concetti SSO (single sign-on)” a pagina 185v “Per fornire l’identità client nelle intestazioni BA” a pagina 186v “Specifica dell’identità client e di una password generica” a pagina 186v “Invio di informazioni sull’intestazione BA originale del client” a pagina 187v “Rimozione delle informazioni di intestazione BA del client” a pagina 188v “Specifica di nomi utente e password da GSO” a pagina 189

Concetti SSO (single sign-on)Quando una risorsa protetta è ubicata su un server di applicazioni Web back-end,un client che richiede tale risorsa può dover eseguire login multipli, uno per ilserver WebSEAL e uno per il server back-end. Ciascun login probabilmenterichiede diverse identità di login.

Il problema della gestione e della manutenzione di più identità di login può spessoessere risolto grazie a un meccanismo SSO (single sign-on). Una soluzione singlesign-on consente all’utente di accedere a una risorsa, indipendentemente

Client WebSEALWeb


Nodo

Registrazione#1

Registrazione#2

Figura 38. Login multipli


dall’ubicazione della risorsa, mediante un solo login iniziale. Qualsiasi ulteriorerequisito di login dai server back-end viene gestito in modo visibile all’utente.

Per fornire l’identità client nelle intestazioni BAE’ possibile configurare junction WebSEAL per poter fornire al server back-end leinformazioni sull’identità del client originali o modificate. La serie di opzioni –bconsente all’utente di fornire specifiche informazioni sull’identità del client nelleintestazioni BA (Basic Authentication) HTTP.

In qualità di responsabile, l’utente deve analizzare l’architettura della rete e irequisiti di sicurezza, nonché rispondere alle seguenti domande:1. Le informazioni di autenticazione sono richieste dal server back-end?

(WebSEAL utilizza l’intestazione Basic Authentication HTTP per convogliare leinformazioni di autenticazione.)

2. Se le informazioni di autenticazione sono richieste dal server back-end, da doveprovengono tali informazioni?(Quali informazioni WebSEAL inserisce nell’intestazione HTTP?)

3. La connessione tra WebSEAL e il server back-end deve essere protetta?(Junction SSL o TCP?)

Dopo l’autenticazione iniziale tra il client e WebSEAL, WebSEAL è in grado dicreare una nuova intestazione BA (Basic Authentication). La richiesta utilizzaquesta nuova intestazione per continuare attraverso il junction verso il serverback-end. L’utente utilizza le opzioni –b per specificare le informazioni diautenticazione specifiche da fornire in questa nuova intestazione.

Specifica dell’identità client e di una password generica–b supply

L’opzione –b supply istruisce WebSEAL alla fornitura del nome utente AccessManager autenticato (identità originale del client) con una password statica egenerica (“fittizia”). La password originale del client non viene utilizzata in questoscenario.

Una password generica elimina l’operazione di amministrazione della password esupporta l’applicazione sulla base di singolo utente. La password “fittizia” (odummy) viene impostata nel parametro basicauth-dummy-passwd del file diconfigurazione webseald.conf:[junction]basicauth-dummy-passwd = <password>

Client WebSEALWeb


Nuova intestazione BA coninformazioni sull’autenticazione

fornite da WebSEAL

L’autenticazione iniziale restituiscele credenziali di Policy Director

nodo

richi est a richi est a

Figura 39. Specifica di informazioni di autenticazione ai server back-end


Questo scenario presuppone che il server back-end richieda l’autenticazione daun’identità Access Manager. Associando un utente client ad un utente AccessManager conosciuto, WebSEAL gestisce l’autenticazione per il server back-end efornisce una semplice soluzione SSO (single sign-on) per l’intero dominio.

Per questa soluzione si verifica che:v WebSEAL viene configurato per fornire al server back-end il nome utente

contenuto nella richiesta originale del client più una password generica(“dummy”).

v La password “dummy” viene configurata nel file di configurazionewebseald.conf.

v Il registro del server back-end deve riconoscere l’identità Access Manager fornitanell’intestazione BA HTTP.

v Poiché attraverso il junction vengono trasmesse informazioni di autenticazionesensibili (nome utente e password), la sicurezza del junction è molto importante.Per questo motivo è fortemente consigliato un junction SSL.

LimitazioniLa stessa password Access Manager “fittizia” viene utilizzata per tutte le richieste;tutti gli utenti hanno la stessa password nel registro del server back-end. L’utilizzodella password “fittizia” comune non offre alcuna base al server di applicazioneper provare la legittimità del client che si collega con tale nome utente.

Se i client passano sempre attraverso WebSEAL per accedere al server back-end,questa soluzione non presenta alcun problema di sicurezza. Tuttavia, è importanteproteggere fisicamente il server back-end da altri possibili modi di accesso.

Poiché questo scenario non ha una protezione a livello di password, il serverback-end deve implicitamente affidarsi a WebSEAL per la verifica della legittimitàdel client.

Il registro del server back-end deve anche riconoscere l’identità Access Managerper poterla accettare.

Invio di informazioni sull’intestazione BA originale del client–b ignore

Client WebSEALnodo SSL

Webapplicazioni

Server

WebSEAL fornisce la passworde l’identità di Policy Director

qualsiasimeccanismo

di autenticazione

Registro Registro

Figura 40. Intestazione BA contenente identità e password ″dummy″

Capitolo 8. Soluzioni Web single sign-on 187

L’opzione –b ignore istruisce WebSEAL a trasmettere l’intestazione BA (BasicAuthentication) originale del client direttamente al server back-end, senzainterferenze. WebSEAL può essere configurato per autenticare queste informazioniBA del client oppure per ignorare l’intestazione BA fornita dal client e inoltrarla,senza alcuna modifica, al server back-end.

Nota: Questo non è un vero meccanismo single sign-on, ma un login diretto alserver di terzi, visibile a WebSEAL.

Per questa soluzione si verifica che:v Il server back-end richiede informazioni sull’identità del client via BA

Il server back-end invierà una richiesta di chiarimenti Basic Authentication alclient. Il client risponde con dati su nome utente e password che il serverWebSEAL inoltra senza modificarli.

v Il server back-end mantiene le proprie password personali fornite dal clientv WebSEAL viene configurato per fornire al server back-end il nome utente e la

password contenuti nella richiesta originale del client.v Poiché attraverso il junction vengono trasmesse informazioni di autenticazione

sensibili (nome utente e password), la sicurezza del junction è molto importante.Per questo motivo è fortemente consigliato un junction SSL.

Rimozione delle informazioni di intestazione BA del client–b filter

L’opzione –b filter specifica a WebSEAL di rimuovere tutte le informazionidell’intestazione Basic Authentication da qualsiasi richiesta client prima di inoltrarequeste ultime al server back-end. In questo scenario, WebSEAL diventa il soloprovider di protezione.

Per questa soluzione si verifica che:v L’autenticazione BA (Basic Authentication) è configurata tra il client e WebSEALv Il server back-end non richiede Basic Authenticationv Al server back-end è possibile accedere solo attraverso WebSEALv WebSEAL gestisce l’autenticazione per conto del server back-end

Client WebSEALnodo

Webapplicazioni

Server

WebSEAL fornisce le informazionioriginali (BA) sull’autenticazione

del client

Autenticazionedi base

Registro Registro

Figura 41. WebSEAL inoltra i dati di identità del client originali


Se è necessario fornire al server back-end alcune informazioni sul client, è possibilecombinare questa opzione con l’opzione –c in modo da inserire dati sull’identitàdel client Access Manager nei campi dell’intestazione HTTP. Consultare “Perfornire l’identità client nelle intestazioni HTTP (–c)” a pagina 170.

Specifica di nomi utente e password da GSO–b gso

L’opzione –b gso impone a WebSEAL di fornire al server back-end le informazionidi autenticazione (nome utente e password) ottenute da un server impostato per lagestione di GSO (global sign-on).

Per questa soluzione si verifica che:v Le applicazioni del server back-end richiedono diversi nomi utente e password

che non sono contenute nel registro WebSEAL.v La sicurezza è importante sia per WebSEAL sia per il server back-end.

Poiché attraverso il junction vengono trasmesse informazioni di autenticazionesensibili (nome utente e password), la sicurezza del junction è molto importante.Per questo motivo è fortemente consigliato un junction SSL.

Questo meccanismo viene descritto più dettagliatamente in “Utilizzo di GSO(global sign-on)”.

Utilizzo di GSO (global sign-on)Access Manager supporta una soluzione SSO flessibile che permette di fornirenomi utente e password alternativi al server di applicazioni Web back-end.

Il GSO (Global Sign-on) concede agli utenti l’accesso alle risorse di elaborazioneche questi sono autorizzati ad utilizzare, attraverso un singolo collegamento.Progettato per grosse aziende con più sistemi e applicazioni all’interno di ambientidi elaborazione distribuiti ed eterogenei, GSO elimina la necessità, da parte degliutenti finali, di gestire più nomi utente e password.

L’integrazione è stata raggiunta mediante la creazione di junction “GSO” traWebSEAL e i server Web back-end. Le risorse GSO e i gruppi di risorse GSOdevono per prima cosa essere creati mediante il gestore di portale Web oppuremediante il programma di utilità pdadmin.

Quando WebSEAL riceve una richiesta per una risorsa ubicata sul server dijunction, richiede al server del registro utenti le appropriate informazioni di

Client WebSEALWeb

ApplicazioniServer

NodoTCP o SSL

Autenticazionedi base

nessuna autenticazi onenecessar ia

WebSEAL rimuove le informazionioriginali sull’identità del client

dall’intestazione BA

Figura 42. Rimozione delle informazioni dall’intestazione BA del client


autenticazione. Il server del registro utenti contiene un database di associazioni —per ogni utente registrato — che fornisce nomi utente e password alternative perrisorse e applicazioni specifiche.

La seguente figura illustra il modo in cui il meccanismo GSO viene utilizzato perrecuperare nomi utente e password per risorse di applicazioni back-end.1. Il client effettua l’autenticazione presso WebSEAL con una richiesta di accesso

ad una risorsa di applicazione su un server back-end. Viene così ottenutaun’identità Access Manager.

Nota: Il processo di singolo collegamento (SSO) è indipendente dal metodo diautenticazione iniziale.

2. WebSEAL trasmette l’identità Access Manager al server del registro utenti.3. Il registro restituisce un nome utente e una password adatti all’utente e alla

risorsa di applicazione richiesta.4. WebSEAL inserisce i dati di nome utente e password nell’intestazione BA (Basic

Authentication) HTTP della richiesta che viene inviata attraverso il junction alserver back-end.

Associazione delle informazioni di autenticazioneIl seguente esempio illustra il modo in cui il registro utente fornisce informazionidi autenticazione a WebSEAL. Se l’utente Michael desidera eseguire la risorsa diapplicazione travel-app (fare riferimento a Figura 43), WebSEAL richiede al serverdel registro utenti le informazioni di autenticazione relative a Michael.

Il server del registro utenti mantiene un completo database di informazioni diautenticazione, sotto forma di associazioni di risorse a dati di autenticazionespecifici. I dati di autenticazione sono una combinazione nome utente / passwordconosciuta come credenziale di risorsa. Le credenziali di risorsa possono esserecreate solo per utenti registrati.

Il registro contiene un database per Michael che associa la risorsa travel-app allacredenziale di risorsa specifica.

nodi (-b gso)

WebSEAL

Client

Dominio protetto

Risorse:- accounts-app

- travel-app

HTTPSRisorse:

- expenses-app- payroll-app

HTTP

Host: sales_svr

Host: adm_svr

Il nodo SSL forni sce unacom unicazi one codi ficat a

/

/sales

/admin

Access ManagerIdentità

Nome utente /password

1

2

3

4

registro utenteServer

Figura 43. Meccanismo GSO (global sign-on)


La seguente tabella illustra la struttura del database di credenziali di risorse GSO:

Michael Paul

resource: travel-appusername=mikepassword=123

resource: travel-appusername=bundypassword=abc

resource: payroll-appusername=powellpassword=456

resource: payroll-appusername=jensenpassword=xyz

In questo esempio, il registro restituisce il nome utente “mike” e la password “123”a WebSEAL. WebSEAL utilizza queste informazioni quando crea l’intestazione BA(Basic Authentication) nella richiesta inviata attraverso il junction al serverback-end.

Configurazione di un junction WebSEAL abilitato per GSOIl supporto per GSO è configurato alla congiunzione tra WebSEAL e un serverback-end.

Per creare un junction che abiliti GSO, utilizzare il comando create con l’opzione–b gso. Il seguente esempio illustra la sintassi per il comando create:create –t tcp –h <nome-host> –b gso –T <risorsa> <punto-jct>

Le opzioni per l’impostazione di junction GSO sono elencate di seguito:

Opzioni Descrizione

–b gso Specifica che GSO deve fornire informazioni diautenticazione per tutte le richieste su questo junction.

–T <resource/resource-group> Specifica la risorsa o il gruppo di risorse GSO. Il nomedi risorsa utilizzato come argomento per questaopzione deve corrispondere esattamente al nome dirisorsa elencato nel database GSO. L’opzione èobbligatoria per junction gso.

Un junction utilizzato in una soluzione WebSEAL/GSO può essere protettomediante SSL applicando, in aggiunta, l’opzione –t ssl durante la creazione deljunction.

Si raccomanda di utilizzare sempre junction SSL con GSO per assicurare la codificadelle credenziali e di tutti i dati.

Esempi di junction WebSEAL abilitati per GSOPer congiungere la risorsa di applicazione: travel-app su host: sales_svr al punto dijunction /sales:create –t tcp –b gso –T travel-app –h sales_svr /sales

Per congiungere la risorsa di applicazione: payroll-app su host: adm_svr al puntodi junction /admin e rendere protetto il junction mediante SSL:create –t ssl –b gso –T payroll-app –h adm_svr /admin

Nota: Nell’esempio precedente, l’opzione –t ssl impone la porta predefinita 443.


Configurazione della cache GSOLa funzionalità della cache GSO (Global Sign-on) consente di migliorare leprestazioni dei junction GSO in un ambiente ad elevato carico di lavoro. Perimpostazione predefinita, la cache GSO è disabilitata. Senza il potenziamento dellacache, per ogni richiamo di informazioni di destinazione GSO (nome utente GSO epassword GSO), sarà richiesto un richiamo al server del registro utenti.

I parametri per la configurazione della cache GSO si trovano nella stanza[gso-cache] del file di configurazione webseald.conf. E’ prima necessario abilitarela cache. I rimanenti parametri configurano la dimensione della cache e i valori ditimeout per le voci della cache. Valori ampi per il timeout di inattività e per ladurata migliorano le prestazioni, ma aumentano il rischio di esposizione delleinformazioni nella memoria WebSEAL. Non abilitare la cache GSO se i junctionGSO non vengono utilizzati nella propria soluzione di rete.


gso-cache-enabled Per abilitare e disabilitare la funzionalità di cacheGSO. I valori comprendono “yes” e “no”. Ilvalore predefinito è “no”.

gso-cache-size Imposta il numero massimo di voci consentitenella tabella hash della cache. Impostare questovalore approssimativamente al numero di piccodi sessioni utente simultanee che accedono aun’applicazione su un junction GSO. Un valoreelevato utilizza una maggior quantità dimemoria ma permette un accesso più rapido alleinformazioni. Ogni voce della cache consumaapprossimativamente 50 byte.

gso-cache-entry-lifetime Tempo massimo (in secondi) che qualsiasi vocedella cache può essere conservata nella cachestessa, indipendentemente dall’attività. Quandouna voce di cache scade, la successiva richiestaeffettuata dallo stesso utente richiede un nuovorichiamo al server di registro utenti.

gso-cache-entry-idle-timeout Tempo massimo (in secondi) che una voceinattiva può essere conservata nella cache.

Configurazione SSO (single sign-on) per IBM WebSphere (LTPA)WebSEAL è in grado di fornire servizi di autenticazione e di autorizzazione,nonché protezione, a un ambiente IBM WebSphere. Quando WebSEAL èposizionato come server front-end di protezione nei confronti di WebSphere, iclient in accesso si trovano di fronte a due potenziali punti di login. Quindi,WebSEAL supporta una soluzione SSO (single sign-on) per uno o più server IBMWebSphere attraverso junction WebSEAL.

WebSphere fornisce un leggero meccanismo di autenticazione di terzi e basato sucookie (LTPA). E’ possibile configurare i junction WebSEAL per il supporto diLTPA e per la fornitura di una soluzione SSO per i client.

Quando un utente effettua la richiesta di una risorsa WebSphere, deve primaautenticarsi su WebSEAL; dopo una corretta autenticazione, WebSEAL genera uncookie LTPA per conto dell’utente. Il cookie LTPA, che serve come token diautenticazione per WebSphere, contiene l’identità dell’utente, i dati di token e di


chiave, la lunghezza buffer e i dati sulla scadenza. Queste informazioni sonocodificate mediante una chiave segreta protetta da password e condivisa traWebSEAL e il server WebSphere.

WebSEAL inserisce il cookie nell’intestazione HTTP della richiesta che viene inviataattraverso il junction a WebSphere. Il server back-end WebSphere riceve larichiesta, decodifica il cookie e autentica l’utente in base ai dati sull’identità fornitinel cookie.

Per migliorare le prestazioni, WebSEAL può memorizzare il cookie LTPA in unacache e utilizzarlo per successive richieste durante la stessa sessione utente. E’possibile configurare valori di timeout della durata e di timeout di inattività per ilcookie memorizzato nella cache.

Configurazione di un junction LTPAUn SSO (Single sign-on) con WebSphere attraverso un cookie LTPA richiede iseguenti elementi di configurazione:1. Abilitare il meccanismo LTPA.2. Fornire l’ubicazione del file di chiavi utilizzato per codificare i dati sull’identità.3. Fornire la password per tale file di chiavi.

Questi tre requisiti di configurazione vengono specificati in tre opzioni aggiuntivesul comando create del junction.v L’opzione –A abilita i cookie LPTA.v L’opzione e l’argomento –F <“file di chiavi”> specificano l’ubicazione del

percorso completo (sul server WebSEAL) del file di chiavi utilizzato percodificare i dati di identità contenuti nel cookie. La chiave condivisa viene inorigine creata sul server WebSphere e copiata con attenzione sul serverWebSEAL. Fare riferimento alla documentazione WebSphere appropriata per idettagli specifici riguardanti questa attività.

v L’opzione e l’argomento –Z <“password-file di chiavi”> specificano la passwordnecessaria per aprire il file di chiavi.La password appare come testo crittografato nel file XML del junction.

Utilizzare queste opzioni, in aggiunta alle altre opzioni di junction necessarie,quando si crea il junction tra WebSEAL e il server back-end WebSphere. Adesempio:create ... -A -F “/abc/xyz/key.file” -Z “abcdefg” ...

Configurazione della cache LTPALa creazione, la codifica e la decodifica di cookie LTPA determinano unsovraccarico dell’elaborazione. La funzionalità della cache LTPA consente dimigliorare le prestazioni dei junction LTPA in un ambiente ad elevato carico dilavoro. Senza il potenziamento della cache, per ogni successiva richiesta dell’utenteviene creato e codificato un nuovo cookie LTPA. Per impostazione predefinita, lacache LTPA è abilitata.

I parametri per la configurazione della cache LTPA sono ubicati nella stanza[ltpa-cache] del file di configurazione webseald.conf. I parametri specificano ladimensione della cache e i valori di timeout per le immissioni della cache. Valoriampi per il timeout di inattività e per la durata migliorano le prestazioni, maaumentano il rischio di esposizione delle informazioni nella memoria WebSEAL.



ltpa-cache-enabled Per abilitare e disabilitare la funzionalità di cacheLTPA. I valori comprendono “yes” e “no”. Ilvalore predefinito è “yes”.

ltpa-cache-size Imposta il numero massimo di voci consentitenella tabella hash della cache. Impostare questovalore approssimativamente al numero di piccodi sessioni utente simultanee che accedono aun’applicazione attraverso un junction LTPA. Unvalore elevato utilizza una maggior quantità dimemoria ma permette un accesso più rapido alleinformazioni. Ogni voce della cache consumaapprossimativamente 50 byte. Il valorepredefinito è di 4096 voci.

ltpa-cache-entry-lifetime Tempo massimo (in secondi) che qualsiasi vocedella cache può essere conservata nella cachestessa, indipendentemente dall’attività. Quandouna voce di cache scade, la successiva richiestaeffettuata dallo stesso utente richiede la creazionedi un nuovo cookie LTPA. Il valore predefinito èdi 3600 secondi.

ltpa-cache-entry-idle-timeout Tempo massimo (in secondi) che una voceinattiva può essere conservata nella cache. Ilvalore predefinito è di 600 secondi.

Note tecniche per single sign-on LTPAv Il file di chiavi contiene informazioni relative a uno specifico server WebSphere.

Un junction LTPA è specifico per un server WebSphere. Se si aggiungono altriserver allo stesso punto di junction, tutti i server condivideranno lo stesso file dichiavi.

v Per ottenere un SSO (single sign-on), WebSEAL e il server WebSphere devonocondividere le stesse informazioni di registro.

v Il server WebSphere è responsabile dell’impostazione di LTPA e della creazionedella chiave segreta condivisa. La partecipazione di WebSEAL comporta leconfigurazioni del junction e della cache.

Configurazione dell’autenticazione SSO (single sign-on) di moduliL’autenticazione SSO di moduli consente a WebSEAL di collegare in modotrasparente un utente autenticato Access Manager a un server di applicazioneback-end di junction che richiede l’autenticazione attraverso un modulo HTML.

Informazioni secondarie e obiettiviL’autenticazione SSO di moduli supporta applicazioni esistenti che utilizzanomoduli HTML per l’autenticazione e che non possono essere modificate perconsentire direttamente l’autenticazione eseguita da WebSEAL. L’abilitazionedell’autenticazione single sign-on dei moduli produce i seguenti risultati:v WebSEAL interrompe il processo di autenticazione iniziato dall’applicazione

back-endv WebSEAL fornisce i dati richiesti dal modulo di login e inoltra il modulo di

login per conto dell’utentev WebSEAL salva e ripristina tutti i cookie e le intestazioni


v L’utente è inconsapevole del secondo loginv L’applicazione back-end non sa che il modulo di login non proviene

direttamente dall’utente.

WebSEAL deve essere configurato per:v Riconoscere ed intercettare il modulo di loginv Riempire i dati di autenticazione appropriati

Il responsabile abilita il single sign-on di moduli:v Creando un file di configurazione per specificare il modo in cui il modulo di

login deve essere riconosciuto, completato ed elaboratov Abilitando il single sign-on di moduli mediante la configurazione del junction

adatto con l’opzione –S (che specifica l’ubicazione del file di configurazione)

Flusso del processo single sign-on di moduliIl seguente scenario presuppone che WebSEAL abbia già autenticato l’utente.

1. Il browser del client richiede la pagina:https://webseal/formsso/content.html

2. WebSEAL trasmette la richiesta al junction.3. Poiché l’applicazione back-end richiede l’autenticazione dell’utente, un

reindirizzamento alla pagina di login dell’applicazione (login.html) vieneinviato attraverso il junction.

4. WebSEAL trasmette il reindirizzamento al browser.5. Il browser segue il reindirizzamento e richiede:

https://webseal/formsso/login.html

Browserclient

WebSEALapplicazioniServer dellenodo -S

richiesta1 2

4

5 6

7

8

3

910

11 12

registrazione necessaria

reindirizzamento allapagina di registrazione

il browser segueil reindirizzamento

inizio di fsso;i cookie vengono

salvati

l’applicazione restituisceil modulo di registrazione

WebSEALcompleta il modulo

registrazione corretta;reindirizzamento alla richiesta

i cookie salvativengono ripristinati;

fine di fsso

il browser segueil reindirizzamento

l’applicazioneelabora la richiesta

Figura 44. Flusso del processo SSO di moduli


Nota: Tutto quanto riportato fino a questo punto nel flusso di processo faparte della funzionalità standard di WebSEAL.

6. WebSEAL è stato configurato per il single sign-on di moduli (opzione –S suljunction). WebSEAL riconosce la richiesta come richiesta di una pagina dilogin, basata sulle informazioni contenute nel file di configurazione SSO deimoduli. La richiesta viene trasmessa al junction. WebSEAL salva tutti i cookieinviati dal browser per utilizzarli nel passo 8.

7. L’applicazione restituisce la pagina di login e, eventualmente, cookie specificidell’applicazione.WebSEAL analizza l’HTML restituito per identificare il modulo di login.Quando WebSEAL trova un modulo HTML nel documento, confronta l’URI diazione del modulo al valore del parametro login-form-action presente nel filedi configurazione personale. Se esiste una corrispondenza, WebSEAL utilizza ilmodulo trovato. In caso contrario, WebSEAL effettua la ricerca di altri moduli.Se nessun modulo della pagina corrisponde al modello di URI di azione delfile di configurazione, WebSEAL interrompe l’elaborazione single sign-on deimoduli e restituisce un errore al browser.WebSEAL analizza la pagina HTML per identificare il metodo della richiesta,l’URI di azione e qualsiasi altro campo di immissione nel modulo, e salvaquesti elementi per utilizzarli nel passo 8.

8. WebSEAL genera la richiesta di autenticazione (completa il modulo di login) ela invia all’applicazione back-end.

9. L’applicazione effettua l’autenticazione utilizzando i dati di autenticazionebforniti da WebSEAL nel modulo. L’applicazione restituisce unreindirizzamento a content.html.

10. WebSEAL combina qualsiasi cookie salvato dalle risposte ai passi 7 e 9, erestituisce tali cookie al browser mediante il reindirizzamento.

Nota: Queste operazioni completano la funzionalità specifica per SSO deimoduli.

11. Il browser segue il reindirizzamento e richiede:https://webseal/formsso/content.html

12. WebSEAL trasmette la richiesta all’applicazione back-end attraverso iljunction.

Durante questo processo, il browser effettua tre richieste a WebSEAL. Dallaprospettiva dell’utente, viene effettuata una sola richiesta perhttps://webseal/formsso/content.html. Le altre richieste hanno luogoautomaticamente attraverso il reindirizzamento HTTP.

Requisiti per il supporto di applicazioniL’autenticazione SSO di moduli è supportata su applicazioni che rispondono aiseguenti requisiti:1. La pagina o le pagine di login per l’applicazione devono essere univocamente

identificabili attraverso una singola oppure varie espressioni regolari.2. La pagina di login può comprendere più di un modulo HTML. Tuttavia, il

modulo di login deve essere identificato applicando un’espressione regolareagli URI di azione di ciascuno dei moduli di login, oppure del modulo di loginche rappresenta il primo modulo nella pagina di login. Notare che, quando siutilizza l’attributo “action” per identificare il modulo di login, l’attributo“action” non è stato sottoposto al filtro HTML di WebSEAL. La corrispondenzadell’espressione regolare all’URI di azione dovrebbe avvenire prima del filtro.


3. La funzione di script del client può essere utilizzata per convalidare i dati diimmissione, ma non deve assolutamente modificarli. Questo include l’utilizzodi Javascript per impostare cookie nel browser dell’utente.

4. I dati di login vengono inoltrati in un solo momento del processo diautenticazione.

5. Il junction su cui la richiesta di autenticazione è diretta deve corrispondere aljunction su cui viene restituita la pagina di login.

Creazione del file di configurazione per SSO di moduliIl file di configurazione single sign-on di moduli è creato in modo personalizzatodal responsabile e salvato in una qualsiasi ubicazione. L’opzione –S sul junctionabilita la funzionalità SSO dei moduli e specifica l’ubicazione del file diconfigurazione. Consultare la sezione “Abilitazione del single sign-on di moduli” apagina 200. Un file di configurazione di esempio (contenente istruzionicommentate) viene fornito con l’installazione di WebSEAL ed è ubicato nellaseguente directory:

UNIX:/opt/pdweb/etc/fsso.conf.template

Windows:C:\Program Files\Tivoli\PDWeb\etc\fsso.conf.template

Il file di configurazione deve iniziare con la stanza [forms-sso-login-pages] e ha ilseguente formato:[forms-sso-login-pages]login-page-stanza = <xxxxx>#login-page-stanza = <aaaaa>#login-page-stanza = <bbbbb>

[<xxxxx>]login-page = <regular-expression-page-match>login-form-action = <regular-expression-form-match>gso-resource = <gso-target>argument-stanza = <yyyyy>

[<yyyyy>]<name> = <method>:<value>

Stanza [forms-sso-login-pages]Il file di configurazione single sign-on dei moduli deve sempre iniziare con lastanza [forms-sso-login-pages]. La stanza contiene una o più vocilogin-page-stanza che puntano ad altre stanze con nomi personalizzati contenentiinformazioni di configurazione per le pagine di login trovate sul server diapplicazione back-end.

La capacità di supportare pagine di login multiple su un singolo junction èimportante poiché un singolo server back-end potrebbe ospitare varie applicazioniognuna delle quali utilizza un metodo di autenticazione differente.

Ad esempio:[forms-sso-login-pages]login-page-stanza = loginpage1login-page-stanza = loginpage2


La stanza pagina di login personalizzataOgni stanza di pagina di login personalizzata viene utilizzata per intercettare unparticolare modello URL. La stanza può contenere i seguenti parametri:


login-page Questo parametro specifica un modello, mediante un’espressioneregolare, che identifica in modo univoco le richieste per la paginadi login di un’applicazione. WebSEAL intercetta queste pagine einizia il processo single sign-on dei moduli. L’espressione regolareviene confrontata all’URI di richiesta ed è correlata (ma non loinclude) al punto di junction in cui è allestito il server.

login-form-action Questo parametro specifica un modello, mediante un’espressioneregolare, che identifica quale tra i moduli contenuti nella paginaintercettata corrisponde al modulo di login dell’applicazione. Senella pagina è presente un solo modulo, oppure se il modulo dilogin è il primo del documento, l’espressione può essere “*”.Diversamente, l’espressione regolare deve corrispondereall’atributo “action” del modulo di login.

gso-resource Questo parametro specifica la risorsa GSO da utilizzare durante ilrecupero del nome utente e della password GSO da un databaseGSO. Lasciare in bianco questo parametro se GSO non è utilizzatoper memorizzare un nome utente e una password GSO.

argument-stanza Questo parametro punta ad un’altra stanza personalizzata cheelenca i campi e i dati richiesti per il completamento del modulo dilogin.

Ad esempio:[loginpage1]login-page = /cgi-bin/getloginpage*login-form-action = *gso-resource =argument-stanza = form1-data

Informazioni sul parametro login-page:

Il valore del parametro login-page è un’espressione regolare che WebSEAL utilizzaper determinare se una richiesta in arrivo è effettivamente una richiesta per unapagina di login. Se è così, WebSEAL intercetta tale richiesta e inizia l’elaborazionesingle sign-on dei moduli.

Un solo parametro login-page è consentito in ogni stanza di pagina di loginpersonalizzata. E’ necessario creare una stanza supplementare di pagina di loginpersonalizzata per ciascun parametro login-page aggiuntivo.

L’espressione regolare di login-page viene confrontata con l’URI di richiesta,correlato al junction. Nell’esempio seguente, l’URI di una richiesta a un serverWebSEAL denominato “websealA” per una risorsa su un junction denominato“junctionX” potrebbe apparire nel modo riportato:https://websealA.ibm.com/junctionX/auth/login.html

La parte di questo URL che viene confrontata con l’espressione regolare dilogin-page è:/auth/login.html

Informazioni sul parametro login-form-action:


Il parametro login-form-action viene utilizzato per identificare il modulo di loginsulla pagina intercettata. Un solo parametro login-form-action è consentito inciascuna stanza.

Il valore del parametro login-form-action è un’espressione regolare che vieneconfrontata con il contenuto dell’attributo “action” della tag HTML “form”.L’attributo “action” è un URI espresso come percorso correlato, correlato al servero assoluto. Il parametro login-form-action deve corrispondere a questo percorsocome se provenisse dal server back-end, anche se viene normalmente modificatoda WebSEAL prima di essere inoltrato al client.

Se più attributi “action” della pagina corrispondono all’espressione regolare, solo ilprimo viene accettato come modulo di login.

Se l’espressione regolare non corrisponde ad alcun modulo della pagina, albrowser viene restituito un errore riportante che non è possibile trovare il modulo.

E’ possibile impostare login-form-action = * per effettuare facilmente lacorrispondenza del modulo di login quando la pagina include un solo modulo dilogin.

Utilizzo di espressioni regolariLa seguente tabella elenca i caratteri speciali consentiti nelle espressioni regolariutilizzate nel file di configurazione SSO di moduli.

* Corrispondenza di zero o più caratteri

? Corrispondenza di uno qualsiasi dei caratteri

\ Carattere escape (ad esempio, \? corrisponde a ?)

[acd] Corrispondenza dei caratteri a, c, oppure d (sensibile almaiuscolo/minuscolo)

[^acd] Corrispondenza di qualsiasi carattere tranne a, c, oppure d(sensibile al maiuscolo/minuscolo)

[a-z] Corrispondenza di qualsiasi carattere tra a e z (lettere minuscole)

[^0-9] Corrispondenza di qualsiasi carattere non compreso tra 0 e 9 (nonun numero)

[a-zA-Z] Corrispondenza di qualsiasi carattere tra a e z (minuscolo) o A e Z(maiuscolo)

Nella maggior parte dei casi, i caratteri speciali non sono necessari poiché larichiesta della pagina di login è un singolo URI identificabile. In alcuni casi, èpossibile utilizzare il carattere “*” alla fine dell’espressione in modo che nessundato di query alla fine dell’URI impedisca la corrispondenza della pagina di login.

La stanza argumentLa stanza argument personalizzata contiene una o più voci nel seguente formato:<name> = <method>:<value>

name

Il valore del parametro name è impostato per equivalere al valore dell’attributo“name” della tag HTML “input”. Ad esempio:<input name=uid type=text>Nomeutente</input>


Questo parametro può anche utilizzare il valore dell’attributo “name “ delle tagHTML “select” o “textarea”.

method:value

Questa combinazione di parametri richiama i dati di autenticazione richiesti dalmodulo. I dati di autenticazione possono includere:v Dati di stringa letterale

stringa:<testo>

L’input utilizzato è la stringa di testo.v Nome utente e password GSO

gso:nomeutentegso:password

L’input è il nome utente e la password GSO dell’utente corrente (dalladestinazione specificata nella stanza di pagina di login personalizzata).

v Valore di un attributo nella credenziale dell’utentecred:<nome-attr-est-cred>

Per impostazione predefinita, la credenziale include dati quali il nome e il DNAccess Manager dell’utente. Per utilizzare il nome Access Manager dell’utentecome valore di input, specificare il valore come:cred:azn_cred_principal_name

Al DN dell’utente è possibile accedere come:cred:azn_cred_authzn_id

E’ anche possibile utilizzare attributi di credenziale personalizzati (aggiuntimediante il meccanismo tag/valore).

Non è necessario specificare campi di immissione nascosti in questa stanza. Talicampi vengono automaticamente recuperati dal modulo HTML e inoltrati con larichiesta di autenticazione.

Ad esempio:[form1-data]uid = string:brian

Abilitazione del single sign-on di moduliDopo aver completato il file di configurazione single sign-on di modulipersonalizzato ed aver localizzato il file in una directory appropriata, è necessarioconfigurare il junction adatto per supportare il single sign-on di moduli. Utilizzarel’opzione di junction –S con il comando pdadmin create:-S <config-file-path>

L’argomento config-file-path specifica l’ubicazione del file di configurazione singlesign-on di moduli personalizzato. L’opzione di junction –S abilita la funzionalitàsingle sign-on di moduli sul junction.

Ad esempio:pdadmin> server task webseald-<istanza> -t tcp -h websvrA \-S /opt/pdweb/fsso/fsso.conf /jctX


Il file di configurazione viene letto al momento della creazione del junction e ognivolta che WebSEAL viene avviato. Errori presenti nel file di configurazionepossono provocare il malfunzionamento di WebSEAL all’avvio.

File di configurazione di esempio per IBM HelpNowIl sito IBM HelpNow richiama il proprio login personale basato su moduli ecostituisce quindi un esempio di come una soluzione SSO di moduli possa offrireun accesso ininterrotto al sito per gli utenti iscritti.

Questa sezione contiene:v Una sezione di modulo, simile al modulo inviato sulla pagina di login HTML

restituita dall’applicazione HelpNowv Il file di configurazione single sign-on di moduli personalizzato utilizzato per

elaborare questo modulo

Il modulo trovato nella pagina HTML intercettata:<form name="confirm" method="post" action="../files/wcls_hnb_welcomePage2.cgi"><p>Employee Serial Number: <input name="data" size="10" maxlength="6"><p>Country Name:<select name="Cntselect" size="1"><OPTION value="notselected" selected>Seleziona il paese</OPTION><OPTION value=675>United Arab Emirates - IBM</OPTION><OPTION value=866>United Kingdom</OPTION><OPTION value=897>United States</OPTION><OPTION value=869>Uruguay</OPTION><OPTION value=871>Venezuela</OPTION><OPTION value=852>Vietnam</OPTION><OPTION value=707>Yugoslavia</OPTION><OPTION value=825>Zimbabwe</OPTION></select><p><input type=submit value=Submit></form>

Il file di configurazione personalizzato utilizzato per elaborare questo modulo:helpnow FSSO configuration:

[forms-sso-login-pages]login-page-stanza = helpnow

[helpnow]# Il sito HelpNow reindirizza l’utente a questa pagina# richiesta per il login.login-page = /bluebase/bin/files/wcls_hnb_welcomePage1.cgi

# Il modulo di login è il primo della pagina, quindi è possibile chiamarlo# ’*’.login-form-action = *

# La risorsa GSO, helpnow, contiene il numero seriale del dipendente.gso-resource = helpnow

# Seguono argomenti di autenticazione.argument-stanza = auth-data

[auth-data]# Il campo ’data’ contiene il numero seriale del dipendente.data = gso:username


# Il campo Cntselect contiene un numero corrispondente al# paese di origine del dipendente. La stringa “897” corrisponde agli Stati Uniti.Cntselect = string:897


Capitolo 9. Integrazione di applicazioni

WebSEAL supporta l’integrazione di applicazioni di terzi attraverso variabili diambiente e capacità di URL dinamici. WebSEAL estende la gamma di variabili diambiente e intestazioni HTTP per abilitare applicazioni di terzi all’esecuzione dioperazioni basate sull’identità di un client. Inoltre, WebSEAL è in grado di fornireil controllo dell’accesso su URL dinamici, quali quelli contenenti testo diinterrogazione.

Indice degli argomenti:v “Supporto della programmazione CGI” a pagina 203v “Supporto di applicazioni per il server back-end” a pagina 205v “Miglior utilizzo di junction per l’integrazione di applicazioni” a pagina 205v “Creazione di un servizio di personalizzazione privato” a pagina 207v “Abilitazione di concessioni dynamic business (tag/valore)” a pagina 209v “Mantenimento dello stato di sessione tra client e applicazioni back-end” a

pagina 211v “Controllo dell’accesso agli URL dinamici” a pagina 215v “Esempio di URL dinamico: Travel Kingdom” a pagina 221

Supporto della programmazione CGIPer supportare la programmazione CGI, WebSEAL aggiunge tre variabili diambiente supplementari alla serie di variabili CGI standard. Queste variabili diambiente possono essere utilizzate da applicazioni CGI in esecuzione sul serverWebSEAL locale oppure su un server back-end di junction. Le variabili fornisconoinformazioni specifiche di Access Manager per utente, gruppo e credenzialeall’applicazione CGI.

Su un server WebSEAL locale, queste variabili di ambiente sono automaticamentedisponibili ai programmi CGI.

Le variabili di ambiente utilizzate da un’applicazione CGI in esecuzione su unserver di junction di terzi vengono prodotte dalle informazioni dell’intestazioneHTTP trasmesse da WebSEAL al server. E’ necessario utilizzare l’opzione –c percreare un junction che supporta informazioni di intestazione specifiche per AccessManager nelle richieste HTTP destinate ad un server back-end.

Vedere anche “Per fornire l’identità client nelle intestazioni HTTP (–c)” apagina 170.

Ulteriori variabili di ambiente specifiche per Access Manager:

Variabili di ambiente CGI Descrizione

HTTP_IV_USER Il nome di account utente Access Manager del richiedente.

HTTP_IV_GROUPS I gruppi Access Manager ai quali appartiene il richiedente.Sono specificati in elenco di gruppi separati da virgole;ogni gruppo è racchiuso tra virgolette.


Variabili di ambiente CGI Descrizione

HTTP_IV_CREDS Struttura di dati non visibili codificati che rappresenta unacredenziale Access Manager. Fornisce le credenziali aiserver remoti in modo che le applicazioni mid-tier possanoutilizzare l’API di autorizzazione per richiamare il serviziodi autorizzazione. Fare riferimento a IBM Tivoli AccessManager Authorization C API Developer’s Reference.

Variabile REMOTE_USER su un server WebSEAL locale:

Su un ambiente di server locale controllato da WebSEAL, il valore della variabileHTTP_IV_USER elencata in precedenza viene fornito come valore per la variabilestandard REMOTE_USER. Notare che la variabile REMOTE_USER può ancheessere presente nell’ambiente di un’applicazione CGI in esecuzione su un serverback-end di junction. Tuttavia, in tale situazione, il relativo valore non è controllatoda WebSEAL.

Variabile di ambiente CGI Descrizione

REMOTE_USER Contiene lo stesso valore del campo HTTP_IV_USER.

Windows: Supporto di variabili di ambiente WIN32Questa sezione si applica esclusivamente a junction locali.

Windows non rende tutte le proprie variabili di ambiente di sistemaautomaticamente disponibili per processi quali le applicazioni CGI. Generalmente,sono presenti le variabili di ambiente di sistema necessarie.

In ogni caso, se le variabili di ambiente di sistema Windows necessarie non sonopresenti nell’ambiente CGI, è possibile renderle esplicitamente disponibili per iprogrammi CGI attraverso il file di configurazione webseald.conf. (Notare che levariabili di ambiente Access Manager menzionate nella precedente sezione sonoautomaticamente disponibili su tutte le piattaforme).

Aggiungere qualsiasi variabile di ambiente di sistema Windows richiesta allastanza [cgi-environment-variables] del file di configurazione webseald.conf.Utilizzare il seguente formato:ENV = <nome-variabile>

Ad esempio:[cgi-environment-variables]#ENV = SystemDriveENV = SystemRootENV = PATHENV = LANGENV = LC_ALLENV = LC_CTYPEENV = LC_MESSAGESENV = LOCPATHENV = NLSPATH

Tutte le righe non commentate vengono ereditate da un ambiente CGI.


Supporto di applicazioni per il server back-endWebSEAL fornisce anche il supporto per codice eseguibile che viene eseguito comecomponente incorporato di un server Web back-end. Gli esempi di tale codiceeseguibile per il server comprendono:v Servlet Javav Cartucce per listener web Oraclev Plug-in del server

Quando si crea un junction per un server back-end mediante l’opzione –c,WebSEAL inserisce informazioni sull’appartenenza al gruppo e sull’identitàdell’utente specifiche per Access Manager nelle intestazioni HTTP delle richiestedestinate a tale server.

Le informazioni delle intestazioni HTTP specifiche per Access Manager abilitano leapplicazioni presenti su server di junction di terzi all’esecuzione di azionispecifiche dell’utente in base all’identità Access Manager del client.

WebSEAL fornisce le seguenti intestazioni HTTP specifiche per Access Manager:

Campi di intestazione HTTPspecifici per PD

Descrizione

iv-user = Il nome lungo o abbreviato del client. Se il client non èautenticato (sconosciuto), il valore predefinito è “Nonautenticato”.

iv-groups = Un elenco di gruppi ai quali appartiene il client. Specificato comeelenco di gruppi tra virgolette separati da virgole.

iv-creds = Struttura di dati non visibili codificati che rappresenta unacredenziale Access Manager. Fornisce le credenziali ai serverremoti in modo che le applicazioni mid-tier possano utilizzarel’API di autorizzazione per richiamare il servizio diautorizzazione. Fare riferimento a IBM Tivoli Access ManagerAuthorization C API Developer’s Reference.

Queste intestazioni HTTP sono disponibili per applicazioni CGI come le variabilidi ambiente HTTP_IV_USER, HTTP_IV_GROUPS e HTTP_IV_CREDS. Per altrestrutture di applicazioni non CGI, fare riferimento alla rispettiva documentazioneper il prodotto associato per istruzioni sull’estrazione di intestazioni da richiesteHTTP.

Vedere anche “Per fornire l’identità client nelle intestazioni HTTP (–c)” apagina 170.

Miglior utilizzo di junction per l’integrazione di applicazioniQuesta sezione contiene consigli sul “miglior utilizzo” dei junction WebSEAL.v “Come fornire informazioni di intestazione HOST complete con -v” a pagina 206v “Supporto del filtro URL assoluto standard” a pagina 206

Capitolo 9. Integrazione di applicazioni 205

Come fornire informazioni di intestazione HOST complete con-v

Le configurazioni di host virtuale e le applicazioni di portale richiedonoinformazioni corrette sull’indirizzo IP per connessioni socket adatte e informazionicomplete sul nome server per un instradamento accurato.

Questi speciali servizi di applicazione back-end richiedono informazioni completesu nome server e designazione porta in qualsiasi richiesta proveniente da browser.L’intestazione HOST di una richiesta contiene tali informazioni e le rendedisponibili all’applicazione. Quando si utilizzano junction WebSEAL, questeinformazioni vengono fornite all’intestazione HOST attraverso l’utilizzodell’opzione di junction –v.

Informazioni insufficienti o mancanti relative al nome e alla porta del serverriducono le prestazioni della funzione di host virtuale e delle applicazioni diportale. Inoltre, i cookie di dominio impostati da queste applicazioni potrebberonon contenere informazioni sufficienti.

Per fornire le informazioni più complete all’intestazione HOST, le raccomandazionidi “miglior utilizzo” consistono nell’utilizzare sempre il nome di dominio completodel server di junction e il numero di porta di connessione nell’opzione –v durantela creazione o l’aggiunta del junction.

L’opzione –v utilizza la seguente sintassi:-v <nome-host-completo>[:<porta>]

Ad esempio:-v xyz.ibm.com:7001

Nota: La designazione della porta deve essere fornita solo se si sta utilizzando unnumero di porta non-standard.

Supporto del filtro URL assoluto standardWebSEAL, come proxy front-end inverso, fornisce servizi di sicurezza per server diapplicazioni back-end di junction. Le pagine restituite al client dalle applicazioniback-end molto spesso contengono collegamenti URL a risorse ubicate sul serverback-end di junction.

E’ importante che tali collegamenti includano il nome di junction per reindirizzarecorrettamente le richieste alle ubicazioni corrette delle risorse. WebSEAL utilizzauna serie di regole standard per filtrare URL statici e fornire queste informazioniper il junction. Una configurazione supplementare è richiesta per il filtro di URL inscript e in URL generati in modo dinamico. Per informazioni dettagliate sullafunzione di filtro URL, fare riferimento a “Modifica di URL a risorse di back-end”a pagina 162.

La capacità di WebSEAL di filtrare URL assoluti da pagine HTML statiche richiedela presenza di informazioni sul nome del server nell’opzione di junction –h. Questaopzione fornisce a WebSEAL il nome del server back-end di junction. Gliargomenti di questa opzione possono includere:v Nome di dominio completo del serverv Nome abbreviato del serverv Indirizzo IP del server


WebSEAL identifica URL assoluti da filtrare in base alla conoscenza del nome delserver back-end di junction. In base al proprio ambiente di rete, la configurazione–h <nome-abbreviato> potrebbe non fornire a WebSEAL le informazioni sufficienti.

Nell’esempio seguente viene creato un junction mediante l’opzione e l’argomentoseguenti per un server back-end, ubicato nella rete ibm.com, con un nomeabbreviato “xyz”:-h xyz

Un collegamento su una pagina HTML da questo server appare nel modoseguente:http://xyz.ibm.com/doc/release-notes.html

Quando questa pagina viene passata al client durante una richiesta, WebSEALpotrebbe non riuscire a filtrare tale URL poiché, in base alle informazioni fornite da–h, potrebbe non riconoscere “xyz.ibm.com” come nome del server. Senza il nomedi junction nel percorso, una richiesta per il documento release notes non ha esitopositivo.

Per supportare un’appropriata funzione di filtro di URL assoluti statici, leraccomandazioni per un “miglior utilizzo” consistono nell’utilizzare sempre ilnome di dominio completo del server di junction nell’opzione –h durante lacreazione o l’aggiunta del junction.

Creazione di un servizio di personalizzazione privatoUn portale Web portal, o pagina di avvio, è un servizio integrato del sito Web cheproduce dinamicamente un elenco personalizzato delle risorse Web disponibili perun utente specifico. Le risorse possono comprendere contenuto aziendale, servizi disupporto e strumenti per l’apprendimento. L’output del portale rappresenta unelenco personalizzato di risorse basato sulle autorizzazioni di accesso per unparticolare utente. La pagina di avvio visualizza solo le risorse che dispongonodelle autorizzazioni di accesso corrette per tale utente.

E’ possibile utilizzare le opzioni di configurazione WebSEAL e il servizio diconcessione di API di autorizzazione per creare una soluzione di portalepersonalizzato in un ambiente Access Manager.

Il flusso del processo per la creazione di un servizio di portale WebSEALpersonalizzato comprende le seguenti voci:1. Viene creata una specifica area dello spazio oggetti protetti in cui localizzare la

serie di oggetti risorse del portale.2. ACL espliciti appropriati vengono collegati a ciascuno di questi oggetti di

risorse.3. Il file di configurazione WebSEAL viene modificato per includere l’URL per il

servizio di portale, il percorso dello spazio oggetti contenente le risorse delportale e il bit di autorizzazione richiesto dall’utente per accedere a tali risorse.

4. Per ogni richiesta utente all’URL del portale, WebSEAL utilizza il Servizio diconcessione autorizzazioni per ricercare in questo spazio oggetti e produrre unelenco di risorse che corrispondono alle condizioni di autorizzazione relative atale utente.

5. WebSEAL inserisce queste informazioni in un’intestazione HTTP PD_PORTALche viene inviata al server back-end (di junction) del portale.


6. Il servizio di portale personalizzato (CGI o servlet) ubicato sul server back-endlegge il contenuto dell’intestazione PD_PORTAL e, ad esempio, associa ilcontenuto alle descrizioni e ai collegamenti URL che vengono visualizzatiall’utente su una pagina Web. Tali informazioni rappresentano l’elencopersonalizzato delle risorse disponibili per l’utente, in base alle autorizzazionisul controllo dell’accesso.

Configurazione di WebSEAL per un servizio dipersonalizzazione

1. Creare un nuovo junction WebSEAL per il servizio di personalizzazione. Adesempio:pdadmin> server task <nome-server> create -t tcp -h portalhost.abc.com \/portal-jct

2. Modificare il file di configurazione webseald.conf per aggiungere una nuovastanza [portal-map]:[portal-map]

3. La voce presente in questa stanza identifica l’URL, collegato al server, delprogramma di servizio del portale e l’area dello spazio oggetti in cui avviene laricerca di risorse di portale protette disponibili, seguita dall’autorizzazionenecessaria per l’accesso. Questo è l’elenco che viene inserito nell’intestazionePD_PORTAL.[portal-map]<URL> = <area-spazio-oggetti>:<autorizzazione>

Nota: Durante la ricerca vengono selezionati solo gli oggetti risorsa con ACLesplicitamente impostati contenenti la corrispondente autorizzazione pertale utente.

4. Dopo aver aggiunto la stanza e le voci di mapping appropriate, WebSEAL(webseald) deve essere riavviato.

Esempio di servizio di personalizzazionev Creare un junction per il server di portale:

pdadmin> server task webseald-WS1 -t ssl -h PORTAL1 /portal

v Definire l’area dello spazio oggetti protetti WebSEAL che contiene risorsedisponibili per il servizio di personalizzazione:pdadmin> objectspace create /Resources “Portal Object Hierarchy” 10pdadmin> object create /Resources/Content ““ 10 ispolicyattachable yespdadmin> object create /Resources/Support ““ 10 ispolicyattachable yespdadmin> object create /Resources/Content/CGI ““ 11 ispolicyattachable yespdadmin> object create /Resources/Support/Servlet ““ 11 ispolicyattachable yes

Nota: L’argomento “ispolicyattachable” deve essere impostato su “yes” per ognirisorsa. Il meccanismo di ricerca seleziona solo gli oggetti risorsaqualificati con ACL esplicitamente impostati.

v Configurazione WebSEAL (webseald.conf):[portal-map]/portal/servlet/PortalServlet = /Resources:r

v URL portale utilizzato dall’utente:https://WS1/portal/servlet/PortalServlet


Abilitazione di concessioni dynamic business (tag/valore)Le aziende commerciali e i propri partner hanno spesso la necessità di condividereconcessioni comuni quali dati del partner (in un rapporto tra aziende) o dati delcliente (in un rapporto azienda-cliente).v Le concessioni generiche sono attributi che descrivono le informazioni

necessarie alle applicazioni che forniscono il servizio. Esempi di tali attributiincludono informazioni sull’account del cliente e dati di fatturazione del cliente.

v Le concessioni di sicurezza sono attributi che forniscono condizioni più raffinateutilizzate per l’autorizzazione di richieste di risorse. Esempi di tali condizioniincludono ruoli commerciali dell’utente, limitazioni al controllo dell’accesso eregole aziendali che definiscono un accordo commerciale tra i partner.

Attraverso un’estensione del CDAS (Cross Domain Authentication Service), AccessManager fornisce un meccanismo flessibile che consente di includere informazionidi titolo nelle credenziali dell’utente al momento dell’autenticazione. Leapplicazioni possono estrarre questi dati direttamente dalla credenziale utilizzandol’API di autorizzazione. Per ulteriori informazioni sull’implementazione di questaestensione CDAS, fare riferimento al manuale IBM Tivoli Access Manager WebSEALDeveloper’s Reference.

Creazione di concessioni business da dati LDAPWebSEAL fornisce uno specifico meccanismo di concessione incorporato checonsente di inserire informazioni LDAP supplementari definite dall’utente nellacredenziale dell’utente sotto forma di dati di attributi estesi. I valori di questiattributi estesi della credenziale possono quindi essere inseriti nell’intestazioneHTTP di una richiesta inviata a un server di applicazioni back-end di junction.

Il seguente flusso di processo descrive la sequenza degli eventi:v I dati supplementari definiti dall’utente provenienti da qualsiasi campo di un

account di registro LDAP dell’utente vengono aggiunti come dati di attributiestesi nella credenziale Access Manager dell’utente.

v Il junction WebSEAL viene configurato per estrarre questi dati dalla credenzialee sistemarli in un’intestazione HTTP della richiesta da inviare al server back-end.

v Il server di applicazioni back-end può estrarre i dati dall’intestazione senzarichiedere codice speciale o API di autorizzazione.

La configurazione WebSEAL per l’inserimento di informazioni LDAPsupplementari nell’intestazione HTTP prevede due passi:1. Richiamo dei dati supplementari dal registro LDAP ed inserimento di tali dati

nella credenziale utente al login.2. In base a un insieme di attributi estesi sul junction (HTTP-Tag-Value),

estrazione dei dati appropriati dalla credenziale e inserimento di questinell’intestazione HTTP della richiesta da inviare sul junction.

Inserimento di dati LDAP supplementari in una credenzialeEsistono due metodi per inserire dati utente LDAP supplementari in unacredenziale:1. Creare voci nella stanza [ldap-ext-cred-tags] del file di configurazione pd.conf

che associano dati specifici LDAP agli attributi estesi nella credenziale.Questo metodo viene descritto nella presente sezione.

2. Scrivere un modulo CDAS personalizzato che associ qualsiasi dato definitodall’utente agli attributi estesi della credenziale.


Per informazioni sull’implementazione di questo CDAS, fare riferimento almanuale IBM Tivoli Access Manager WebSEAL Developer’s Reference.

La stanza [ldap-ext-cred-tags] del file di configurazione pd.conf viene utilizzataper associare dati specifici della classe oggetti LDAP inetOrgPerson a un attributoesteso definito dall’utente nella credenziale dell’utente. I parametri di questa stanzahanno il seguente formato:<cred-ext-attr-name> = <inetOrgPerson-name>

Nella stessa credenziale, ogni voce cred-ext-attr-name definita nel file diconfigurazione pd.conf è preceduta dalla frase “tagvalue_”. Questo prefissoimpedisce qualunque conflitto con altre informazioni presenti nella credenziale. Adesempio:

Nome e valore dallaclasse oggetti inetOrgPerson:

employeeNumber:09876

Il nome dell’attributo esteso della credenziale:ldap-employee-number

Associazione del nome attributo conil nome dati LDAP nellastanza [ldap-ext-cred-tags]:

ldap-employee-number = employeeNumber

Nome e valore attributo come appaiononella credenziale utente:

tagvalue_ldap-employee-number:09876

v Questa funzionalità richiede l’autenticazione utente attraverso un nome utente euna password LDAP. Il meccanismo di autenticazione passwd-ldap deve essereabilitato. La libreria condivisa libldapauthn (ldapauthn) è codificata in modo daricercare nella stanza [ldap-ext-cred-tags] del file di configurazione pd.conf leinformazioni supplementari per la credenziale definite dall’utente.

v I dati LDAP possono provenire da un campo standard o personalizzato dellaclasse oggetti inetOrgPerson.

v E’ possibile inserire voci multiple nella stanza [ldap-ext-cred-tags].v Tutti gli attributi estesi specificati nelle voci della stanza vengono inseriti nella

credenziale durante il login utente.v I nomi dei dati LDAP non sono sensibili al maiuscolo/minuscolo.v I nomi degli attributi estesi della credenziale sono sensibili al

maiuscolo/minuscolo.

Inserimento dei dati di credenziale nell’intestazione HTTPLe informazioni sulla credenziale definite dall’utente create nella precedentesezione possono essere inserite in un’intestazione HTTP della richiesta che vieneinviata attraverso un junction a un server back-end.

E’ necessario configurare il junction per estrarre i dati dell’attributo esteso dallacredenziale e inserirli nell’intestazione HTTP della richiesta. Questa funzionalitàavviene mediante l’impostazione di un attributo esteso di junction, denominatoHTTP-Tag-Value, sull’oggetto junction dello spazio oggetti protetti di WebSEAL.

Il comando pdadmin object modify set attribute viene utilizzato per impostareattributi estesi su un oggetto junction nello spazio oggetti protetti di WebSEAL.pdadmin> object modify <obj-name> set attribute <attr-name> <attr-value>

Un attributo esteso (“attr-name”) abilita il junction all’esecuzione di un tipospecifico di funzionalità. L’attributo esteso HTTP-Tag-Value istruisce il junction adestrarre un particolare valore dalla credenziale di un utente e invia tale valore al


server back-end in un’intestazione HTTP. Il valore dell’attributo estesoHTTP-Tag-Value utilizza il seguente formato:<cred-ext-attr-name>=<http-header-name>

La voce cred-ext-attr-name appare esattamente come nella stanza[ldap-ext-cred-tags] del file di configurazione pd.conf. Il prefisso “tagvalue_”, cheappare nella credenziale, non è utilizzato. La voce è sensibile almaiuscolo/minuscolo. La voce http-header-name specifica il nome dell’intestazioneHTTP utilizzata per la consegna dei dati sul junction.

Ad esempio:pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value ldap-employee-number=employee-id

Quando WebSEAL elabora una richiesta utente in un server di applicazioniback-end, ricerca qualsiasi attributo HTTP-Tag-Value configurato sull’oggettojunction.

In questo esempio, il junction configurato esamina la credenziale dell’utente cheeffettua la richiesta, estrae il valore dell’attributo esteso della credenzialetagvalue_ldap-employee-number e lo inserisce in un’intestazione HTTP come:employee-id:09876

Riepilogando:

Valore dell’attributo HTTP-Tag-Valueimpostato su un oggetto junction:

ldap-employee-number=employee-id


tagvalue_ldap-employee-number:09876

Nome e valore intestazione HTTP: employee-id:09876

Se l’applicazione back-end è un’applicazione CGI, la specifica CGI determina che leintestazioni HTTP vengano rese disponibili ai programmi CGI come variabili diambiente, nel formato:HTTP_<http-header-name>

Ad esempio:HTTP_employee-id=09876

Dati di attributo utente multipli possono essere trasmessi al server di junction inintestazioni HTTP utilizzando più comandi pdadmin object modify set attributeper specificare attributi di junction HTTP-Tag-Value multipli (viene specificato unattributo per comando).

Mantenimento dello stato di sessione tra client e applicazioni back-endWebSEAL può mantenere lo stato della sessione con client su HTTP e HTTPS. Inaggiunta, è possibile configurare WebSEAL per fornire indformazioni sulla sessioneutente ai server di applicazioni di junction back-end. Con queste informazioni sullasessione utente, le applicazioni back-end possono mantenere lo stato della sessionecon i client.


Informazioni secondarie per la gestione della sessione utenteUna connessione protetta, o una sessione, tra un client e un server richiede che ilserver abbia la capacità di ricordare, tra le numerose richieste, a chi è collegato. Ilserver deve disporre di alcune informazioni sullo stato della sessione cheidentificano il client associato a ciascuna richiesta.

Senza uno stato di sessione stabilito tra client e server, la comunicazione tra ilclient e il server deve essere rinegoziata per ogni richiesta successiva. Leinformazioni sullo stato della sessione migliorano le prestazioni eliminandochiusure e riaperture ripetute di connessioni client/server. Il client può collegarsiuna volta ed effettuare numerose richieste senza eseguire un separato login perciascuna richiesta.

WebSEAL mantiene le informazioni sullo stato della sessione attraverso la cache IDsessione SSL GSKit e la cache di sessione/credenziali WebSEAL. La cache disessione GSKit supporta comunicazioni HTTPS (SSL) quando l’ID sessione SSLviene utilizzato per mantenere lo stato della sessione. La cache di credenzialiWebSEAL memorizza un ID sessione WebSEAL per ogni client, oltre a qualsiasiinformazione di credenziale specifica per ogni client.

E’ possibile configurare WebSEAL in modo da memorizzare un unico ID sessioneutente per ogni client in autenticazione come attributo esteso nella credenziale diciascun client. Utilizzando attributi estesi per oggetti Access Manager, è possibileconfigurare un junction per fornire queste informazioni sull’ID sessione utente alserver back-end. Un’applicazione su questo server back-end può sfruttare leinformazioni per gestire l’interazione client-server, ad esempio la traccia delleattività degli utenti.

Abilitazione della gestione id sessione utenteIl parametro user-session-ids nella stanza [session] del file di configurazionewebseald.conf consente di abilitare e disabilitare la creazione di un ID sessioneutente unico nella credenziale di ogni client che effettua una richiesta. Il valorepredefinito è “yes” (abilitato):[session]user-session-ids = yes

L’ID sessione utente unico viene memorizzato nella credenziale di un utente comeattributo esteso con un nome e un valore:tagvalue_user_session_id = <user-session-id>

Nella stessa credenziale, il nome dell’attributo esteso (user_session_id) appare conun prefisso “tagvalue_” che impedisce ogni conflitto con altre informazionipresenti nella credenziale.

Il valore dell’ID sessione utente corrisponde a una stringa che identifica in modounivoco una sessione specifica per un utente autenticato. L’ID sessione utente èuna stringa codificata MIME-64 che include il nome dell’istanza WebSEAL (persupportare istanze WebSEAL multiple) e l’ID sessione WebSEAL standard perl’utente.

Un singolo utente che si collega in tempi diversi (ad esempio, da macchinedifferenti) ha ID sessione WebSEAL multipli. Poiché l’ID sessione utente si basasull’ID sessione WebSEAL, tra essi esiste un’associazione uno a uno. L’ID sessioneutente unico viene memorizzato nella credenziale dell’utente come attributo. Ciò


consente al valore di essere trasmesso su un junction come intestazione HTTP(mediante la funzionalità tag-value) ed essere disponibile per un’applicazioneback-end.

Inserimento dei dati di credenziale nell’intestazione HTTPLo scopo della gestione della sessione utente consiste nel fornire l’ID sessioneutente unico al server di applicazioni back-end. Questo obiettivo viene raggiuntomediante la configurazione dell’attributo esteso HTTP-Tag-Value sul junction.

Il comando pdadmin object modify set attribute viene utilizzato per impostare unattributo esteso su un oggetto junction nello spazio oggetti protetti di WebSEAL.pdadmin> object modify <obj-name> set attribute <attr-name> <attr-value>

Un attributo (“attr-name”) abilita il junction all’esecuzione di un tipo specifico difunzionalità. L’attributo HTTP-Tag-Value abilita il junction ad estrarre un valoreda un attributo esteso di credenziale e invia tale valore al server back-end inun’intestazione HTTP.

Il valore dell’attributo esteso HTTP-Tag-Value utilizza il seguente formato:<cred-ext-attr-name>=<http-header-name>

Per i dati di ID sessione utente, la voce cred-ext-attr-name indica il nomedell’attributo esteso user_session_id nella credenziale dell’utente. Il prefisso“tagvalue_”, che appare solo nella credenziale, non è utilizzato. La voce è sensibileal maiuscolo/minuscolo. Il valore di questo attributo esteso contiene l’ID sessioneutente unico.

La voce http-header-name specifica il nome dell’intestazione HTTP utilizzata per laconsegna dei dati sul junction. In questo esempio, viene utilizzata un’intestazionedenominata PD-USER-SESSION-ID:pdadmin> object modify /WebSEAL/WS1/junctionA set attribute \HTTP-Tag-Value user_session_id=PD-USER-SESSION-ID

Quando WebSEAL elabora una richiesta utente in un server di applicazioniback-end, ricerca qualsiasi attributo esteso HTTP-Tag-Value configuratosull’oggetto junction.

In questo esempio, il junction configurato esamina la credenziale dell’utente cheeffettua la richiesta, estrae il valore ID sessione utente dall’attributo estesotagvalue_user_session_id nella credenziale e lo inserisce in un’intestazione HTTPcome:PD-USER-SESSION-ID:<user-session-id>

Riepilogando:

Valore dell’attributo HTTP-Tag-Valueimpostato su un oggetto junction:

user_session_id=PD-USER-SESSION-ID


tagvalue_user_session_id:<user-session-id>

Nome e valore intestazione HTTP: PD-USER-SESSION-ID:<user-session-id>

Se l’applicazione back-end è un’applicazione CGI, la specifica CGI determina che leintestazioni HTTP vengano rese disponibili ai programmi CGI come variabili diambiente, nel formato:


HTTP_<HTTP-header-name>

Ad esempio:HTTP_PD-USER-SESSION-ID=<user-session-id>

Per ulteriori informazioni sulla funzionalità tag/value, fare riferimento a“Abilitazione di concessioni dynamic business (tag/valore)” a pagina 209.

Conclusione delle sessioni utenteUn utente può avviare la terminazione della sessione corrente attraverso ilcomando pkmslogout. In aggiunta, le informazioni contenute nell’ID sessioneutente consentono a responsabili e applicazioni back-end di eseguire la traccia e lagestione di utenti. Questa sezione descrive due metodi per terminare la sessioneutente a livello di responsabile:v “Utilizzo dell’API Administration per terminare le sessioni di un singolo utente”

a pagina 214v “Utilizzo di pdadmin per terminare tutte le sessioni utente” a pagina 214

Utilizzo dell’API Administration per terminare le sessioni di unsingolo utenteUn’applicazione back-end può utilizzare l’API Administration Access Manager perterminare una specifica sessione utente in base all’ID sessione utente trasmesso suljunction. L’applicazione richiama la funzione ivadmin_server_performtask()all’interno del proprio codice di terminazione. L’istanza del server WebSEAL e l’IDsessione utente sono inclusi come parametri di questa funzione.

WebSEAL verifica che il server back-end che inizia l’operazione di terminazioneabbia le autorizzazioni adatte prima di terminare la sessione utente.

Per ulteriori informazioni, fare riferimento al manuale IBM Tivoli Access ManagerAdministration C API Developer’s Reference.

Utilizzo di pdadmin per terminare tutte le sessioni utenteUn responsabile può utilizzare il programma di utilità pdadmin per terminaretutte le sessioni di un utente specifico in base all’ID utente.pdadmin> server task webseald-<nome-istanza> terminate all_sessions <id-utente>

La cache delle credenziali WebSEAL è organizzata per riferimenti incrociati di IDutente, ID sessione WebSEAL e informazioni della voce di cache. Un utentedispone sempre di un unico ID per più sessioni. Ogni ID sessione WebSEAL,tuttavia, è univoco. Il comando terminate all_sessions rimuove tutte le voci dicache che appartengono all’id-utente.


WebSEAL verifica la presenza delle autorizzazioni adatte per il responsabile cheinizia il comando prima di terminare le sessioni dell’utente.

Controllo dell’accesso agli URL dinamiciL’ambiente Web corrente consente agli utenti l’accesso immediato per la rapidamodifica delle informazioni. Molte applicazioni Web generano in modo dinamicoURL (Uniform Resource Locators) in risposta ad ogni richiesta dell’utente. TaliURL dinamici possono esistere solo per un breve periodo di tempo. Malgrado lanatura temporanea, gli URL dinamici necessitano comunque di una forteprotezione da utilizzi o accessi indesiderati.

Componenti URL dinamiciAlcuni sofisticati strumenti di applicazioni Web utilizzano browser Web standardper comunicare con i server di applicazioni attraverso l’interfaccia CGI di un serverWeb.

Tutti questi strumenti utilizzano URL dinamici e elementi nascosti di modulo percomunicare l’operazione richiesta (con il relativo valore di parametro) al server diapplicazioni. Un URL dinamico fornisce all’indirizzo dell’URL standard leinformazioni relative alla specifica operazione e i rispettivi valori di parametro. Laporzione della stringa di query dell’URL fornisce operazioni, parametri e valoriall’interfaccia applicativa Web.

ID utente ID sessione Dati cache

utenteA 1234credenziale più

attributo IDsessione utente

utenteB 5678credenziale più


utenteA 1369credenziale più


terminare tutte le sessioni dell’utenteA

Cache credenziali WebSEAL

Figura 45. Chiusura di tutte le sessioni dell’utente A


Associazione di oggetti ACL e POP a URL dinamiciWebSEAL utilizza il modello di spazio oggetti protetti, ACL (access control lists) ePOP (protected object policies) per proteggere URL generati dinamicamente, qualiquelli generati da richieste di database. Ogni richieste a WebSEAL viene risolta inuno specifico oggetto come primo passo del processo di autorizzazione. UnACL/POP applicato all’oggetto decide la protezione richiesta su ogni URLdinamico associato a tale oggetto.

Poiché gli URL dinamici esistono solo temporaneamente, non è possibile disporredi voci ad essi relative in un database di criteri di autorizzazione pre-configurato.Access Manager risolve questo problema fornendo un meccanismo in cui vari URLdinamici possono essere associati a un singolo oggetto protetto statico.

Le associazioni tra oggetti e modelli avvengono in un file plain text:/opt/pdweb/www/lib/dynurl.conf

L’ubicazione di questo file (relativa a server-root) viene definita dal parametrodynurl-map nella stanza [server] del file di configurazione webseald.conf:[server]dynurl-map = lib/dynurl.conf

E’ necessario creare questo file, che non è pre-esistente. La presenza di tale file (conle immissioni) abilita la funzione di URL dinamici.

Modificare il file per creare le associazioni adatte. Le voci del file hanno unformato:<oggetto> <maschera>

Access Manager utilizza un sottoinsieme di corrispondenza modello shell UNIX(comprendente caratteri globali) per definire la serie di parametri che costituisconoun oggetto nello spazio oggetti. Qualsiasi URL dinamico che corrisponde a taliparametri viene associato a tale oggetto.

Access Manager supporta i seguenti caratteri di corrispondenza modello per shellUNIX:

http://www.acm e.com /sales/ web/fortecgi .cgi?nam e= catalog&product = shi rt&color= red

Protocol lo ServerW eb

Percor so per ilprogram m a CG I

O perazi oni, param etri eval ori per l’interfacci adelle appl icazi oniW eb

File diprogram m a

CG I

URL di base Stri nga query

Figura 46. Trasmissione di dati ad un gateway CGI attraverso un URL


Carattere Descrizione

\ Il carattere che segue la barra retroversa fa parte di una specialesequenza. Ad esempio, \t rappresenta il carattere TAB. Può anchefunzionare come carattere escape.

? Carattere globale che corrisponde a un singolo carattere. Adesempio, la stringa “abcde” equivale all’espressione “ab?de”

* Carattere globale che corrisponde a zero o più caratteri.

[] Definisce un insieme di caratteri da cui è possibile effettuarequalsiasi corrispondenza. Ad esempio, la stringa “abcde” equivaleall’espressione regolare “ab[cty]de”.

^ Indica una negazione. Ad esempio, l’espressione [^ab] corrisponde aqualsiasi espressione che non abbia caratteri ‘a’ o ‘b’.

L’esempio seguente illustra il modulo di un URL dinamico che esegue un controllodel bilancio di credito:http://<server-name>/home-bank/owa/acct.bal?acc=<account-number>

L’oggetto che rappresenta questo URL dinamico dovrebbe apparire nel modoseguente:http://<server-name>/home-bank/owa/acct.bal?acc=*

Un attento esame dell’URL dinamico in questo esempio mostra che esso descriveuno specifico numero di account. L’oggetto per i bilanci di account su home-bankmostra che le autorizzazioni ACL e POP si applicano a qualsiasi account, poichél’ultima parte della voce (acc=*) utilizza il carattere globale asterisco checorrisponde a tutti i caratteri.

La figura seguente illustra uno scenario completo di uno specifico URL dinamicoassociato ad uno specifico oggetto protetto:

http://www.acm e.com /sales/ web/db.cgi?ser vice= Sof tW ear&catalog= cl othing&product = shi rt&color= red

www.acme.com/

db.cgi

web/

sales/

camiciarossa

Voci URL dinamico:

Spazio nome oggetti protetto

"*pr odot to= cam icia*col ore= rosso*”

Associa la stringa della query con la vocedello spazio nomi Web "camiciarossa”

...gruppo adm in -abc- --T-m ----lrxgruppo ABC _com pany -abc- --T-m ----lrxany_aut hent icat ed --------------unaut hent icat ed --------------...

ACL associato all’oggetto:"www.acme.com/sales/web/fortecgi.cgi/redshirt"

Figura 47. Autorizzazione su un URL dinamico


Aggiornamento di WebSEAL per URL dinamiciUtilizzare il comando dynurl update per aggiornare lo spazio oggetti protetti diWebSEAL con le immissioni effettuate nel file di configurazione dynurl.conf.1. Creare, modificare o eliminare una voce di URL dinamico nel file di

configurazione dynurl.conf.2. Dopo aver apportato le modifiche, utilizzare il comando dynurl update per

aggiornare il server:pdadmin> server task webseald-<nome-server> dynurl update

L’argomento nome-server rappresenta il nome host non qualificato dellamacchina WebSEAL.

Risoluzione di URL dinamici nello spazio oggettiLa risoluzione di un URL dinamico per un oggetto è dipendente dall’ordine dellevoci nel file di configurazione dynurl.conf.

Durante il tentativo di associare un URL dinamico a una voce di oggetto, l’elencodelle associazioni nel file dynurl.conf viene esaminato dall’alto verso il basso finoal rilevamento del primo modello di corrispondenza. Quando la primacorrispondenza viene rilevata, la voce di oggetto corrispondente viene utilizzataper la successiva verifica di autorizzazione.

Se nessuna corrispondenza viene rilevata, WebSEAL utilizza lo stesso URL, menola porzione http://<server> del percorso.

Mantenere nella parte alta dell’elenco le associazioni che corrispondono agli ACLpiù restrittivi. Ad esempio, se la procedura book.sales di un’applicazione di ordinedi vendita deve essere limitata ad un solo gruppo del club dei libri, ma al restodell’applicazione possono accedere tutti gli utenti, le associazioni devono averel’ordine riportato nella seguente tabella:

Voce spazio oggetti Maschera URL

/ows/sales/bksale /ows/db-apps/owa/book.sales*

/ows/sales/general /ows/db-apps/owa/*

Notare che, se le voci dell’associazione fossero in ordine inverso, tutte le procedurememorizzate nella directory /ows/db-apps/owa verrebbero associate all’oggetto/ows/sales/general. Ciò potrebbe portare a possibili riduzioni della sicurezza,dovute a tale risoluzione dello spazio oggetti non corretta.

Quando si associa un’espressione regolare URL a una voce di spazio oggetti, ilformato URL deve basarsi sul formato prodotto dal metodo GET,indipendentemente dall’utilizzo del metodo POST o GET.

Nel metodo GET di trasmissione dei dati, i dati dinamici (come quelli forniti da unutente in un modulo) vengono accodati all’URL.

Nel metodo POST di trasmissione dei dati, i dati dinamici sono inclusi nel corpodella richiesta.


Valutazione ACL e POPUna volta che l’URL dinamico è stato risolto in una voce dello spazio oggetti, ilmodello di eredità ACL/POP standard viene utilizzato per determinare se larichiesta deve essere elaborata oppure vietata (a causa di privilegi insufficienti).

Configurazione di limitazioni su richieste POSTIl contenuto di una richiesta POST è inserito nel corpo della richiesta. Inoltre, unarichiesta POST contiene la lunghezza, determinata dal browser, di questo contenutoed elenca il valore in byte.

request-body-max-read

Il parametro request-body-max-read nella stanza [server] del file di configurazionewebseald.conf limita l’impatto di grandi richieste POST su WebSEAL mediante laspecifica del numero massimo di byte da leggere come contenuto dal corpo dellerichieste POST. Il contenuto letto da WebSEAL è soggetto a controlli diautorizzazione, come descritto precedentemente in questa sezione.

Il valore del parametro request-body-max-read viene considerato quando larichiesta POST viene utilizzata per l’elaborazione di URL dinamici o perl’autenticazione Moduli. Il valore predefinito è 4096 byte:[server]request-body-max-read = 4096

Notare che questo parametro non limita la dimensione massima del contenutoPOST (che è illimitata). Il parametro protegge WebSEAL dall’elaborazione dirichieste POST di dimensioni irragionevoli.

dynurl-allow-large-posts

Sebbene il parametro request-body-max-read limiti la quantità del contenuto POSTletto ed elaborato da WebSEAL, non impedisce alla richiesta, nella sua interezza, dipassare attraverso il server di applicazioni. In questo scenario, un contenuto nonconvalidato viene trasmesso al server di applicazioni. Se quest’ultimo non disponedi proprie capacità di autorizzazione, la situazione potrebbe provocare un rischioper la sicurezza.

Il parametro dynurl-allow-large-posts consente all’utente di controllare il modo incui WebSEAL gestisce le richieste POST con un contenuto di lunghezza maggiorerispetto a quella specificata da request-body-max-read. Se il valore del parametro èimpostato su “no” (predefinito), WebSEAL rifiuta completamente qualsiasi richiestaPOST con un contenuto di lunghezza superiore a quanto specificato darequest-body-max-read.[server]dynurl-allow-large-posts = no

Se il valore del parametro è impostato su “yes”, WebSEAL accetta l’intera richiestaPOST, ma convalida solo la quantità di contenuto equivalente al valore direquest-body-max-read.[server]dynurl-allow-large-posts = yes

Esempio 1:

v Viene ricevuta una richiesta POST grande (maggiore del valore direquest-body-max-read).


v dynurl-allow-large-posts = no

v Gli URL dinamici sono abilitati.v Risultato: 500 “Errore del server”

Esempio 2:

v Viene ricevuta una richiesta POST grande (maggiore di post-request-body-max-read).

v dynurl-allow-large-posts = yes

v Gli URL dinamici sono abilitati.v Risultato: WebSEAL confronta la quantità di contenuto fino a

request-body-max-read con ognuna delle espressioni regolari presenti nel file diconfigurazione dynurl.conf, ed esegue una verifica di autorizzazione sulcorrispondente oggetto, se viene rilevata una corrispondenza. Diversamente, laverifica di autorizzazione viene eseguita sull’oggetto corrispondente all’URLricevuto, come di consueto. La parte del corpo della richiesta che eccederequest-body-max-read non viene convalidata.

v La seguente maschera contiene il tipo di disposizione di corrispondenza modelloche determina l’uso improprio da parte di una richiesta POST grande:/rtpi153/webapp/examples/HitCount\?*action=reset*

Riepilogo e note tecnicheRiepilogo:

v Per configurare WebSEAL per la gestione di URL dinamici in modo protetto,creare il seguente file:/opt/pdweb/www/lib/dynurl.conf

v Il file deve contenere una o più linee di formato:<oggetto> <maschera>

v Se il file non esiste, oppure se è vuoto, la capacità di URL dinamici non èabilitata.

v Dopo l’elaborazione del file, il nome oggetto appare come risorsa secondarianello spazio oggetti WebSEAL.

v La maschera può contenere un sottoinsieme dei caratteri di corrispondenza delmodello standard. La maschera può anche corrispondere a una stringa esattasenza caratteri di corrispondenza del modello.

Il seguente file di esempio, dynurl.conf, definisce tre oggetti rappresentanti alcunedelle applicazioni Web di esempio che fanno parte del prodotto IBM WebSphere:

Voce di oggetto Maschera URL

/app_showconfig /rtpi153/webapp/examples/ShowConfig*

/app_snoop /rtpi153/servlet/snoop

/app_snoop /rtpi025/servlet/snoop

/app_hitcount/ejb /rtpi153/webapp/examples/HitCount\?source=EJB

/app_hitcount /rtpi153/webapp/examples/HitCount*

Note tecniche:

v Le maschere URL multiple URL possono essere associate allo stesso oggetto (adesempio, app_snoop si associa a URL su due differenti server).


v Gli oggetti possono essere nidificati (ad esempio, app_hitcount eapp_hitcount/ejb).

v Una richiesta URL in arrivo viene confrontata con le maschere, dall’alto verso ilbasso. Quando viene rilevata una corrispondenza, l’elaborazione si interrompe.Quindi, inserire le maschere maggiormente restrittive nella parte alta del file.

v Per attivare le definizioni nel file dynurl.conf, immettere il comando dynurlupdate (utilizzare pdadmin server task).L’aggiornamento si verifica immediatamente e gli oggetti appaiono nel gestoredi portale Web quando si aggiorna la visualizzazione dello spazio oggettiprotetti.

v Evitare l’uso di caratteri maiuscoli nel nome oggetto. Utilizzare solo caratteriminuscoli.

v Non utilizzare un nome oggetto già esistente nello spazio oggetti protetti.v Prima di eliminare un oggetto dal file dynurl.conf, rimuovere qualsiasi ACL ad

esso collegato.

Esempio di URL dinamico: Travel KingdomL’esempio seguente illustra il modo in cui una rete intranet aziendale puòproteggere URL generati da un listener Web Oracle.

Il server Web di URL dinamici utilizzato in questo esempio è il listener WebOracle. Questa tecnologia può essere ugualmente applicata ad altri server Web diURL dinamici.

L’applicazioneLa Travel Kingdom è un’organizzazione che offre ai propri clienti un servizio diprenotazione viaggi attraverso Internet. L’azienda intende mettere in opera dueapplicazioni di database Oracle sul proprio server Web, accessibile dall’interno delfirewall aziendale e da Internet.1. Sistema di prenotazione viaggi

I clienti autorizzati possono effettuare prenotazioni in remoto ed eseguireinterrogazioni di queste ultime. Lo staff della Travel Kingdom può ancheeffettuare prenotazioni per clienti via telefono, elaborare le modifiche edeseguire molte altre transazioni. Poiché i clienti esterni pagano i servizimediante carta di credito, la trasmissione di tali informazioni deve esserealtamente protetta.

2. Responsabile di amministrazione

Come la maggior parte delle aziende, la Travel Kingdom mantiene un databasedi amministrazione contenente informazioni sui salari, sulle posizioni e sulleesperienze. Questi dati sono accompagnati da una foto di ciascun membro dellostaff.

L’interfacciaUn server Web Oracle è configurato per fornire l’accesso alle seguenti procedurememorizzate del database:

/db-apps/owa/tr.browse Offre a tutti gli utenti la possibilità di effettuareinterrogazioni su destinazioni, tariffe, etc.

/db-apps/owa/tr.book Utilizzata per inserire una prenotazione (staffdell’agente di viaggi o clienti autenticati).


/db-apps/owa/tr.change Utilizzata per rivedere o modificare le prenotazionicorrenti.

/db-apps/owa/admin.browse Utilizzata da qualsiasi membro dello staff pervisualizzare informazioni non limitate sullo staff, adesempio, numero di estensione, indirizzo email efoto.

/db-apps/owa/admin.resume Offre a un membro dello staff la possibilità divisualizzare o modificare le proprie informazioniriassuntive nel database di Amministrazione.

/db-apps/owa/admin.update Utilizzata dallo staff di amministrazione peraggiornare le informazioni sul personale.

Struttura dello spazio WebUn server WebSEAL viene utilizzato per fornire un’interfaccia protetta allo spazioWeb unificato della Travel Kingdom.v Viene effettuato un junction (/ows) al server Web Oracle su cui sono in

esecuzione sia l’applicazione di prenotazione viaggi, sia l’applicazione diamministrazione.

Il criterio di protezionePer fornire un’opportuna protezione alle risorse Web e, contemporaneamente,conservare una facilità di utilizzo del sistema, la direzione commerciale ha stabilitoi seguenti obiettivi di sicurezza:1. Lo staff dell’agente di viaggi ha un controllo completo su tutte le prenotazioni.2. I clienti autenticati possono effettuare e modificare le proprie prenotazioni, ma

non possono interferire con le informazioni di viaggio di altri clienti autenticati.3. Lo staff di amministrazione ha accesso completo a tutti i dati di

amministrazione.4. Lo staff Travel Kingdom che non rientra nel reparto amministrativo può

modificare i propri dati riassuntivi e visualizzare parzialmente i dati di altrimembri dello staff.

Associazioni tra URL dinamico e spazio oggettiPer ottenere i risultati descritti in precedenza, le associazioni tra URL dinamici evoci di oggetto ACL devono essere configurate come riportato nella tabellaseguente.

Ricordare che l’ordine di queste associazioni è fondamentale per raggiungere gliobiettivi di sicurezza trattati.

Voce spazio oggetti Modello URL

/ows/tr/browse /ows/db-apps/owa/tr.browse\?dest=*&date=??/??/????

/ows/tr/auth /ows/db-apps/owa/tr.book\?dest=*&depart=??/??/????& return=??/??/????

/ows/tr/auth /ows/db-apps/owa/tr.change

/ows/admin/forall /ows/db-apps/owa/admin.resume

/ows/admin/forall /ows/db-apps/owa/admin.browse\?empid=[th]???

/ows/admin/auth /ows/db-apps/owa/admin.update\?empid=????


Client protettiIl client effettua l’autenticazione con WebSEAL su un canale crittografato eprotetto.

I clienti che intendono utilizzare l’interfaccia Web devono inoltre registrarsi con ilTravel Kingdom Webmaster per ricevere un account.

Struttura di gruppi e accountSul sistema vengono creati quattro gruppi:

Staff Membri dell’organizzazione Travel Kingdom.

TKStaff Agenti di viaggi della Travel Kingdom.

AdminStaff Membri del reparto Amministrazione della Travel Kingdom.Notare che i membri dello staff Amministrazione fanno parte anchedel gruppo Staff.

Clienti Clienti della Travel Kingdom che intendono effettuare le proprieprenotazioni su Internet.

Ad ogni utente viene attribuito un account nel dominio protetto in modo che possaessere singolarmente identificato dal server WebSEAL. L’identità dell’utente vieneanche trasmessa ai server Web Oracle per fornire una soluzione SSO (singlesign-on) a tutte le risorse Web.

Controllo dell’accessoLa seguente tabella elenca i controlli di accesso risultanti dall’applicazione delleprecedenti informazioni:

/ows/tr/browse unauthenticated Trany_authenticated Tr

/ows/tr/auth unauthenticated -any_authenticated -group TKStaff Trgroup Customer PTr

/ows/admin/forall unauthenticated -any_authenticated -group Staff Tr

/ows/admin/auth unauthenticated -any_authenticated -group AdminStaff Tr

I gruppi Clienti e TKStaff hanno gli stessi privilegi sugli oggetti di conservazionedel piano di viaggio e prenotazione, ad eccezione del fatto che i clienti devonocrittografare i dati (autorizzazione privacy) per dare maggior protezione agli stessiquando si inviano dati sensibili (ad esempio, i dati della carta di credito) suInternet.

ConclusioneQuesto semplice esempio illustra i concetti di distribuzione di un sistema in gradodi:v Proteggere dati sensibiliv Autenticare utentiv Autorizzare l’accesso a dati sensibili


Inoltre, le identità degli utenti autenticati del sistema sono conosciute sia dal serverWebSEAL che dal server Oracle, e vengono utilizzate per fornire una soluzioneSSO.


Appendice A. Riferimento webseald.conf

File di configurazione webseald.conf

Categorie e stanze:v WEBSEAL GENERALE

[server]v LDAP

[ldap]v ACTIVE DIRECTORY

[uraf-ad]v DOMINO

[uraf-domino]v SSL

[ssl]v JUNCTION

[junction][filter-url][filter-schemes][filter-content-types][script-filtering][gso-cache][ltpa-cache]

v AUTENTICAZIONE[ba][forms][token][certificate][http-headers][auth-headers][ipaddr][authentication-levels][mpa][cdsso][cdsso-peers][failover][e-community-sso][inter-domain-keys][reauthentication][authentication-mechanisms][ssl-qop][ssl-qop-mgmt-hosts][ssl-qop-mgmt-networks]


[ssl-qop-mgmt-default]v SESSIONE

[session]v CONTENUTO

[content][acnt-mgt][cgi][cgi-types][cgi-environment-variables][content-index-icons][icons][content-cache][content-mime-types][content-encodings]

v LOGGING[logging]

v API DI AUTORIZZAZIONE[aznapi-configuration][aznapi-entitlement-services]

v POLICY DIRECTOR[policy-director]

WEBSEAL GENERALE


stanza [server]

SISTEMA

unix-user Account utente UNIX per il server WebSEAL.

unix-group Account gruppo UNIX per il server WebSEAL.

unix-pid-file Ubicazione del file PID.

server-root Directory principale del server WebSEAL.

server-name Nome dell’istanza server WebSEAL.

THREAD E CONNESSIONI

worker-threads Numero di thread di processo WebSEAL.

client-connect-timeout Timeout di connessione client iniziale.

persistent-con-timeout Timeout di connessione permanente HTTP/1.1.

CLIENT HTTPS

https Consentire accesso HTTPS.

https-port Porta da utilizzare per richieste HTTPS protette.

CLIENT HTTP

http Consentire accesso HTTP (TCP) non protetto.

http-port Porta da utilizzare per richieste HTTP non protette.

CORPI RICHIESTA E CACHING

request-body-max-read Numero massimo di byte da leggere come contenutodal corpo di richieste POST.


WEBSEAL GENERALE


request-max-cache Quantità massima di dati memorizzati nella cacheper richiesta.

DYNURL

dynurl-map Ubicazione del file di mapping URL-oggettoprotetto.

dynurl-allow-large-posts Limita la capacità di WebSEAL di leggere richiestePOST più grandi di quanto specificato dapost-max-read.

GESTIONE URI

utf8-url-support-enabled Controlla il modo in cui WebSEAL interpreta gliURL inviati da browser.

SOPPRESSIONE IDENTITA’ SERVER

suppress-server-identity Elimina l’identità del server WebSEAL nelle rispostedel server HTTP.

LDAP


stanza [ldap]

ldap-server-config Ubicazione del file di configurazione ldap.conf(impostato durante la configurazione).

cache-enabled Abilita e disabilita la cache LDAP locale.

prefer-readwrite-server Consente la selezione di server LDAP scrivibili,quando disponibile.

auth-using-compare Consente verifiche di autenticazione più rapideutilizzando una operazione di confronto passwordanziché un bind LDAP.

default-policy-override-support Verifica il criterio predefinito oppure il criteriospecifico dell’utente.

user-and-group-in-same-suffix Ricerca nelle prestazioni. Indica i gruppi definitinello stesso suffisso LDAP dell’utente.

ssl-enabled Abilita e disabilita SSL per la comunicazioneWebSEAL-LDAP.

ssl-keyfile Ubicazione del file di chiavi SSL.

ssl-keyfile-dn L’etichetta del certificato nel file di chiavi SSL, sepresente.

ssl-keyfile-pwd Password per il file di chiavi SSL.

bind-dn Il nome particolare (Distinguished Name) deldaemon WebSEAL (impostato durante laconfigurazione).

bind-pwd La password per il daemon WebSEAL (impostatadurante la configurazione).

ACTIVE DIRECTORY


stanza [uraf-ad]

Appendice A. Riferimento webseald.conf 227

ACTIVE DIRECTORY


ad-server-config Ubicazione del file di configurazione ActiveDirectory (impostato durante la configurazione).

bind-id Identità per il server corrente.

bind-pwd Password per il server corrente.

DOMINO


stanza [uraf-domino]

domino-server-config Ubicazione del file di configurazione Domino(impostato durante la configurazione).

bind-id Identità per il server corrente.

bind-pwd Password per il server corrente.

SSL


stanza [ssl]

webseal-cert-keyfile Ubicazione del file di chiavi contenente il certificatodel server inviato ai browser da WebSEAL durantela negoziazione di sessioni SSL.

webseal-cert-keyfile-pwd Password di chiave privata del certificato WebSEAL.

webseal-cert-keyfile-stash Ubicazione del file di password della chiave privataWebSEAL.

webseal-cert-keyfile-label Nome del certificato WebSEAL da utilizzare diversodal predefinito.

ssl-keyfile Ubicazione del file di chiavi del certificato WebSEALutilizzato per comunicazioni interne.

ssl-keyfile-pwd Password di chiave privata del certificato WebSEAL(per comunicazioni interne).

ssl-keyfile-stash Ubicazione del file di password della chiave privataWebSEAL (per comunicazioni interne).

ssl-keyfile-label Nome del certificato da utilizzare diverso dalpredefinito (per comunicazioni interne).

disable-ssl-v2 Per disabilitare in modo selettivo il supporto SSL V2.

disable-ssl-v3 Per disabilitare in modo selettivo il supporto SSL V3.

disable-tls-v1 Per disabilitare in modo selettivo il supporto TLSV1.

ssl-v2-timeout Timeout ID sessione della cache GSKit perconnessioni SSL V2.

ssl-v3-timeout Timeout ID sessione della cache GSKit perconnessioni SSL V3.

ssl-max-entries Numero massimo di immissioni simultanee nellacache ID sessione SSL GSKit.

gsk-crl-cache-size Configurazione della cache CRL. Numero massimodi immissioni nella cache CRL GSKit.


SSL


gsk-crl-cache-entry-lifetime Configurazione della cache CRL. Timeout del ciclodi vita per immissioni singole nella cache CRLGSKit.

ssl-ldap-server Server LDAP utilizzato per il controllo CRL.

ssl-ldap-server-port Numero di porta su cui questo server LDAP è inascolto per il controllo CRL.

ssl-ldap-user Utente responsabile per il server LDAP.

ssl-ldap-user-password Password dell’utente responsabile per il serverLDAP.

JUNCTION


stanza [junction]

junction-db Ubicazione del database junction.

jmt-map Ubicazione della tabella di mappingjunction-richiesta (JMT).

http-timeout Timeout per invio a/lettura da un junction basatosu TCP.

https-timeout Timeout per invio a/lettura da un junction basatosu SSL.

ping-time Intervallo per la routine di ping per serverWebSEAL-junction.

basicauth-dummy-passwd Password globale per la specifica di dati diautenticazione di base su junction “-b supply”.

worker-thread-hard-limit Percentuale di tutti i thread di processo cheelaborano richieste per un particolare junction.

worker-thread-soft-limit Percentuale di tutti i thread di processo cheelaborano richieste per un particolare junction.

io-buffer-size Dimensione del buffer per lettura/scrittura in unjunction.

max-webseal-header-size Dimensione massima, in byte, delle intestazioniHTTP generate da WebSEAL.

FILTRO DOCUMENTI

stanza [filter-url]

<tag> = <attribute> Attributi URL che WebSEAL filtra nelle risposteprovenienti da server di junction.

stanza [filter-schemes]

scheme = <scheme-name> Elenco degli schemi URL che WebSEAL filtra nellerisposte provenienti da server di junction.

stanza [filter-content-types]

type = text/html> Tipo di contenuto del documento che WebSEALfiltra nelle risposte provenienti da server dijunction.

type = text/vnd.wap.wml Tipo di contenuto del documento che WebSEALfiltra nelle risposte provenienti da server dijunction.


JUNCTION


stanza [script-filtering]

script-filter Abilita e disabilita il filtro di URL assoluti dascript su server di junction.

CACHE GSO

stanza [gso-cache]

gso-cache-enabled Abilita e disabilita la cache GSO.

gso-cache-size Numero di immissioni nella cache GSO.

gso-cache-entry-lifetime Durata massima di un’immissione nella cacheGSO.

gso-cache-entry-idle-timeout Durata massima di un’immissione inattiva nellacache GSO.

CACHE LTPA

stanza [ltpa-cache]

ltpa-cache-enabled Abilita e disabilita la cache LTPA.

ltpa-cache-size Numero di immissioni nella cache LTPA.

ltpa-cache-entry-lifetime Durata massima di un’immissione nella cacheLTPA.

ltpa-cache-entry-idle-timeout Durata massima di un’immissione inattiva nellacache LTAPA.

AUTENTICAZIONE


AUTENTICAZIONE DI BASE

stanza [ba]

ba-auth Abilita e disabilita il meccanismo BasicAuthentication.

basic-auth-realm Nome realm visualizzato nel prompt di login BA delbrowser.

MODULI

stanza [forms]

forms-auth Abilita e disabilita l’autenticazione mediante Moduli.

TOKEN

stanza [token]

token-auth Abilita e disabilita l’autenticazione mediante codicidi accesso token.

CERTIFICATO

stanza [certificate]

accept-client-certs Configura la gestione di certificati WebSEAL delclient.

INTESTAZIONI HTTP

stanza [http-headers]

http-headers-auth Abilita e disabilita l’autenticazione medianteintestazioni HTTP.


AUTENTICAZIONE


stanza [auth-headers]

header Specifica le intestazioni HTTP utilizzate perl’autenticazione.

INDIRIZZO IP

stanza [ipaddr]

ipaddr-auth Abilita e disabilita l’autenticazione medianteinformazioni sull’indirizzo IP.

STEP UP

stanza [authentication-levels]

level = unauthenticatedlevel = password

Configurazione di autenticazione a fasi.

MPA (MULTIPLEXING PROXY AGENTS)

stanza [mpa]

mpa Abilita e disabilita il supporto per l’autenticazionevia MPA (multiplexing proxy agents).

CDSSO

stanza [cdsso]

cdsso-auth Abilita e disabilita l’autenticazione mediante tokenCDSSO.

authtoken-lifetime Valore di durata massima per token diautenticazione CDSSO.

stanza [cdsso-peers]

<machine-name> =<keyfile-location>

Peer di dominio partecipanti in CDSSO.

FAILOVER

stanza [failover]

failover-auth Abilita e disabilita l’accettazione di cookie difailover.

failover-cookies-keyfile Ubicazione (percorso assoluto) della chiave dicrittografia cookie generata da cdsso_key_gen.

failover-cookie-lifetime Limite di tempo per la validità del contenuto deicookie di failover.

enable-failover-cookie-for-domain Cambia il tipo di cookie di failover da cookiespecifico del server a cookie specifico di dominio.

SSO e-COMMUNITY

stanza [e-community-sso]

e-community-sso-auth Abilita e disabilita SSO e-community.

e-community-name Il nome e-community che appare in token e richieste“di convalida”.

intra-domain-key Ubicazione del file di chiavi utilizzato percomunicazioni protette tra istanze WebSEAL in undominio DNS.

is-master-authn-server Designa la macchina locale come server diautenticazione principale WebSEAL.


AUTENTICAZIONE


master-authn-server Nome del server di autenticazione principaleWebSEAL (se non corrisponde alla macchina locale).

master-http-port Porta HTTP non standard su cui è in ascolto ilserver di autenticazione principale.

master-https-port Porta HTTPS non standard su cui è in ascolto ilserver di autenticazione principale.

vf-token-lifetime Il valore della durata del token “di convalida”.

vf-url L’URL “di convalida”.

ec-cookie-lifetime Il valore della durata del cookie e-community.

stanza [inter-domain-keys]

<domain-name> = <keyfile> I file di chiavi per altri domini partecipantiall’e-community.

RIAUTENTICAZIONE

stanza [reauthentication]

reauth-for-inactive Abilita la riautenticazione dovuta al timeout diinattività dell’immissione nella cache di sessione.

reauth-reset-lifetime Reimposta la durata dell’immissione nella cache disessione dopo una riautenticazione riuscita.

reauth-extend-lifetime Estende la durata dell’immissione nella cache disessione al processo di riautenticazione completo.

MECCANISMI DI AUTENTICAZIONE E LIBRERIE

stanza [authentication-mechanisms]

passwd-cdaspasswd-ldappasswd-uraftoken-cdascert-sslcert-cdashttp-requestcdssopasswd-strengthcred-ext-attrssu-passwordsu-token-cardsu-certificatesu-http-requestsu-cdssofailover-passwordfailover-token-cardfailover-certificatefailover-http-requestfailover-cdsso

Elenco dei meccanismi di autenticazione supportati edelle librerie condivise associate.

GESTIONE QOP (QUALITY OF PROTECTION) SSL

stanza [ssl-qop]

ssl-qop-mgmt Abilita e disabilita la gestione QOP (quality ofprotection).

stanza [ssl-qop-mgmt-hosts]

<ip-address> Livello di crittografia QOP per singoli host.


AUTENTICAZIONE


stanza [ssl-qop-mgmt-networks]

<ip-address/mask> Livello di crittografia QOP per singole reti.

stanza [ssl-qop-mgmt-default]

default Livello di crittografia QOP predefinito per tutti glialtri indirizzi IP non associati.

SESSIONE


stanza [session]

max-entries Numero massimo di immissioni simultanee nellacache credenziali/sessione WebSEAL.

timeout Durata massima di un’immissione nella cachecredenziali/sessione WebSEAL.

inactive-timeout Durata delle immissioni inattive nella cache dellecredenziali WebSEAL.

SESSIONI CLIENT SSL

ssl-id-sessions Utilizza l’ID SSL per mantenere le sessioni di loginHTTPS.

CONDIVISIONE SESSIONI

use-same-session Utilizza lo stesso ID sessione per i client che sispostano tra HTTP e HTTPS.

INVIO COOKIE DI SESSIONE

resend-webseal-cookies Invia tutti i cookie di failover e di sessioneconfigurati, con qualsiasi risposta, al client.

ID SESSIONE UTENTE

user-session-ids Abilita/disabilita la creazione e la gestione di IDsessione utente per la gestione della sessione.

CONTENUTO


stanza [content]

DIRECTORY E FILE LOCALI

doc-root Directory principale della struttura documenti Web.

directory-index Nome del file di indice directory.

delete-trash-dir Directory cestino temporanea per i file eliminati dalresponsabile.

DIRECTORY UTENTE LOCALE

user-dir La directory home dell’utente, contenente documentiHTML pubblici.

PAGINE DI ERRORE

error-dir La directory contenente file di descrizione deglierrori WebSEAL.

PAGINE DI GESTIONE ACCOUNT


CONTENUTO


stanza [acnt-mgt]

mgt-pages-root Root delle pagine di gestione account.

login Nome del modulo di login standard.

login-success Nome del modulo di login riuscito.

logout Nome della pagina visualizzata dopo l’avvenutoscollegamento.

account-locked Nome della pagina visualizzata se l’autenticazionenon è riuscita a causa di un blocco dell’account.

passwd-expired Nome della pagina visualizzata se l’autenticazionenon riesce a causa di password scaduta.

passwd-change Nome del modulo di modifica password.

passwd-change-success Nome della pagina visualizzata se la richiesta dimodifica password ha esito positivo.

passwd-change-failure Nome della pagina visualizzata se la richiesta dimodifica password ha esito negativo.

help Nome della pagina contenente i collegamenti apagine di amministrazione valide.

token-login Nome del modulo di login token.

next-token Nome del modulo del successivo token.

stepup-login Nome del modulo di login di autenticazione a fasi.

switch-user Nome del modulo di gestione cambio utente.

CGI LOCALE

stanza [cgi]

cgi-timeout Valore di timeout per la scrittura e la lettura inprocessi CGI secondari.

stanza [cgi-types]

bat = cmdcmd = cmdpl = perlsh = shtcl = tclsh76

Designa, per i server Win32, il programma daeseguire per una particolare estensione file CGI.

stanza [cgi-environment-variables]

ENV = <nome-variabile> Variabili di ambiente da ereditare da programmiCGI.

ICONE

stanza [content-index-icons]

image/*video/*audio/*text/htmltext/*application/x-tarapplication/*

Specifica le icone grafiche da utilizzare quandoWebSEAL genera un indice di directory (si verificaquando non esiste un file index.html).

stanza [icons]

diricon Icona da utilizzare per sottodirectory.


CONTENUTO


backicon Icona da utilizzare per la directory principale.

unknownicon Icona da utilizzare per tipi di file sconosciuti.

CACHE DI DOCUMENTI

stanza [content-cache]

text/htmlimage/**/*

Definisce dimensione e tipo della cache per tipiMIME di specifici documenti che WebSEAL archivianella memoria.

TIPI MIME

stanza [content-mime-types]

<extension> = <type> Definisce il tipo MIME per specifiche estensioni didocumento.

deftype Tipo MIME predefinito da utilizzare quando il tipodi documento non è elencato nella tabella diassociazione.

CODIFICHE CONTENUTO

stanza [content-encodings]

gzZ

Associa l’estensione del documento a un tipo dicodifica per browser che supportano la codifica delcontenuto.

LOGGING


stanza [logging]

server-log Ubicazione del file di log degli errori del server.

max-size Soglia di inversione del file di log per registrazioniHTTP.

flush-time Frequenza di svuotamento dei buffer dei file di logHTTP.

requests Abilita e disabilita il log di richieste HTTP.

requests-file Ubicazione del log di richieste HTTP.

referers Abilita e disabilita il log di referer HTTP.

referers-file Ubicazione del log di referer HTTP.

agents Abilita e disabilita il log di agent HTTP.

agents-file Ubicazione del log di agent HTTP.

gmt-time Registra richieste in GMT anziché nell’ora locale.

API DI AUTORIZZAZIONE


stanza [aznapi-configuration]

db-file Ubicazione del file di cache del database criteri delclient locale.

cache-refresh-interval Definisce l’intervallo tra i controlli di aggiornamento(poll) nel server di autorizzazione principale.


API DI AUTORIZZAZIONE


listen-flags Abilita e disabilita gli indicatori per la ricezione dinotifiche di aggiornamento della cache dei criteri.

LOGGING API DI AUTORIZZAZIONE

logclientid=webseald

logsize Soglia di inversione del file di log per laregistrazione dell’audit di gestione.

logflush Frequenza di svuotamento dei buffer dei file di logdell’audit di gestione.

logaudit Abilita e disabilita la funzione di audit.

auditlog Ubicazione del log di audit.

auditcfg = azn Cattura eventi di autorizzazione.

auditcfg = authn Cattura eventi di autenticazione.

auditcfg = http Cattura eventi WebSEAL.

DEFINIZIONI DEL SERVIZIO API DI AUTORIZZAZIONE

<service-id>

stanza [aznapi-entitlement-services]

AZN_ENT_EXT_ATTR

POLICY DIRECTOR


stanza [policy-director]

config-file Ubicazione del file di configurazione pd.conf.


Appendice B. Riferimento junction WebSEAL

Il programma di utilità pdadmin fornisce un prompt di riga comandi interattivoda cui è possibile eseguire attività su junction WebSEAL.

Indice degli argomenti:v “Utilizzo di pdadmin per creare junction” a pagina 237v “I comandi junction” a pagina 238v “Creazione di un nuovo junction per un server iniziale” a pagina 239v “Aggiunta di un server supplementare a un junction esistente” a pagina 241

Utilizzo di pdadmin per creare junctionPrima di utilizzare pdadmin, è necessario collegarsi a un dominio protetto comeutente responsabile sec_master.

Ad esempio:

UNIX:# pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>

Windows:MSDOS> pdadminpdadmin> loginImmettere ID utente: sec_masterImmettere la password:pdadmin>

Per creare junction WebSEAL, viene utilizzato il comando pdadmin server taskcreate:pdadmin> server task <ID-server> create <opzioni>

Il componente ID-server di questo comando rappresenta una combinazione delserver Access Manager utilizzato da tale comando e del nome host del serverAccess Manager.<server-Access-Manager>-<nome-host>

Sintassi per un singolo server WebSEAL:

Per Access Manager WebSEAL, Access-Manager-server è webseald e il nome-hostcorrisponde al nome della macchina server WebSEAL:pdadmin> server task webseald-<nome-host> create <opzioni>

Il server WebSEAL iniziale installato su una macchina è sempre citato dopo ilnome della macchina. Ad esempio, se il nome della macchina è cruz,l’identificazione del server per una singola installazione di WebSEAL è:webseald-cruz


Sintassi per istanze multiple di WebSEAL:

Se si installano istanze multiple del server WebSEAL sulla stessa macchina,Access-Manager-server rappresenta il nome configurato dell’istanza del serverWebSEAL, seguito da webseald, seguito a sua volta dal nome host:<nome-istanza>-webseald-<nome-host>

Ad esempio, se i nomi configurati per due istanze supplementari di WebSEALsono webseal2 e webseal3, le identificazioni del server saranno:webseal2-webseald-cruzwebseal3-webseald-cruz

Utilizzare il comando server list per verificare l’identificazione del server:pdadmin> server listwebseald-cruzwebseal2-webseald-cruzwebseal3-webseald-cruz

Opzioni di comando junction obbligatorie:

Le opzioni di comando obbligatorie per creare un junction WebSEAL di basecomprendono:v Il nome host del server di applicazione back-end (opzione –h)v Il tipo di junction — tcp, ssl, tcpproxy, sslproxy, local (opzione –t)v Il punto di junction (punto di montaggio)pdadmin> server task webseald-<nome-host> create –t <tipo>–h <nome-host> <punto-jct>

I comandi junctionI seguenti comandi junction sono disponibili con pdadmin server task:

Comando Descrizione

create Crea un nuovo junction per un server iniziale.

add Aggiunge server supplementari a un punto di junctionesistente.

remove Rimuove un server da un punto di junction.

Sintassi: remove –i <id-server> <punto-junction>

Utilizzare il comando show per determinare l’ID di unparticolare server.

delete Rimuove il punto di junction.

Sintassi: delete <punto-junction>

list Elenca tutti i punti di junction su questo server.

Sintassi: list

show Visualizza i dettagli di un junction.

Sintassi: show <punto-junction>


Comando Descrizione

jmt load jmt clear Il comando jmt load fornisce a WebSEAL i dati della tabella diassociazione dei junction (jmt.conf) per gestire l’elaborazionedi URL relativi al server generati in modo dinamico.

Il comando jmt clear rimuove i dati della tabella diassociazione dei junction da WebSEAL.

help Elenca i comandi junction.

Sintassi: help

help <comando> Visualizza una guida dettagliata sui comandi di uno specificojunction.

exit Esce dal programma di utilità pdadmin.

Sintassi: exit

Questi comandi, e le opzioni associate, vengono trattati nelle sezioni seguenti.

Creazione di un nuovo junction per un server inizialeOperazione: Crea un nuovo punto di junction e collega un server iniziale.

Sintassi:create –t <tipo> –h <nome-host> [<options>] <punto-junction>

Tipo di junction

–t <tipo> **Obbligatorio**

Tipo di junction. Uno dei seguenti: tcp, ssl, tcpproxy,sslproxy, local.

La porta predefinita per –t tcp è 80. La portapredefinita per –t ssl è 443.

Nome host

–h <nome-host> **Obbligatorio**

Il nome host DNS o l’indirizzo IP del server back-enddi destinazione.

Opzioni

Autenticazione reciproca su SSL

–K <etichetta-chiave> WebSEAL utilizza il certificato client perl’autenticazione al server back-end.

–B WebSEAL utilizza informazioni sull’intestazione BAper l’autenticazione al server back-end. Richiede leopzioni di filtro –U, –W e –b.

–U <“nomeutente”> Il nome utente WebSEAL. Utilizzare con –B perinviare informazioni sull’intestazione BA al serverback-end.

–W <“password”> La password WebSEAL. Utilizzare con –B per inviareinformazioni sull’intestazione BA al server back-end.

Appendice B. Riferimento junction WebSEAL 239

–D <“DN”> Specificare il nome particolare (DN-DistinguishedName) del cerificato del server back-end. Questovalore, corrispondente al DN del certificato effettivo,migliora la funzione di autenticazione.

Opzioni di junction proxy (richiede –t tcpproxy o –t sslproxy)



Immissione di informazioni sull’intestazione BA

–b <valore-BA> Definisce il modo in cui il server WebSEAL trasmettele informazioni HTTP sull’autenticazione BA al serverback-end. Può essere uno dei modi seguenti:

filter (predefinito), ignore, supply, gso

Opzioni generali per junction TCP e SSL

–c <tipi-id> Inserire l’identità client Access Manager nelleintestazioni HTTP sul junction. L’argomento tipi-idpuò includere qualsiasi combinazione dei seguenti tipidi intestazione HTTP Access Manager: iv-user,iv-user-l, iv-groups, iv-creds, all.

–i Il server WebSEAL tratta gli URL come non sensibiliai caratteri maiuscoli/minuscoli.

–j Fornire l’identificazione del junction in un cookie pergestire URL relativi al server generati da script.

–k Invia cookie di sessione al server di portale back-end.

–p <porta> La porta TCP del server di back-end di terzi. Il valorepredefinito è 80 per junction TCP; 443 per junctionSSL.

–q <ubicazione> Percorso relativo per lo script query_contents. Perimpostazione predefinita, Access Manager ricercaquery_contents in /cgi_bin/. Se questa directory èdiversa oppure se il nome file query_contents èdiverso, utilizzare questa opzione per indicare aWebSEAL il nuovo URL per il file. Obbligatorio perserver back-end Windows.

–r Inserisce l’indirizzo IP in arrivo nell’intestazioneHTTP sul junction.

–s Specifica che il junction supporta le applicazioni distato (stateful). Per impostazione predefinita, ijunction non sono ″stateful″.

–T <risorsa/gruppo-risorse>

Nome della risorsa o del gruppo risorse GSO.Obbligatorio ed utilizzato solo con l’opzione –b gso.

–u <UUID> Specifica l’UUID di un server back-end collegato aWebSEAL attraverso un junction stateful (–s).


–v <nome-host-virtuale>[:<port>]

Il nome host virtuale rappresentato sul serverback-end. Questa opzione supporta un’impostazionedi host virtuale sul server back-end.

L’utente utilizza –v quando il server di junctionback-end prevede un’intestazione di nome hostpoiché si sta eseguendo un collegamento adun’istanza virtuale di tale server. La richiesta diintestazione HTTP predefinita proveniente dalbrowser non è a conoscenza del fatto che il serverback-end ha più nomi e server virtuali multipli. E’necessario configurare WebSEAL in modo che forniscainformazioni supplementari sull’intestazione nellerichieste destinate ad un server back-end impostatocome host virtuale.

–w Supporto filesystem Win32.

Equità di junction

–l <valore-percentuale> Definisce il limite soft per il consumo di thread diprocesso.

–L <valore-percentuale> Definisce il limite hard per il consumo di thread diprocesso.

Junction LTPA

–A Abilita e disabilita junction LTPA.

–F <“file di chiavi”> Ubicazione del file di chiavi utilizzato percrittografare i dati del cookie LTPA.

–Z <“password-file dichiavi”>

La password per il file di chiavi.

Junction SSL WebSEAL-WebSEAL

–C Autenticazione reciproca tra un server WebSEALfront-end e un server WebSEAL back-end su SSL.Richiede il tipo –t ssl o –t sslproxy.

Single sign-on dei moduli

–S <file-config> Ubicazione del file di configurazione single sign-ondei moduli.

Opzioni di junction locali (utilizzare con –t local)

–d <dir> Directory locale per il junction. **Obbligatorio.**

–f Forza la sostituzione di un junction esistente.

Punto di junction

Posizione nello spazio per i nomi WebSEAL per creare il junction.

Aggiunta di un server supplementare a un junction esistenteOperazione: Aggiunge un server supplementare a un punto di junction esistente.

Sintassi:add –h <nome-host> [<options>] <punto-junction>

Nome host

Appendice B. Riferimento junction WebSEAL 241

–h <nome-host> **Obbligatorio**

Il nome host DNS o l’indirizzo IP del server back-enddi destinazione.

Opzioni

Autenticazione reciproca su SSL

–D <“DN”> Specificare il nome particolare (DN-DistinguishedName) del cerificato del server back-end. Questovalore, corrispondente al DN del certificato effettivo,migliora la funzione di autenticazione.

Opzioni di junction proxy (obbligatorie con –t tcpproxy e –t sslproxy)



Opzioni generali per junction TCP e SSL

–i Il server WebSEAL tratta gli URL come non sensibiliai caratteri maiuscoli/minuscoli.

–p <porta> La porta TCP del server di back-end di terzi. Il valorepredefinito è 80 per junction TCP; 443 per junctionSSL.

–q <url> URL di relazione per lo script query_contents. AccessManager ricerca query_contents in /cgi_bin/. Sequesta directory è diversa oppure se il filequery_contents è stato ridenominato, utilizzare questaopzione per indicare a WebSEAL il nuovo URL per ilfile.

–u <UUID> Specifica l’UUID di un server back-end collegato aWebSEAL attraverso un junction stateful (–s).

–v <nome-host-virtuale> Il nome host virtuale rappresentato sul serverback-end. Questa opzione supporta un’impostazionedi host virtuale sul server back-end.

L’utente utilizza –v quando il server di junctionback-end prevede un’intestazione di nome hostpoiché si sta eseguendo un collegamento adun’istanza virtuale di tale server. La richiesta diintestazione HTTP predefinita proveniente dalbrowser non è a conoscenza del fatto che il serverback-end ha più nomi e server virtuali multipli. E’necessario configurare WebSEAL in modo che forniscainformazioni supplementari sull’intestazione nellerichieste destinate ad un server back-end impostatocome host virtuale.

–w Supporto filesystem Win32.

Punto di junction

Aggiunge un server a questo punto di junction esistente.


Appendice C. Informazioni particolari

Queste informazioni sono state sviluppate per prodotti e servizi offerti negli StatiUniti d’America.

E’ possibile che in altri paesi l’IBM non offra i prodotti, i servizi o le funzioniillustrati in questo documento. Per informazioni sui prodotti e i servizi disponibilinel proprio paese, consultare il rappresentante locale IBM. Ogni riferimentorelativo a prodotti, programmi o servizi IBM non implica che solo quei prodotti,programmi o servizi IBM possano essere utilizzati. In sostituzione a quelli fornitidall’IBM, possono essere usati prodotti, programmi o servizi funzionalmenteequivalenti che non comportino la violazione dei diritti di proprietà intellettuale odi altri diritti dell’IBM. E’ comunque responsabilità dell’utente valutare e verificarela possibilità di utilizzare altri programmi e/o prodotti, fatta eccezione per quelliespressamente indicati dall’IBM.

L’IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattatonella presente pubblicazione. La fornitura di questa pubblicazione non implica laconcessione di alcuna licenza su di essi. Chi desiderasse ricevere informazionirelative a lincenze può rivolgersi per iscritto a:

Director of Commercial RelationsIBM EuropeSchoenaicher Str. 220D-7030 BoeblingenDeutschland

Per domande sulla licenza riguardanti informazioni double-byte (DBCS), contattareIBM Intellectual Property Department nel proprio paese oppure scrivere a:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chomeMinato-kuTokyo 106Japan

Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui legginazionali siano in contrasto con le disposizioni in esso contenute:L’INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCEQUESTA PUBBLICAZIONE ″NELLO STATO IN CUI SI TROVA″, SENZAALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALIGARANZIE DI COMMERCIABILITA’ ED IDONEITA’ AD UNO SCOPOPARTICOLARE. Alcune stati non consentono la rinuncia a garanzie esplicite oimplicite in determinate transazioni; quindi la presente dichiarazione potrebbeessere non essere a voi applicabile.

Questa pubblicazione potrebbe contenere imprecisioni tecniche o errori tipografici.Le informazioni incluse in questo documento vengono modificate su baseperiodica; tali modifiche verranno incorporate nelle nuove edizioni dellapubblicazione. L’IBM si riserva il diritto di apportare miglioramenti e/o modificheal prodotto o al programma descritto nel manuale in qualsiasi momento e senzapreavviso.


Tutti i riferimenti a siti Web non dell’IBM contenuti in questo documento sonoforniti solo per consultazione. I materiali disponibile presso i siti Web non fannoparte di questo prodotto e l’utilizzo di questi è a discrezione dell’utente.

Tutti i commenti e i suggerimenti inviati potranno essere utilizzati liberamentedall’IBM e dalla Selfin e diventeranno esclusiva delle stesse.

Coloro che detengono la licenza su questo programma e desiderano avereinformazioni su di esso allo scopo di consentire (i) uno scambio di informazioni traprogrammi indipendenti ed altri (compreso questo) e (ii) l’uso reciproco di taliinformazioni, dovrebbero rivolgersi a:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758USA

Queste informazioni possono essere rese disponibili secondo condizionicontrattuali appropriate, compreso, in alcuni casi, il pagamento di un addebito.

Il programma su licenza descritto in questo manuale e tutto il materiale su licenzaad esso relativo sono forniti dall’IBM nel rispetto delle condizioni previste dallalicenza d’uso.

Tutti i dati relativi alle prestazioni contenuti in questa pubblicazione sono statideterminati in un ambiente controllato. Pertanto, i risultati ottenuti in ambientioperativi diversi possono variare in modo considerevole. Alcune misure potrebberoessere state fatte su sistemi di livello di sviluppo per cui non si garantisce chequeste saranno uguali su tutti i sistemi disponibili. Inoltre, alcune misurepotrebbero essere state ricavate mediante estrapolazione. I risultati possono quindivariare. Gli utenti di questa pubblicazione devono verififcare che i dati sianoapplicabili al loro specifico ambiente.

Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di taliprodotti. L’IBM non ha verificato tali prodotti e, pertanto, non può garantirnel’accuratezza delle prestazioni. Eventuali commenti relativi alle prestazioni deiprodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.

Tutte le dichiarazioni riguardanti la futura direzione o le intenzioni della IBM sonosoggette a sostituzione o al ritiro senza preavviso, e rappresentano unicamentescopi e obiettivi della IBM stessa.

Questa pubblicazione contiene esempi di dati e prospetti utilizzati quotidianamentenelle operazioni aziendali, Pertanto, può contenere nomi di persone, società,marchi e prodotti. Tutti i nomi contenuti nella pubblicazione sono fittizi e ogniriferimento a nomi e indirizzi reali è puramente casuale.

LICENZA SOGGETTA ALLE LEGGI SUL DIRITTO D’AUTORE:

Queste informazioni contengono esempi di programmi applicativi in linguaoriginale, che illustrano le tecniche di programmazione su diverse piattaformeoperative. Potete copiare, modificare e distribuire questi esempi di programmisotto qualsiasi forma senza alcun pagamento alla IBM, allo scopo di sviluppare,utilizzare, commercializzare o distribuire i programmi applicativi in modoconforme alle API (Application Programming Interface) a seconda della


piattaforma operativa per cui tali esempi dei programmi sono stati scritti. Questiesempi non sono stati testati approfonditamente tenendo conto di tutte lecondizioni possibili. La IBM, quindi, non può garantire o assicurare l’affidabilità, lapraticità o il funzionamento di questi programmi. E’ possibile copiare, modificare edistribuire questi esempi di programmi sotto qualsiasi forma e senza alcunpagamento alla IBM, allo scopo di sviluppare, utilizzare, commercializzare odistribuire i programmi applicativi in modo conforme alle API (ApplicationProgramming Interface) della IBM.

Ogni copia o parte di tali programmi di esempio deve includere un’informazionesul copyright come questa di seguito indicata:

© (nome società) (anno). Parti di questo programma derivano da programmi diesempio della IBM Corp. © Copyright IBM Corp. _inserire l’anno o gli anni_. Tuttii diritti riservati.

MarchiI seguenti termini sono marchi della International Business Machines Corporationnegli Stati Uniti e/o in altri paesi:

AIXDB2IBMLogo IBMSecureWayTivoliLogo TivoliWebSphere

Microsoft, Windows, Windows NT e il logo Windows sono marchi della MicrosoftCorporation.

Java e tutti i marchi ed i logo basati su Java sono marchi o marchi registrati dellaSun Microsystems, Inc.

UNIX è un marchio di The Open Group.

Nomi di altri prodotti, società e servizi potrebbero essere marchi di altre società.

Appendice C. Informazioni particolari 245

Indice analitico

Aaccept-client-certs 120access control list (ACL) 4account-locked 34acct_locked.html 34ACL 4agent.log 40

esempio 42formato logging degli eventi 44

agenti 40agents-file 40aggiornamenti e polling del database autorizzazioni 48argument-stanza 198arresto di WebSEAL 20ascolto notifiche di aggiornamento 48, 49attributi estesi

document-cache-control (POP) 30HTTP-Tag-Value (junction) 209, 213nelle credenziali utente 210reauth (POP) 128

attributo di junction HTTP-Tag-Value 210, 213attributo esteso POP document-cache-control 30attributo esteso POP reauth 128attributo esteso su-admin 67autenticazione

accesso alle risorse, autenticato 11accesso alle risorse, non autenticato 11autenticazione base 115CDSSO 135certificato 118comprensione del processo 101configurazione metodi multipli 113configurazione predefinita 113e-community 139indirizzo IP 123intestazione HTTP 121metodi supportati 102moduli 117MPA (multiplexing proxy agents) 124obiettivi 10panoramica 9panoramica sulla configurazione 112parametri CDAS personalizzati 112parametri locali 112riautenticazione 127, 130richiesta di login 114single sign-on moduli 194switch user 60tipi di dati di sessione supportati 102token 123

autenticazione a fasi 91autenticazione base

configurazione 115autenticazione CDSSO 135autenticazione di indirizzo IP 123autenticazione di intestazione HTTP 121autenticazione e-community 139

codifica token ″di convalida″ 147configurazione 148cookie e-community 145flusso del processo 141

autenticazione e-community (Continua)funzioni 141richiesta e risposta ″di convalida″ 146token ″di convalida″ 147

autenticazione mediante certificato 118autenticazione moduli 117

soluzione single sign-on 194autenticazione MPA 124autenticazione multi-factor 95autenticazione token 123authtoken-lifetime 138avvio di WebSEAL 20

Bba-auth 115back-end, supporto applicazioni 205backicon 27basic-auth-realm 115basicauth-dummy-passwd 186

Ccache

credenziali WebSEAL 103GSKit (SSL) 103

cache CRL, configurazione 39gsk-crl-cache-entry-lifetime 39gsk-crl-cache-size 39

cache di credenziali 103configurazione 105maximum entries 105panoramica e struttura 12timeout di inattività 105timeout durata 105

cache di documenti 28POP document-cache-control 30ripulitura delle cache 30

cache di richieste 67cache di richieste del server 67cache di richieste POST 67cache di sessione

configurazione 104, 105credenziali WebSEAL 103GSKit (SSL) 103panoramica e struttura 12timeout di inattività 105timeout durata 105

cache di sessione/credenziali WebSEALconfigurazione 105panoramica 103panoramica e struttura 12

cache di sessione GSKit (SSL) 103configurazione 104

cache GSO, configurazione 192cache LTPA, configurazione 193cache-refresh-interval 49caratteri codificati UTF-8 70cdsso 112, 137cdsso-auth 137


cdsso_key_gen 111, 138, 147cdssoauthn 137cert-cdas 112cert-ssl 112, 120certificati

gestione 35GSKit 36iKeyman 36tipi di file del database di chiavi 36

cgi-timeout 25client-connect-timeout 24comando net (Windows) 59comando pd_start status 59comando pdweb 20, 59concessioni business (dynamic) 209concessioni dynamic business 209connettività SSL 24connettività TLS 24controllo CRL 39cookie

junction 167sessione 106, 173

cookie di failoverabilitare cookie per tutto il dominio 111abilitazione 110codifica/decodifica dati di cookie 111configurazione 108configurazione durata cookie 111

cookie di sessione 106abilitazione 106

cookie e-community 145cookie junction 167cred-ext-attrs 113credenziali

attributi estesi 209, 213inserimento dati in intestazioni HTTP 209inserimento di dati LDAP 209inserimento id sessione utente nell’intestazione HTTP 213panoramica 12

criteri ACLcaratteri validi per nomi ACL 86definizione 4ereditato 5esplicito 5specifici di WebSEAL 85

criteri POPattributo esteso document-cache-control 30attributo esteso reauth 128autenticazione basata su rete 96definizione 4qualità di protezione 99rafforzamento autenticazione (a fasi) 91

criterio ACL default-webseal 86criterio ACL ereditato 5criterio ACL esplicito 5criterio di protezione

identificazione tipi di contenuto 8livelli di protezione 8pianificazione e implementazione 8

criterio di rafforzamento password 88criterio pdadmin

disable-time-interval 87max-login-failures 87max-password-repeated-chars 88min-password-alphas 88min-password-length 88min-password-non-alphas 88

criterio pdadmin (Continua)password-spaces 88

criterio POP di autenticazione basato su rete 96criterio POP di rafforzamento autenticazione 91, 96criterio three strikes login 87cross-domain sign-on

CDSSO 135e-community 139

Ddati LDAP in intestazioni HTTP 209db-file 49directory-index 27directory principale del server 23directory root dei documenti

modifica dell’ubicazione 26diricon 27disable-ssl-v2 24disable-ssl-v3 24disable-tls-v1 24doc-root 26dynamic business, concessioni 209dynurl-allow-large-posts 219dynurl.conf 216dynurl-map 216dynurl update 218

Ee-community-name 148e-community-sso-auth 148ec-cookie-lifetime 149enable-failover-cookie-for-domain 111enforcer dei criteri 7entrust-client 122equità junction 50error.log 44espressioni regolari

elenco di 199per single sign-on di moduli 199per URL dinamici 216

Ffailover-auth 110failover-cdsso 110failover-certificate 110failover-cookie-lifetime 111failover-cookies-keyfile 111failover-http-request 110failover-password 110failover-token-card 110fatal.log 44file di instradamento 44filtro dei documenti 31filtro di URL

elaborazione di URL nelle richieste 167filtro di script per percorsi assoluti 165intestazione Content-Length 166regole standard di filtro 164

flush-time 41formato combinato NCSA 43formato di log HTTP comune 42formato log comune (request.log) 42forms-auth 117


fsso.conf.template 197funzione di filtro

documenti statici 164elaborazione di URL nelle richieste 167filtro di URL assoluti con funzione di filtro script 165intestazione Content-Length

X-Old-Content-Length 166miglior utilizzo per URL assoluti 206regole di filtro URL standard per WebSEAL 164text/html 164text/vnd.wap.wml 164tipi MIME del documento 31URL assoluti 165URL correlati al server 165

funzione di registrazione HTTPimpostazione predefinita 40utilizzo del logging di eventi 43

Ggestione ID sessione 211gestione ID sessione utente 212

tagvalue_user_session_id 212user-session-ids 212

gestore del portale Web 6gestore risorse 7global sign-on (GSO) 189gmt-time 41gruppo su-admins 60, 61, 62, 63gruppo su-excluded 61, 62, 63gruppo webseal-mpa-servers 126, 127gsk-crl-cache-entry-lifetime 39gsk-crl-cache-size 39GSKit 36

cache CRL 39tipi di file 36

GSO 189configurazione cache GSO 192

gso-cache-enabled 192gso-cache-entry-idle-timeout 192gso-cache-lifetime 192gso-cache-size 192gso-resource 198

Hhelp 34help.html 34http 24http-headers-auth 121HTTP_IV_CREDS 170, 203, 205HTTP_IV_GROUPS 170, 203, 205HTTP_IV_REMOTE_ADDRESS 171HTTP_IV_USER 170, 203, 205HTTP_PD_USER_SESSION_ID 211HTTP_PD-USER-SESSION-ID 214http-port 24http-request 112, 113, 122http-timeout (junctions) 25httpauthn 122https 24https-port 24https-timeout (junctions) 25

Iicone indice di directory 27ID sessione SSL 106identità del server (HTTP), soppressione 72identità del server HTTP, soppressione 72iKeyman 38

certificato di prova WebSEAL 119junction di tipo SSL 157junction SSL autenticati reciprocamente 159panoramica 38

inactive-timeout 105installazione WebSEAL, directory principale 19intestazione 122intestazione Content-Length 166intestazione HOST, miglior utilizzo per junction 206intestazione HTTP

limitazione della dimensione 172PD-USER-SESSION-ID 213

intestazione PD_PORTAL 207intestazione PD-USER-SESSION-ID HTTP 213intra-domain-key 147, 149ipaddr-auth 123is-master-authn-server 149istanze multiple WebSEAL

annullamento configurazione 58comandi di avvio, arresto, riavvio e stato del server 59configurazione su UNIX 54configurazione su Windows 56panoramica sulla configurazione 53sintassi nei comandi pdadmin 155, 238

iv-creds 170, 205iv-groups 170, 205iv-remote-address 171iv-user 170, 205ivweb_setup 56ivweb_uninst 58

Jjmt.conf 168jmt load 168jmt-map 168junction

-b filter 188-b gso 189-b ignore 187-b supply 186applicazione di autorizzazioni 178assegnazione thread di processo (-l) 51assegnazione thread di processo (-L) 52attributo HTTP-Tag-Value 213autenticati in modo reciproco (-D, -K, -B, -U, -W) 158autenticazione mediante certificato 179autenticazione mediante intestazione BA (-B, -U, -W) 160certificato client (WebSEAL) (-K) 159certificato client WebSEAL (-K) 159cookie di sessione a server di portale (-k) 173corrispondenza del DN (Distinguished Name)(-D) 159elaborazione di URL nelle richieste 167elaborazione URL correlati al server mediante associazione

di junction 168elaborazione URL correlati al server mediante cookie 167file system Windows (-w) 177filtro di URL assoluti con funzione di filtro script 165filtro di URL nelle risposte 164fornire identità client in intestazioni HTTP (-c) 170

Indice analitico 249

junction (Continua)forzatura nuovo junction (-f) 26, 169global sign-on (GSO) 189impatto delle opzioni -b su junction autenticati

reciprocamente 160indicazioni per la creazione 154junction proxy (-H, -P) 161LTPA (-A, -F, -Z) 193miglior utilizzo 205miglior utilizzo di intestazioni HOST (-v) 206modifica URL da applicazioni back-end 162montaggio di più server 178nome host virtuale (-v) 206opzione host (-h) 156opzione tipo (-t) 156opzioni gso (-b gso, -T) 191opzioni obbligatorie 156panoramica 13, 153pdadmin server task 155query_contents 179riferimento comandi 237risposte HTTP/1.0 e 1.1 20scalabilità 15single sign-on di moduli (-S) 200specifica indirizzo IP nelle intestazioni HTTP (-r) 171specifica UUID back-end (-u) 174supporto junction di stato (-s, -u) 174tabella di associazione junction 168URL non sensibili al maiuscolo/minuscolo (-i) 173WebSEAL-WebSEAL (-C) 162

junction autenticati reciprocamente 158junction-db 153junction di stato 174junction WebSEAL, Vedere junction 153

Lldapauthn 116, 117libcdssoauthn 137libhttpauthn 122libldapauthn 116, 117libreria condivisa CDMF 135libreria condivisa libfailoverauthn 110libsslauthn 120libsuauthn 64libtokenauthn 123listen-flags 49logcfg 43, 81logging di eventi

funzione di registrazione HTTP 43statistiche 81

login 34condizioni di richiesta 114

login-form-action 198login.html 34, 118login-page 198login_success.html 34logout 34, 114logout.html 34LTPA (WebSphere) 192

configurazione cache LTPA 193configurazione junction 193

ltpa-cache-enabled 193ltpa-cache-entry-idle-timeout 193ltpa-cache-entry-lifetime 193ltpa-cache-size 193

Mmaster-authn-server 149master-http-port 148master-https-port 148max-entries 105max-size 41max-webseal-header-size 172messaggi 44

error.log 44fatal.log 44file di instradamento 44notice.log 44warning.log 44

messaggi di errorefunzionalità 44HTTP 31supporto macro per HTTP 33

messaggi di errore HTTP 31supporto macro 33

messaggi di funzionalità 44error.log 44fatal.log 44file di instradamento 44notice.log 44warning.log 44

metodi di autenticazione, riepilogo 102metodo GET 218metodo POST 218

configurazione di limitazioni 219mgt-pages-root 34, 62miglior utilizzo

filtro URL assoluto 206fornire informazioni di intestazione HOST (-v) 206

miglior utilizzo, filtro URL assoluto 206MIME, tipo 31mpa 127multiplexing proxy agents (autenticazione) 124

Nnext-token 34nexttoken.html 34notice.log 44

Ooggetti definiti dall’utente 4oggetti di gestione 4oggetti web 3oggetto protetto 3

Ppagine di gestione account 34pagine di gestione account HTML

supporto macro 35pagine personalizzate HTML 34parametri di timeout

cache di sessione/credenziali WebSEAL 105cache di sessione SSL GSKit 104HTTP e HTTPS 24

passwd-cdas 112passwd-change 34passwd-change-failure 34passwd-change-success 34


passwd_exp.html 34passwd-expired 34passwd.html 34passwd-ldap 112, 116, 117passwd_rep.html 34pd.conf 209pdadmin server task

terminate all_sessions 214pdadmin server task (junction) 155PDWeb_config 54pdweb.debug (trace) 83PDWeb_unconfig 58persistent-con-timeout 24ping-time (junctions) 25pkmscdsso 139pkmslogout 114pkmspasswd 115pkmsvouchfor 146, 149polling 48polling del database di autorizzazioni 49pool di eventi

http 43http.agent 43http.clf 43http.cof 43http.ref 43

pool di eventi http 43pool di eventi http.agent 43pool di eventi http.clf 43pool di eventi http.cof (NCSA) 43pool di eventi http.ref 43POP 5posizione database autorizzazioni di replica 49posizione replica del database autorizzazioni 49programma di utilità trace 82

componente pdweb.debug 83trace list 83trace set 82trace show 83

programmazione CGIsupporto 203supporto di variabili di ambiente WIN32 204

protected object policies 5

Qqualità di protezione

criteri POP 99host 48livello predefinito 47reti 48

query_contents 179installazione 179personalizzazione 182protezione 183

query_contents.c 179query_contents.cfg 179query_contents.exe 179query_contents.html 179query_contents.sh 179

Rreauth-extend-lifetime 129, 132reauth-for-inactive 131reauth-reset-lifetime 129, 132

referer 40referer.log 40


referers-file 40registrazione

HTTP (logging di eventi) 43HTTP predefinita 40

REMOTE_USER 203replica di server WebSEAL front-end 52request-body-max-read 69, 219request.log 40


request-max-cache 69requests-file 40resend-webseal-cookies 106riautenticazione

attributo esteso POP reauth 128basata su criteri (POP) di protezione 127basata sull’inattività di sessione 130parametro reauth-for-inactive 131reauth-extend-lifetime 129, 132reauth-reset-lifetime 129, 132

richiesta di logincondizioni 114

richiesta e risposta di convalida 146richieste 40ripulitura delle cache 30risorsa di sistema 3risposte HTTP/1.1 20

Sscalabilità 15

server back-end di replica 17server front-end di replica 15

script-filter 165scripting cross-site

prevenzione della vulnerabilità 71stanza illegal-url-substrings 72

securitygroup 61, 62, 63server-log 21server-name 20, 52server-root 23, 62server WebSEAL front-end

replica 52servizio di autorizzazione 7servizio di personalizzazione

configurazione di WebSEAL 208esempio 208panoramica 207

single sign-on-b filter 188-b gso 189-b ignore 187-b supply 186autenticazione moduli 194CDSSO 135concetti 185configurazione cache GSO 192e-community 139fornire identità client nelle intestazioni BA 186global sign-on (GSO) 189LTPA (WebSphere) 192

spazio oggetti protetti 3oggetti definiti dall’utente 4


spazio oggetti protetti (Continua)oggetti di gestione 4oggetti web 3oggetto protetto 3risorsa di sistema 3server-name WebSEAL 20

ssl-id-sessions 106ssl-keyfile 38ssl-keyfile-label 38ssl-keyfile-pwd 38ssl-keyfile-stash 38ssl-ldap-server 39ssl-ldap-server-port 39ssl-ldap-user 39ssl-ldap-user-password 39ssl-max-entries 104ssl-qop-mgmt 47ssl-v2-timeout 104ssl-v3-timeout 104sslauthn 120stanza acnt-mgt 34, 62stanza authentication-levels 91, 96stanza authentication-mechanisms 64stanza aznapi-configuration 43, 49, 81stanza cache ltpa 193stanza cdsso-peers 138stanza cgi-types 28stanza content-caches 28stanza filter-content-types 31stanza filter-schemes 31stanza filter-url 165stanza forms-sso-login-pages 197stanza illegal-url-substrings 72stanza inter-domain-keys 147, 150stanza junction 51stanza ldap-ext-cred-tags 209, 210stanza logging 21stanza login-page 197stanza portal-map 208stanza script-filtering 165stanza ssl-qop-mgmt-default 47stanza ssl-qop-mgmt-hosts 48stanza ssl-qop-mgmt-networks 48stanza variabili di ambiente cgi 204statistiche 73

abilitare (stats on) 73abilitazione mediante il logging di eventi 81comandi stats 73componenti 76disabilitazione (stats off) 75elenco (stats list) 76parametro logcfg 81parametro stats 81pdweb.authn 76pdweb.authz 77pdweb.doccache 79pdweb.http 77pdweb.https 77pdweb.jct.# 81pdweb.jmt 78pdweb.sescache 79pdweb.threads 78reimpostazione (stats reset) 76sintassi del comando stats 73tipi di attività 76visualizzazione (stats get) 75visualizzazione (stats show) 75

statistiche pdweb.authn 76statistiche pdweb.authz 77statistiche pdweb.doccache 79statistiche pdweb.http 77statistiche pdweb.https 77statistiche pdweb.jct.# 81statistiche pdweb.jmt 78statistiche pdweb.sescache 79statistiche pdweb.threads 78stato di sessione

abilitazione cookie di sessione 106configurazione cache di credenziali WebSEAL 105configurazione cache ID sessione SSL GSKit 104cookie di failover 108cookie di sessione 106gestione 103gestione ID sessione utente 212terminare sessioni di un singolo utente 214terminare tutte le sessioni utente 214tipi di dati ID sessione validi 108tra client e back-end 211

stats 81stats, comandi 73stepup-login 34, 93stepuplogin.html 34, 93suauthn 64supporto applicazioni back-end 205supporto applicazioni per il server 205supporto macro

messaggi di errore HTTP 33pagine di gestione account HTML 35

suppress-server-identity 72switch user 60

abilitazione 61attributo esteso su-admin 67esclusione di utenti 63flusso del processo 60gruppo su-admins 60, 61gruppo su-excluded 61impatto sulla funzionalità WebSEAL 66libreria condivisa CDAS 65libreria condivisa incorporata 64meccanismo di autenticazione 64metodi di autenticazione validi 63securitygroup 61

switch-user 62

Ttabella di associazione junction 168tag- valore 209, 213tagvalue_user_session_id 213tcp-port 49terminare sessioni di un singolo utente 214terminare tutte le sessioni utente 214thread di processo

assegnazione globale 51assegnazione per junction 51equità junction 50gestione 49junction 50WebSEAL 50

timeout 105, 129, 131tipi di dati di sessione 102tipi di dati ID sessione 108tipi di file del database di chiavi 36TLS (Transport Layer Security) 24


token-auth 123token-cdas 112, 123token-login 34tokenauthn 123tokenlogin.html 34

Uudp-port 49unknownicon 27URL

comprensione tipi di percorso 164gestione UTF-8 70modifica URL a risorse back-end 162opzioni di filtro 164percorsi assoluti 164percorsi correlati 164percorsi correlati al server 164utilizzo di cookie junction 167utilizzo tabella di associazione junction 168

URL dinamiciassociazione di oggetti ACL 216controllo dell’accesso, come fornire 215dynurl-allow-large-posts 219dynurl-map 216dynurl update, aggiornamento 218esempio 221inserimento di limitazioni su richieste POST 219metodi GET e POST 218panoramica 215request-body-max-read 219riepilogo e note tecniche 220risoluzione 218

use-same-session 106, 107user-session-ids 212utenti non autenticati, controllo di 99utf8-url-support-enabled 70

Vvariabili di ambiente WIN32, supporto 204vf-token-lifetime 149vf-url 149

Wwarning.log 44WebSEAL

avvio e arresto del server 20configurazione istanze multiple 53directory di installazione principale 19directory principale del server 23directory principale della struttura documenti 26file di configurazione webseald.conf 21file di log 21nello spazio oggetti 20panoramica 1risposte HTTP/1.1 20server-name 20statistiche 73

WebSEAL, file di log 21webseal-cert-keyfile 37webseal-cert-keyfile-label 37, 119, 179webseal-cert-keyfile-pwd 37webseal-cert-keyfile-stash 37

webseald.confpanoramica 21riferimento 225ubicazione 21

WebSphere LTPA 192worker-thread-hard-limit 51worker-thread-soft-limit 51worker-threads 50


Stampato in Italia

GC13-3056-00

IBM Tivoli Access Manager: Guida per il responsabile di sistema

Documents

Transcript of IBM Tivoli Access Manager: Guida per il responsabile di sistema