Cestrone Pasquale

MANUALE
START
 Cestrone Pasquale

MANUALE START

Indice
1. Web Server 3
2. Web Application 4
3. Application Server 5
3.1 WebLogic Server (Admin Server) 7
4. Directory 9
5. Directory Service 11
6. Active Directory 12
7. Replica di Active Directory e ruoli FSMO 14
8. Protocollo LDAP 17
9. Single Sign-On 22
10. CA Siteminder 32
11. OAM 45
12. OIM 48
12.1 Integration Solutions 49
12.1.1 Connettori predefiniti 49
12.1.2 Connettori generici di tecnologia 49
12.1.3 Connettori personalizzati 49
12.2 Riconciliazione 49
12.3 Provisioning 50
13. OpenID e SAML 52
14. Oauth 55
15. Federation 56
16. OpenAM 58
17. Service-Oriented Architecture 60
18. Algoritmo RSA 61
19. Computer Cluster 64
20. Server-side 66
19.1 Apache Tomcat 66
21. Replica di Active Directory e ruoli FSMO 71
22. Glossario – Definizioni 74

2
 Cestrone Pasquale

MANUALE START
1. Web Server
Un web server è un applicativo software che gira su di un server fisico in ascolto su porte a lui dedicate, per
comunicare con i client che richiedono i suoi contenuti ed i suoi servizi. La comunicazione tra Client – Server
avviene tramite il protocollo HTTP, che utilizza la porta 8080, oppure tramite la versione più sicura, il
protocollo HTTPS, sulla porta 8443. L’insieme di tutti i Web Server, interconnessi a livello mondiale, dà vita
al World Wide Web.
Nello specifico quando scriviamo un indirizzo internet, il nostro browser la traduce in una richiesta http e la
consegna al server indicato. Riceve poi da questo una risposta http e un file HTML che viene tradotto (si parla
di rendering) sotto forma di testo e immagini per mostrarcelo così a video. Segue un semplice schema del
processo descritto:

Le pagine web interrogate possono essere sia statiche che dinamiche.

• La pagine statiche sono scritte solamente con codice HTML e al loro interno contengono già tutti i
dati che verranno poi mostrati all'utente finale.
• Le pagine dinamiche, invece, oltre ad HTML usano altri linguaggi (PHP, ASP, ecc..), attraverso i quali
sono definite delle istruzioni attraverso le quali viene generato il contenuto della pagina richiesta. In
questo caso è il web server a processare queste istruzioni (presenti sotto forma di script), mostrando
all'utente finale i contenuti generati dinamicamente con l'aspetto predefinito dal programmatore.
Avere l'intero carico di lavoro lato server è molto comodo per l'utente finale, che non deve avere
installato alcun software aggiuntivo oltre al browser e viene sollevato da ogni tipo di elaborazione
con conseguente risparmio di tempo e banda.

Elenco dei server web (software) più diffusi:

• Apache HTTP Server (sviluppato dalla Apache Software Foundation)
• Apache Tomcat (sviluppato dalla Apache Software Foundation)
• Cassini Server Web
• HTTP File Server
• Sun ONE (di Sun Microsystems)

3
 Cestrone Pasquale

MANUALE START
2. Web Application
Tutti noi abbiamo aperto la posta elettronica, effettuato una ricerca con Google o controllato il proprio conto
in una banca online. Ebbene, stavamo utilizzando delle Web Application. E’ impossibile distinguere delle
pagine generate da un server “statico” da quelle generate da una Web Application.
La differenza sta nell’origine delle pagine. Nel primo caso le pagine sono file statici (file .html) che vengono
semplicemente prelevati dal server e visualizzati nel browser. Nel caso di Web Application, invece, le pagine
vengono costruite dinamicamente al tempo della chiamata da un programma che gira sul server e che può
essere scritto in un qualsiasi linguaggio di programmazione.

Ma perché realizzare una Web Application e non un semplice sito statico?

Perché le Web application permettono di fare molto di più. Come farebbe un sito statico a prendere le vostre
username e password, controllare che siano corrette, recuperare da un database i vostri messaggi e
visualizzarli a video dividendoli 10 per pagina? Come farebbe un sito statico a permettervi di rilanciare
sull’asta dell’ultimo cd del vostro cantante preferito fino alla cifra massima da voi impostata?

Una Web application lo può fare e ci può aiutare a risolvere problemi anche molto più complessi. Essa è
composta in genere da una serie di algoritmi che vengono eseguiti sul server e che generano l’output
desiderato.

Un’applicazione Web, nella maggior parte dei casi, si sviluppa su tre livelli logico-funzionali (applicazioni
Three-Tier) ma che possono essere distribuiti anche su più livelli (applicazioni Multi-Tier):

• Livello di presentazione: rappresenta l’interfaccia utente dell’applicazione e si occupa di acquisire

dati e visualizzare risultati;
• Livello intermedio: si occupa delle elaborazioni dei dati in base alla cosiddetta business logic, cioè
all’insieme delle regole per cui i dati sono considerati significativi e le loro relazioni consistenti; le
elaborazioni del livello intermedio generano i risultati richiesti dall’utente. Rappresenta tutte le
funzionalità offerte dall’applicazione Web; costituisce il filtro bidirezionale tra logica di
presentazione e logica dei dati.
• Livello dati: rappresenta l’insieme dei servizi offerti da applicazioni indipendenti dal Web, come ad
esempio un gestore di database, un sistema di gestione di posta elettronica, ecc. Rappresenta la
gestione fisica dei dati (memorizzazione,ricerca ed aggiornamento di dati), compresa la verifica della
loro integrità e completezza.

4
 Cestrone Pasquale

MANUALE START
3. Application Server
L’esecuzione di una Web Application necessita della presenza sul server di un “ambiente”, di un framework
per il supporto dei linguaggi che si vogliono utilizzare per la stesura dell’applicazione lato server. L’ambiente
che ci dà questo supporto è proprio l’Application Server. Questo, a differenza del Web server, non si limita
a rispondere alla richiesta dell’utente con la pagina HTML ma è capace di eseguire degli algoritmi per fare
calcoli, ricerche, memorizzare, ecc. Questo ci permetterà due cose molto importanti:

• Di affiancare alle normali pagine HTML statiche delle pagine dinamiche. Delle pagine, cioè, che
cambieranno il loro aspetto ed il loro contenuto in base a dei parametri che saremo noi a decidere.
Ad esempio potremo costruire una pagina che visualizzi il proverbio del giorno. Se dovessimo
utilizzare il normale HTML saremmo costretti a mettere mano al codice della pagina tutti i giorni e
cambiare la parte di testo relativa al proverbio. Con le pagine dinamiche, invece, tutto ciò potrà
avvenire in automatico, quindi dovremo scrivere la pagina Web una sola volta. Naturalmente il
semplice HTML non sarà più sufficiente, ma sarà affiancato da linguaggi più potenti. Il tipo di
linguaggio da adoperare dipenderà dal tipo di Application server utilizzato e dai Plug-in che vi saranno
installati.
• Di inserire lato server dei veri e propri algoritmi che ricevano dalle pagine Web delle informazioni,
effettuino le opportune elaborazioni e restituiscano i risultati ad altre pagine Web per la
visualizzazione. Anche in questo caso il linguaggio con cui scrivere questi algoritmi dipenderà dalla
logica contenuta dall’Application Server utilizzato.

L'application server è composto da moduli (struttura modulare) realizzati secondo standard ben definiti ed
accettati dalla comunità mondiale dei programmatori. Un esempio di questi standard è il protocollo HTTP,
normalmente utilizzato per la trasmissione di informazioni sul web. Al suo interno, un application server
dispone di componenti che consentono ad una Web Application di lavorare facilmente con lo standard HTTP.
I moduli normalmente presenti in un application server sono:

• modulo web server che espone al client browser la logica di presentazione statica delle applicazioni
e in diretta interazione con la sottostante logica di business;

• contenitore di componenti server-side detti anche logica di business;

• gestore degli accessi degli utenti e della sicurezza;

• gestione accesso a database o in generale a sorgenti di dati esterne;

• gestore transazioni;

• interfaccia per l'accesso ad un sistema legacy;

• altri componenti per massimizzare le prestazioni, come connection pool, load balancer, caching, ecc.

Quali sono le tecnologie disponibili?

Come abbiamo detto esiste un filo doppio che unisce il linguaggio con cui vogliamo realizzare le pagine
dinamiche del nostro sito Web e la sua logica di controllo e l’Application server (per brevità, AS) da utilizzare.
Nello scegliere la piattaforma non siamo sempre liberi, possiamo essere coinvolti in un progetto in cui tutto
è già stato impostato, ad esempio. Con vincoli del genere l’unica cosa da fare è adattarsi e sviluppare nel
linguaggio che impone la condizione.

5
 Cestrone Pasquale

MANUALE START
Se invece saremo noi a scegliere l’AS, potremo sceglierlo tenendo conto anche dei linguaggi che vorremo
utilizzare per scrivere pagine Web ed applicazioni. Cominciando proprio da queste ultime, le 2 famiglie più
diffuse che si contendono la supremazia del Web sono Java e DotNet.

Le due tecnologie hanno parecchio in comune, questo anche perchè il Framework .NET ed i relativi linguaggi
di programmazione sono stati sviluppati molto tempo dopo la nascita di Java e se ne avverte l’influenza
positiva. Ma se è vero che ci sono molti punti in comune, è altrettanto vero che si tratta di piattaforme ben
distinte.

Scegliere una piattaforma infatti non significa solo scegliere un linguaggio di programmazione, ma anche
tutto ciò che lo circonda. Chi usa la tecnologia Microsoft .NET e C#, ad esempio, avrà a che fare con il
Framework .NET, con il Web server IIS e con tutte le estensioni (o filtri) ISAPI che gli permettono di svolgere
le funzioni di application server. In questo caso, sarà configurato il filtro ISAPI per le applicazioni scritte nei
linguaggi per DotNet. IIS arrivato alla versione 6, vanta una fetta pari al 20% di tutti i server presenti nel Web.

Chi invece predilige J2EE ha una gamma più larga di scelte. Infatti esistono versioni della JVM sia per Windows
sia per Linux ed anche il principe degli AS, Jakarta Tomcat, è disponibile per entrambi i sistemi operativi.
Inoltre possiamo scegliere di usare Tomcat in coppia con IIS o Apache su sistemi Microsoft o su Apache per
sistemi Linux. Questo application server open source è usato per quasi il 70% dei server della rete mondiale
ed è la soluzione ottimale per chi sceglie di utilizzare Java e JSP per realizzare il codice delle pagine Web e
della logica.

Il punto forte della coppia Apache Tomcat sta nel fatto che, essendo open source, vantano sul supporto delle
migliaia di comunità di sviluppatori online sparsi nei cinque continenti.

Oltre a quelli appena citati vi sono tantissimi altri AS di tantissime case produttrici di software ed altri open
source. Quasi tutti gli altri sono prodotti molto professionali e quindi rivolti ad una nicchia di clienti di fascia
alta, grosse aziende o grandi organizzazioni. Tra questi nominiamo:

• JBoss, un altro AS open source

• WebSphere, l’AS di casa IBM che vanta innumerevoli estensioni.
• WebLogic, la proposta di BEA, una software house americana specializzata in soluzioni enterprise.
• Oracle GlassFish, la piattaforma per la gestione di enormi quantitativi di dati che include anche un
ottimo Application server.
• Geronimo

Quali sono i vantaggi di un Application Server?

L'adozione di Application Server offre particolari benefici soprattutto nei settori dello sviluppo,
dell'esecuzione e della gestione integrata dei sistemi. I principali vantaggi possono essere così riassunti:

• Semplificazione delle attività di sviluppo: gli application server creano un ambiente nel quale si
possono utilizzare gli strumenti di sviluppo più diffusi sul mercato, consentendo di produrre e
distribuire rapidamente applicazioni transazionali (sistema che mette a disposizione meccanismi per
la definizione e l’esecuzione di transazioni) altamente scalabili. In generale, questi ambienti
comprendono modelli e strumenti di ausilio per sviluppare le applicazioni, riducendo i tempi di
realizzazione e messa in esercizio dei programmi negli ambienti distribuiti.

• Supporto di vari linguaggi, strumenti e piattaforme software: a seconda dell'application server

utilizzato, le applicazioni possono essere scritte nel linguaggio preferito dal programmatore.

6
 Cestrone Pasquale

MANUALE START

• Riusabilità del codice: la riusabilità del codice deriva sia dalla programmazione orientata agli oggetti,
spesso utilizzata in questi casi, sia dall'utilizzo dell'approccio a componenti. Una volta sviluppata la
logica applicativa, essa può essere condivisa e riutilizzata.

• Gestione delle transazioni. L'application server facilita la gestione delle operazioni basate su
transazioni, assicurando l'integrità transazionale e gestione affidabile dei back-end multipli per le
risorse e i dati. Il sistema di gestione delle transazioni gestisce le interazioni con i database e le
funzioni di commit, rollback e recovery.

• Alte prestazioni. Gli application server offrono caratteristiche architetturali che permettono di
erogare elevate prestazioni quali il multithreading, il bilanciamento dinamico dei carichi di lavoro
(load balancing), il caching e il pooling degli oggetti e delle connessioni ai database.

• Scalabilità. Gli application server supportano il partizionamento delle applicazioni e la distribuzione

in rete dei componenti. I sistemi multiprocessore e i cluster di application server assicurano la
scalabilità necessaria a gestire anche un gran numero di utenti concorrenti.

• Estendibilità. L'architettura modulare degli application server e il supporto per i server e per i moduli
applicativi che possono essere caricati dinamicamente, consente alle aziende di estendere
facilmente le funzionalità dei loro sistemi e delle relative applicazioni.

• Robustezza. L'architettura basata sui componenti degli application server e il bilanciamento

dinamico dei carichi assicurano l'alta disponibilità dei sistemi. I componenti del server e la logica
applicativa possono essere riconfigurati, aggiunti o rimossi senza interruzioni nell'erogazione dei
servizi agli utenti. Queste caratteristiche sono particolarmente importanti per garantire l'alta
disponibilità del sistema, requisito necessario!

• Sicurezza. Gli application server offrono funzioni specifiche di sicurezza end-to-end, necessarie per
l'esecuzione delle applicazioni aziendali che richiedono particolari misure di sicurezza e riservatezza
dei dati. Per le comunicazioni tra client e server, vengono impiegati algoritmi standard e ampiamente
testati e collaudati sul web, come quelli offerti dal protocollo SSL. Il logging e il tracking degli eventi
forniscono protezione dagli accessi non autorizzati.

3.1 WebLogic Server (Admin Server)

BEA WebLogic Server è uno degli Application Server più utilizzati tra quelli compatibili con la piattaforma
J2EE. Nell’articolo vedremo l’installazione dell’Application Server per poi passare allo sviluppo e
l’installazione di una semplicissima applicazione web che ci aiuterà a prendere confidenza con le funzionalità
messe a disposizione. Infine affronteremo anche il problema dell’installazione e dell’utilizzo di un EJB di tipo
Session Stateless.

Configurazione di un Dominio

Prima operazione fondamentale successiva all’istallazione dell’Application Server è la creazione di un

Dominio. Si tratta di un gruppo di istanze di WebLogic Server che condividono trà loro diversi settaggi quali
i ruoli, gli utenti e le politiche di sicurezza.

7
 Cestrone Pasquale

MANUALE START
Un Dominio è costituito da almeno un’istanza di WebLogic Server chiamata Administration Server che viene
creata automaticamente in fase di creazione del Dominio. Tutte le altre istanze sono chiamate Managed
Server.

Ciascun Dominio può essere di due tipi:

• Development: riservata agli sviluppatori in quanto utilizza delle politiche di sicurezza meno
complesse e quindi leggermente più veloce. Permette l’auto-deploy delle applicazioni che velocizza
il processo di sviluppo delle applicazioni.

• Production: riservata alle applicazioni ormai collaudate e funzionanti che necessitano di complesse
politiche di sicurezza. Risulta più lenta ma più efficiente da un punto di vista di sicurezza. Durante la
creazione di un nuovo Dominio bisogna specificare le credenziali di accesso che saranno utilizzate
dall’amministratore per accedere al pannello di amministrazione.

Start dell’Application Server

Avviare l’Application Server equivale ad avviare un Dominio. Nella directory

BEA_HOME\user_projects\domains vengono memorizzate le informazioni sui Domini. Ciascun Dominio
creato avrà una sottodirectory che conterrà il file startWebLogic.cmd. Per avviare il Dominio è necessario
lanciare questo file. WebLogic Server utilizza di default la porta 7001 quindi tutte le Web Application che
vengono installate sono raggiungibili dal link http://localhost:7001/ContextRoot.

Una volta fatto ciò è possibile sviluppare un’applicazione e farne il deploy (installazione) per renderla
disponibile all’uso sul server.

8
 Cestrone Pasquale

MANUALE START
4. Directory
Una directory viene considerata, per analogia, un database organizzato, da un punto di vista logico, secondo
una modalità gerarchica. Si tratta di un particolare tipo di database, un database specializzato, che ha
caratteristiche differenti dai tradizionali database relazionali.

Per prima cosa una directory per sua stessa natura riceve quasi esclusivamente accessi in lettura; la fase di
scrittura è limitata agli amministratori di sistema o ai proprietari delle singole informazioni. Per questo
motivo, le directory sono ottimizzate per la lettura, mentre i tradizionali database relazionali devono
supportare sia la lettura sia la scrittura dei dati (ad esempio in un sistema di prenotazioni aeree o in
applicazioni bancarie).

Ne consegue che le directory non sono adatte per immagazzinare informazioni aggiornate di frequente. Ad
esempio, il numero di processi in coda in fase di stampa non va memorizzato in una directory, visto che per
offrire un dato accurato il numero deve essere aggiornato continuamente. La directory può invece contenere
l'indirizzo di una stampante remota che è inserita nel processo di stampa; una volta trovata la stampante con
una ricerca nella directory, si può ottenere poi il numero di processi in attesa. L'informazione nella directory
(indirizzo della stampante) è statica, mentre il numero richiesto è dinamico e quindi non adatto per stare in
una directory.

Un'altra differenza tra directory e database relazionali è che la maggior parte delle implementazioni di
directory non supporta le transazioni, ovvero operazioni atomiche, che devono essere eseguite interamente
o non eseguite per niente, come ad esempio avviene per le operazioni bancarie di trasferimento di denaro.
Sono comunque supportate nel LDAP, anche se sono limitate a transazioni tra directory LDAP e non
includono altre transazioni, come operazioni tra database. I tradizionali database relazionali di solito
supportano queste transazioni, che però complicano la loro implementazione.

Un'altra importante differenza sta nel metodo di accesso alle informazioni. La maggior parte dei database
relazionali supporta un metodo d'accesso potente e standardizzato che è SQL. SQL permette aggiornamenti
e interrogazioni elaborati a discapito delle dimensioni del programma e della complessità dell'applicazione.
Le directory invece, in particolare le directory LDAP, usano un protocollo di accesso semplificato e ottimizzato
che può essere usato in applicazioni snelle e relativamente semplici. Visto che le directory non hanno
l'intento di fornire lo stesso numero di funzioni di un tradizionale database relazionale, possono essere
ottimizzate per consentire a più applicazioni di accedere ai dati in grandi sistemi distribuiti nel modo più
rapido possibile.

Directory client e server

L'accesso alle directory di solito utilizza il modello di comunicazione client/server. Un'applicazione che vuole
leggere o scrivere informazioni in una directory non vi accede direttamente, ma invoca una funzione o
un'interfaccia (API, application programming interface) che genera l'invio di un messaggio ad un altro
processo. Questo secondo processo accede alle informazioni della directory per conto dell'applicazione che
ne ha fatto richiesta via TCP/IP. La porta TCP/IP di default è 636 per le comunicazioni sicure crittografate e
389 per le comunicazioni non crittografate. Il risultato dell'operazione di lettura o di scrittura è restituito
quindi all'applicazione. Una richiesta è di solito fatta dal directory client, e il processo che cerca
l'informazione nella directory è chiamato directory server. In generale, i server forniscono un servizio
specifico ai client. Qualche volta un server può diventare un client di altri server, per ottenere le informazioni
necessarie per soddisfare la richiesta. Client e server possono risiedere o meno sulla stessa macchina.
Un server può soddisfare diversi client; più server possono eseguire richieste in parallelo. Si possono avere
anche code di processi quando i server sono occupati mentre stanno eseguendo un'altra richiesta. Un API
definisce l'interfaccia di programmazione che un particolare linguaggio usa per accedere ad un servizio. Il

9
 Cestrone Pasquale

MANUALE START
formato e il contenuto dei messaggi scambiati tra client e server deve rispettare un protocollo concordato,
come LDAP.
Tipi di directory

Una directory può essere locale o globale, a seconda se si tratti di un'area limitata o estesa all'universo di
interesse, che può essere un'azienda, una nazione o tutto il mondo. I client che accedono ad una directory
possono essere locali o remoti. I client locali si trovano nello stesso edificio, o comunque possono accedere
alla stessa LAN. I client remoti possono invece trovarsi in qualsiasi punto del pianeta.

Una directory inoltre può essere centralizzata o distribuita, a seconda che si tratti di un server in un solo
posto o di più server sparsi. Quando una directory è distribuita, le informazioni contenute possono essere
partizionate o replicate. Quando l'informazione è partizionata, ogni directory server contiene una parte di
informazione unica e non sovrapponibile. Cioè ogni entry della directory è contenuta in uno e un solo server.
Una delle tecniche di partizione è quella di usare riferimenti LDAP; questi permettono agli utenti di rivolgere
le richieste LDAP a server differenti. Quando l'informazione è replicata, la stessa entry è contenuta in più
server. In una directory distribuita ci possono essere informazioni partizionate e replicate insieme. La
distribuzione dei directory server e la modalità in cui i dati sono partizionati o replicati determina il livello di
prestazione e di disponibilità della directory.

10
 Cestrone Pasquale

MANUALE START
5. Directory Service
Identificano uno o più programmi che si occupano di memorizzare, organizzare e gestire informazioni o
risorse centralizzate e condivise, all’interno di reti di computer(e.g. Server, Mainframe..). Inoltre grazie alla
directory service è possibile effettuare un controllo sugli accessi. Banalmente la directory server si interpone
tra l’utente e la risorsa.

DIFFERENZE TRA DIRECTORY E DATABASE RELAZIONALI:

1. Possiamo considerare la directory come un database specializzato a modalità gerarchica. Nelle

directory è possibile quasi esclusivamente accedere in lettura, infatti la modalità di scrittura è limitata
ai soli amministratori di sistema o ai proprietari delle singole informazioni. Ragion per cui le directory
sono ottimizzate per la lettura. Motivati anche dal fatto che le directory non sono adatte per
memorizzare informazioni aggiornate di frequente. Come ad esempio le informazioni nella directory
sono statiche (indirizzo della stampante), mentre il numero di richieste (numero di stampe) sono
dinamiche(no directory).
2. Nella maggior parte delle implementazioni delle directory, non sono supportate le transazioni
(operazioni atomiche, che comportano la modifica dell’intero database). Però sono supportate da
LDAP (solo tra directory LDAP).
3. Riguardo al metodo di accesso alle informazioni, bisogna fare una distinzione:
• Le directory LDAP, utilizzano un protocollo di accesso semplificato ed ottimizzato. Poiché le
directory non sono utilizzate per immagazzinare una grande mole di funzioni (come nei db
relazionali), si ha la necessità di ottimizzarle per consentire a più applicazioni di accedere a
più dati, in grandi sistemi distribuiti (in modo più rapido possibile).
• Il Database relazionale supporta il metodo di accesso SQL (potente e standardizzato).

ACCESSO ALLE DIRECTORY:

Il metodo di accesso alle directory si basa sul modello Client-Server. Dove la richiesta viene effettuata dal
Directory Client, mentre la ricerca delle informazioni è effettuata dal Directory Server. Talvolta il directory
server diventa il client per altri server, per ottenere le informazioni necessarie per soddisfare altre richieste.

Un Server riesce a soddisfare più Client contemporaneamente.

Più Server possono eseguire più richieste in parallelo per un Client.

11
 Cestrone Pasquale

MANUALE START
6. Active Directory
Le Active Directory è un insieme di servizi di rete (directory service) adottati dai SO Windows (a partire da
Windows 2000 Server) e gestiti da un domain controller. Le Active Directory si fondano sul concetto di
Dominio e Directory. Nello specifico possiamo descrivere le active directory come la modalità con cui sono
assegnati agli utenti tutte le risorse della rete, come:

• Account utente
• Account computer
• Cartelle condivise
• Stampanti

Rispettando le assegnazioni imposte dall’amministratore di sistema di group policy (criteri di gruppo).

DESCRIZIONE ACTIVE DIRECTORY:

I servizi di rete di active directory, in particolare il servizio di Autenticazione Kerberos realizzano un’altra
caratteristica importante: Single Sign – ON (SSO), cioè un utente, una volta entrato nel dominio ed effettuato
il login da una qualsiasi macchina di dominio, può accedere a risorse disponibili in rete, come:
• Condivisioni
• Mailbox
• Intranet

Senza dover rieffettuare l’autenticazione!

Un’altra definizione di Active Directory è quella di considerarla come un Framework gerarchico di oggetti
con il compito di gestire un dominio. A tale scopo utilizza vari protocolli:
• Protocolli LDAP
• Protocollo Kerberos
• DNS
• Protocollo DHCP

L’Active Directory include in un unico sistema di monitoraggio tutti gli oggetti del domino, come:
• Risorse(stampanti)
• Servizi(email)
• Utenti(account utenti e gruppi)

Nello specifico svolge le seguenti attività:

• FORNISCE informazioni sugli oggetti
• ORGANIZZA informazioni sugli oggetti
• CONTROLLA gli accessi
• IMPOSTA la security

LDAP IN ACTIVE DIRECTORY:

LDAP in Active Directory viene utilizzato come Base di Dati, dove sono memorizzate, in forma centralizzata,
tutte le informazioni di un dominio di rete. Nello specifico si occupa dell’autenticazione e dell’accesso ai
servizi.

12
 Cestrone Pasquale

MANUALE START
Con quale VANTAGGIO?
Con il vantaggio di mantenere tutte queste informazioni SINCRONIZZATE tra i vari server di autenticazione
di accesso alla rete.
STRUTTURA ACTIVE DIRECTORY:
Strutturalmente possiamo considerare l’Active Directory come un raggruppamento logico di utenti e
computer di domini, gestito centralmente da server detti “Controllori di Dominio”. Gli oggetti sono divisi
per categoria: Risorse, Servizi e Utenti.
Ogni singolo oggetto è identificato da un nome univoco, ed è considerato una singola entità, alla quale
vengono definiti degli attributi (ovvero le caratteristiche e le informazioni che l’oggetto può contenere). Tali
attributi sono definiti da uno Schema, il quale definisce anche i tipi di oggetto che è possibile immagazzinare
nell’Active Directory.
Quindi l’oggetto attributo può essere utilizzato in differenti classi d’oggetto di uno Schema.
L’oggetto Schema, permette allo Schema stesso di essere esteso o modificato. Inoltre la disattivazione (può
essere solo disattivato e no modificato) o la modifica dell’oggetto schema può avere seri conseguenze, poiché
modifica in maniera massiccia la struttura dell’Active Directory.
Per quale motivo? Perché ogni oggetto Schema è esso stesso parte della definizione degli oggetti dell’ Active
Directory.

I SITI:
Il sito è una locazione geografica fisica che ospita reti, inoltre contiene oggetti chiamati sottoreti.
Ma a cosa servono i siti? Sono utilizzati per:
• Assegnare oggetti (politica di gruppo)
• Semplificale l’individuazione delle risorse
• Gestire la replicazione delle Active Service
• Gestire il traffico di collegamento alla rete
Inoltre un sito può essere collegato ad altri siti.
Ai siti possono essere assegnati:
• Costi
o Velocità
o Affidabilità
o Disponibilità
o Altre proprietà di una risorsa fisica
• Pianificazioni

13
 Cestrone Pasquale

MANUALE START
7. Replica di Active Directory e ruoli FSMO
Il database di Active Directory non ha una struttura monolitica ma è organizzato in partizioni o naming
context che identificano strutture gerarchiche di oggetti, ciascuna delle quali costituisce un'unità di
replicazione indipendente. Le partizioni Active Directory possono essere di tipo generale oppure di tipo
applicativo (Active Directory Partition ADP).

Le partizioni generali possono essere di tre specie:

• Schema Partition. Contiene la definizioni degli oggetti (attributi e classi) utilizzabili in Active Directory
(user, group, computer, organizational unit, etc...) e delle regole di utilizzo. Esiste una sola Schema
Partition per ogni ciascuna foresta.

• Configuration Partition. Contiene informazioni generali sulla struttura e la composizione di una

foresta (site, subnet, partizioni che compongono la foresta, dc, etc...). Esiste una sola Configuration
Partition per ogni ciascuna foresta.

• Domain Partition. Contiene informazioni sugli oggetti creati in ogni dominio (user, group, computer,
organizational unit, etc...). Esiste una sola Domain Partition per ogni dominio appartenente alla
stessa foresta.

Le informazioni della Schema Partition e della Configuration Partition sono comuni a tutti i domini della
foresta e quindi verranno replicate a tutti i DC della foresta, mentre le informazioni della Domain Partition
sono private del dominio e quindi verranno replicate solo ai DC dello stesso dominio.

Le partizioni applicative possono essere di due specie:

• ADP builtin. Sono quelle dedicate al DNS (DomainDnsZones e ForestDnsZones) create

automaticamente all'atto della creazione del dominio, nel caso si scelga di installare e configurare il
servizioDNS dal wizard Dcpromo.

• ADP custom o personalizzate. Possono essere create manualmente per ospitare informazioni
riguardanti applicazioni integrate in Active Directory (AD-aware)

Il processo di replica di Active Directory mantiene allineate le Directory Partition dei DC tramite una tipologia
multimaster incrementale che consente di effettuare modifiche su qualsiasi DC e far sì che questo fornisca
agli altri DC soltanto le differenze rispetto all'ultima sincronizzazione avvenuta. Per minimizzare i conflitti
dovuti a modifiche dello stesso oggetto su DC diversi Active Directory implementa la replica a livello di singolo
attributo, I DC, infatti, a seguito di una modifica aggiornano lo stamp associato all'attributo che è compostato
da un Version Number (incrementato ad ogni modifica), un Timestamp (data e ora della modifica) e da un
Server GUID (contenente il GUID del DC su cui è avvenuta la modifica). Nella comparazione degli stamp si
considera il Version Number maggiore, nel caso ugualianza si considera il Timestamp maggiore e se anche il
Timestamp è uguale si valuta il Server GUID.

Allo scopo di evitare conflitti di replica non risolvibilit tramite la comparazione degli stamp, Active Directory
introduce l'amministrazione centralizzata di alcune operazioni, in altre parole alcune attività possono essere
eseguite esclusivamente a seguito dell'autorizzazione data dal DC in possesso del ruolo associato alla
specifica tipologia di operazione. Tali ruoli sono definiti flexible o Floating Single Master Operations (FSMO)
in quanto è possibile spostare un ruolo assegnandolo ad un altro DC.

14
 Cestrone Pasquale

MANUALE START

I ruoli FSMO sono cinque:

• Schema Master. Lo Schema Master è l'unico DC della foresta che possiede una copia i scrittura della
Schema Partition (ciò significa che la modifica dello schema può essere seguita da un qualunque DC,
ma prevede la connessione diretta con lo Schema Master).

• Domain Naming Master. Il Domain Naming Master è unico nella foresta e viene contattato quando è
necessario creare un dominio per verificare che non sia già stato definito e ottenere un identificatore
GUID univoco. Il Domain Naming Master è responsabile anche dell'autorizzazione alla cancellazione
di un dominio, della validazione durante le operazioni di modifica dei nomi di dominio tramite il tool
RENDOM.EXE e della creazione e cancellazione di una Application Directory Partition.

• Relative Identifier Master. Il Relative Identifier Master è unico nel dominio ed è responsabile della
distribuzione dei pool contenenti le sequenze univoche dei Relative ID (RID) ai DC del dominio. I RID
sono utilizzati dai DC durante la creazione degli oggetti Security Principal (User, Group o Computer)
per attribuirgli identificativi Security ID (SID) univoci.Il Relative Identifier Master si occupa anche di
autorizzare lo spostamento di un oggetto in un altro dominio, tramite ad esempio l'Active Directory
Migration Tool, per evitare che lo stesso oggetto possa essere spostato in due domini diversi.I DC del
dominio ricevono un pool di 500 RID dal Relative Identifier Master e quando la quantità disponibile
raggiunge circa le 100 unità il DC contatterà il Relative Identifier Master per ottenere un nuovo pool.
Un SID è composto da 4 elementi S-1-5-Y1-Y2-Y3-Y4:

o S-1 che indica la revisione del SID (al momento è in uso la 1)

o 5 che definisce l'autorità di emissione del SID (5 indica Windows NT, 2000 o 2003 Server, per
i well know SID si utiliza 0 o 1)

o Y1-Y2-Y3 è la porzione del domain SID (uguale per tutti i Security Principal del dominio)

o Y4 rappresenta il relative ID del dominio.

• PDC emulator. il PDC emulator è unico nel domino e viene utilizzato come fonte di replica (master-
slave) degli update della Domain Partition verso i BDC NT nel caso in cui il livello funzionale del
dominio sia Windows server 2003 Interim o Windows 2000 Mixed Mode. il PDC emulator viene
inoltre contattato da client precedenti Windows 2000 su cui non è installato l'Active Directory client
durante la fase di cambio password degli account e per offrire piena compatibilità verso essi. Il PDC
emulator assolve anche la funzionalità di Domain Master Browser e indipendentemente dal livello
funzionale del dominio ha i seguenti compiti:

o Diminuire il tempo di convergenza nei cambi password.

o Essere la fonte di sincronizzazione del Windows Time Service (in una foresta i DC di un
dominio usano il PDC emulator del proprio dominio come time source e a loro volta i PDC
emulator dei vari domini della foresta usano come time source il PDC emulator del Forest
Root Domain il quale può essere sincronizzato su un time server esterno tramite il comando
net time \\servername /setsntp:TimeServer).

15
 Cestrone Pasquale

MANUALE START
o Essere utilizzato di default dallo snap-in di creazione o modifica di un Group Policy Object.

o Autorizzare il raise del livello funzionale del dominio.

• Infrastructure Master. l'Infrastructure Master è l'unico DC nel domino che ha il compito di mantenere
aggiornata la relazione GUID-SID-DN degli utenti/gruppi definiti nei domini esterni a quello di
appertenenze dell'Infrastructure Master, ma utilizzati anche nei gruppi del suo dominio (phantom
record). In caso di modifica del Distinguished Name (DN) (per es. spostamento nel domino) o del SID
(per es. spostamento in altri domini) di tali utenti/gruppi la visualizzazione dei membri dei gruppi che
li contengono non deve produrre incoerenze. Per ottenere tale risultati l'Infrastructure Master
verifica e aggiorna periodicamente eventuali differenze tra il proprio database locale di phantom
record e le informazioni nei Global Catalog server.

16
 Cestrone Pasquale

MANUALE START
8. Protocollo LDAP
LDAP opera su TCP/IP, prima di LDAP, invece, per accedere a dati memorizzati in una directory X.500 un
client doveva supportare il DAP (DIRECTORY ACCESS PROTOCOL),il quale imponeva una notevole
penalizzazione delle risorse in gioco in quanto richiedeva l'utilizzo della specifica OSI(Open System
Interconnection) che oggi é sostituita largamente dalla suite di protocolli TCP/IP ed altri protocolli. LDAP
nasce proprio per sostituire DAP in quanto molto oneroso dal punto di vista dell'impiego delle risorse. LDAP
è client-sever: un client LDAP invia una richiesta ad un server LDAP (sono comunemente definite
due porte TCP per la connessione in chiaro (porta 389) e la connessione cifrata (porta 636).), che processa la
richiesta ricevuta, accede eventualmente ad un directory database e ritorna dei risultati al client. (N.B.: Le
comunicazioni sono sempre iniziate dal client che invia una richiesta alla quale il server deve rispondere).

Che tipo di informazioni possono essere memorizzate in una directory?

Il modello di informazioni di LDAP all'interno di una directory è organizzata in elementi chiamati entry è
basato sulle entry. Un’entry è una collezione di attributi aventi un unico nome globale:
il Distinguished Name (DN). Il DN è usato per riferirsi ad una particolare entry, senza avere ambiguità.
Ogni attributo dell’entry ha un tipo ed uno o più valori. I tipi di solito sono stringhe mnemoniche, come cn per
i common name (i nomi comuni), oppure mail per gli indirizzi di posta elettronica. La sintassi dei valori
dipende dai tipi, così ad esempio abbiamo che il valore di cn potrà essere il nome Valentino Rossi, mentre il
valore di mail potrà essere valentino@honda.com.

Come sono strutturate le informazioni?

In LDAP, le entry di una directory sono strutturate come in una struttura gerarchica ad albero che riflette
confini politici, geografici o organizzativi. Gli elementi (attributi della entry, che hanno un mone e un valore,
es. ou=people) che rappresentano gli stati appaiono in cima all'albero (alla radice); al di sotto di essi ci sono
gli elementi che rappresentano stati e organizzazioni nazionali. Più in basso potrebbero apparire elementi
per rappresentare le divisioni all'interno di una singola organizzazione, singole persone, documenti,
stampanti o qualsiasi altra cosa.

FIGURA 1: LDAP directory tree (nomi tradizionali)

17
 Cestrone Pasquale

MANUALE START
I tipici elementi di un Directory sono:

• utenti: rappresentazione dell'identità digitale assegnata ad un utente, collegata ad una password in

forma di hash, verificata al momento del binding;
• gruppi: permettono di specificare logiche di appartenenza su cui è possibile costruire un controllo
di accessi RBAC, i gruppi possono essere innestati tra loro e l'utente può appartenere a più gruppi;
• organizational unit: è una suddivisione logica dell'organizzazione, permette di specificare
indirettamente la designazione di un utente se collocato al suo interno, ha il limite di prevedere
un'assegnazione 1 a molti, non adattandosi correttamente ai contesti dove gli utenti possono avere
più designazioni contemporaneamente.

L’albero può essere rappresentato anche usando lo schema del DNS. Questa rappresentazione è la più usata:

FIGURA 2: LDAP directory tree (nomi usati in Internet)

Nella struttura ad albero, ad ogni livello esiste un Relative distinguished name (RDN) che identifica
l'elemento in relazione ad un altro (ad esempio ou=people). L'unione di tutti i RDN, presi in successione dal
nodo foglia fino alla radice, costituisce il distinguished name (DN), una stringa che rappresenta
univocamente una entry nella directory. IL DN per l’entrata Barbara Jensen(nella figura 1) può essere ad
esempio:

uid=babs, ou=People, dc=example, dc=com

Un altro esempio di entry basandosi sul primo albero può essere:

"cn=John Doe,ou=people,dc=wikipedia,dc=org"

Ciascuna entry ha una serie di attributi, costituiti dall'associazione attributo-valore; per ogni attributo
possono esserci più valori (si veda l'esempio appena mostratodc). I nomi degli attributi solitamente sono
scelti per essere facilmente memorizzabili, per esempio "cn" per common name, o "mail" per un indirizzo e-
mail. Per esempio, un attributo di tipo mail potrebbe contenere il valore "user@example.com", mentre un
attributo "jpegPhoto" potrebbe contenere una fotografia nel formato (binario) JPEG.

Nomenclatura:
• RDN = Relative distinguished name
• DN = Distinguished Name
• CN = Common Name
• OU = Organizational Unit

18
 Cestrone Pasquale

MANUALE START
• DC = Domain Component
Come si accede alle informazioni?
Il protocollo LDAP definisce servizi per accedere e aggiornare una directory. Fornisce, infatti, operazioni per
aggiungere o cancellare un’entry da una directory, modificare un’entry già esistente, oppure cambiare il
nome dell’entry. L’operazione più usata è, però, quella di ricerca di informazioni all’interno della directory.
LDAP fornisce un efficiente algoritmo di ricerca.
In particolare il client può richiedere le seguenti operazioni:

Bind esegue l'autenticazione

Search esegue una ricerca
Compare esegue un test di confronto tra un valore e il valore
assegnato ad un attributo
Add aggiunge un nuovo oggetto
Delete cancella un oggetto
Modify modifica gli attributi di un oggetto
Modify Distinguished Name (DN) sposta o rinomina un oggetto
Abandon annulla una richiesta inviata in precedenza
Extended Operation richiesta di operazioni estese (definite in altre RFC)
Unbind indica al server di chiudere la connessione (non è
esattamente l'inverso della Bind)
StartTLS estensione per utilizzare Transport Layer
Security (TLS) per eseguire la Bind

Come funziona LDAP?

Il servizio di directory LDAP è basato su un modello client – server. Uno o più server LDAP contengono i dati
che servono a costruire l’albero delle informazioni di una directory, il DIT (Directory Information Tree). La
radice di un DIT è una DSA-specific Entry (DSE) e non una parte dei nomi del contesto: ogni server ha
differenti attributi e valori nella root DSE. Il client si connette al server e gli chiede informazioni. Il server
replica con risposte precise e/o con un puntatore che indica dove il client può accedere ad informazioni
addizionali, tipicamente un altro server LDAP. Il client LDAP può comunicare sia con un server X.500 sia con
un server LDAP. Nelle due figure successive sono rappresentati i due schemi di comunicazione.

FIGURA 3: Schema di comunicazione con un server X.500

19
 Cestrone Pasquale

MANUALE START

FIGURA 4: Schema di comunicazione con un server LDAP

Differenze con database

La sigla LDAP sta per Lightweight Directory Access Protocol ovvero: protocollo "leggero" per l'accesso a
servizi di directory e, come il lettore ha colto nella domanda, ha funzioni in parte simili a quelle di un
database.
La differenza sostanziale può essere cercata nella parola "leggero": si tratta cioè di un sistema che ha alcune
funzioni di un database ma è specializzato in modo da ottimizzare le prestazioni per l'uso attraverso la rete
in operazioni di lettura, lista e ricerca di informazioni contenute in un "server" LDAP, ovvero un sistema che
risponde a richieste di operazioni da parte di "clienti" effettuate mediante il protocollo stabilito.
Un server LDAP consente di effettuare operazioni di inserzione, cancellazione ed aggiornamento dei dati,
come un database generico, ma e' ottimizzato per effettuare operazioni di ricerca ed accesso alle
informazioni.
In sostanza non differisce poi molto da un sistema di database generico; vediamo quindi un po' più in
dettaglio:
• Le informazioni contenute in un server LDAP devono avere una semplice struttura gerarchica.
Immaginiamo di voler gestire un elenco degli studenti italiani in cui i singoli elementi siano identificati
da quattro campi:

1) Provincia, 2) comune, 3) scuola, 4) studente

Ogni elemento (studente) può essere identificato da quattro elementi, ad esempio:

Mauro Rossi, Liceo Michelangiolo, Scandicci, Firenze.

20
 Cestrone Pasquale

MANUALE START
La struttura è rigidamente gerarchica: uno studente può frequentare una sola scuola, un comune
appartiene ad un'unica provincia, ecc.

Un database classico, invece, deve poter trattare strutture di dati in cui le relazioni fra gli elementi
possono essere variamente articolate. Ad esempio già l'organizzazione di una biblioteca richiede
strutture di dati più complesse: un libro può avere un qualunque numero di autori, un autore può
aver scritto più libri ogni volta con coautori diversi, e via complicando.

• Un server LDAP deve poter servire richieste che pervengono attraverso la rete. Le operazioni definite
sono quindi studiate per minimizzare l'occupazione di banda.

Inoltre deve essere dotato di funzioni di autenticazione e protezione, ovvero deve essere protetto
da accessi illeciti e deve poter autorizzare o respingere richieste di operazioni basandosi sull'identità
del cliente, deve poter utilizzare canali "sicuri" per la trasmissione dei dati.

• Un server LDAP deve funzionare indipendentemente dalle caratteristiche dei clienti che richiedono
il servizio.

LDAP è parte integrante dei sistemi di autorizzazione più diffusi, si può dire che ogni organizzazione ne ha
(almeno) uno. I prodotti più diffusi in questo campo sono Microsoft Active Directory, Novell eDirectory
(Novell Directory Services), Oracle Unified Directory, OpenLDAP (opensource) e OpenDJ (opensource).
Inoltre sono disponibili librerie per qualsiasi linguaggio di programmazione, rendendone semplice
l'integrazione in un qualunque sistema software.

Probabilmente a causa di questa semplicità di integrazione questa tecnologia viene spesso utilizzata in modo
inappropriato, sfruttandola per implementare anche il processo di autenticazione, a discapito dei meccanismi
visti in precedenza. Il binding LDAP è infatti l'operazione che permette di accedere al Directory specificando
l'identità dell'utente e le credenziali per accedervi. Se questa operazione viene mediata da un altro sistema
software (es. un web service o un'applicazione web che hanno accesso al Directory), quest'ultimo può
efficacemente verificare l'identità fornita da un utente.

Il problema di questa modalità, rispetto ad una soluzione sicura come Kerberos, è che espone le credenziali
dell'utente al sistema software (non necessariamente trusted, o con livelli di manutenzione adeguata alla
delicatezza del ruolo).

21
 Cestrone Pasquale

MANUALE START
9. Single Sign-On
Il Single sign-on (SSO, traducibile come autenticazione unica o identificazione unica) è la proprietà di un
sistema di controllo d'accesso che consente ad un utente di effettuare un'unica autenticazione valida per più
sistemi software o risorse informatiche alle quali è abilitato.

Gli obiettivi sono multipli:

• semplificare la gestione delle password: maggiore è il numero delle password da gestire, maggiore
è la possibilità che vengano utilizzate password simili le une alle altre e facili da memorizzare,
abbassando così il livello di sicurezza;

• semplificare la gestione degli accessi ai vari servizi;

• semplificare la definizione e la gestione delle politiche di sicurezza.

Architettura
Vi sono tre approcci per la creazione di un sistema di SSO: l'approccio centralizzato, l'approccio federativo e
l'approccio cooperativo.

Approccio centralizzato
Il principio è di disporre di un database globale e centralizzato di tutti gli utenti e di centralizzare allo stesso
modo la politica della sicurezza. Questo approccio è destinato principalmente ai servizi dipendenti tutti dalla
stessa entità, per esempio all'interno di una azienda.

Approccio federativo
Con questo approccio differenti gestori ("federati" tra loro) gestiscono dati di uno stesso utente. L'accesso
ad uno dei sistemi federati permette automaticamente l'accesso a tutti gli altri sistemi.
Un viaggiatore potrebbe essere sia passeggero di un aereo che ospite di un albergo. Se la compagnia aerea e
l'albergo usassero un approccio federativo, potrebbero stipulare un accordo reciproco sull'autenticazione
dell'utente finale. Il viaggiatore potrebbe ad esempio autenticarsi per prenotare il volo ed essere autorizzato,
in forza di quella sola autenticazione, ad effettuare la prenotazione della camera d'albergo.
Questo approccio è stato sviluppato per rispondere ad un bisogno di gestione decentralizzata degli utenti:
ogni gestore federato mantiene il controllo della propria politica di sicurezza.

Approccio cooperativo
L'approccio cooperativo parte dal principio che ciascun utente dipenda, per ciascun servizio, da uno solo dei
gestori cooperanti. In questo modo se si cerca, ad esempio, di accedere alla rete locale, l'autenticazione viene
effettuata dal gestore che ha in carico l'utente per l'accesso alla rete.
Come per l'approccio federativo, in questa maniera ciascun gestore gestisce in modo indipendente la propria
politica di sicurezza. L'approccio cooperativo risponde ai bisogni di strutture istituzionali nelle quali gli utenti
sono dipendenti da una entità, come ad esempio in università, laboratori di ricerca, amministrazioni, etc.

Soluzioni per SSO

Esistono molti SSO gratuiti e commerciali, eccone una lista parziale:

• Il JA-SIG Central Authentication Service (CAS) (https://www.apereo.org/projects/cas) è un servizio

single sign-on libero (originariamente sviluppato dall'Università di Yale) che permette alle
applicazioni web la possibilità di rinviare tutte le autenticazioni a un server centrale o a più server di

22
 Cestrone Pasquale

MANUALE START
fiducia. Numerosi client sono disponibili gratuitamente, inclusi client per Java, Microsoft
.Net, PHP, Perl, Apache, uPortal, Liferay (http://www.liferay.com) e altri.

• A-Select è il sistema di autenticazione Olandese co-sviluppato da SURFnet (l'olandese NREN). A-

Select ora è diventata open source ed è usata dal Governo Olandese per esempio per DigiD, il loro
sistema di autenticazione. A-Select (http://www.openaselect.org/trac/openaselect/) permette allo
staff e agli studenti di ottenere l'accesso a svariati servizi web attraverso una sola autenticazione on-
line. Le istituzioni possono usare A-Select per proteggere le loro applicazioni web in maniera
semplice. Possono usare differenti strumenti di autenticazione che vanno dal username/password a
metodi più sicuri come una one-time password mandata a un cellulare o a un'autenticazione
bancaria su Internet.

• CoSign è un progetto open source, originariamente destinato a dotare l'Università del Michigan di
un sicuro sistema di autenticazione web di tipo single sign-on. CoSign permette di autenticare gli
utenti sul web server e poi fornisce un campo variabile lo users'name. Quando l'utente accede a una
parte del sito che richiede l'autenticazione, la presenza di questa variabile permette l'accesso senza
doversi loggare nuovamente. CoSign è parte del software lancio del National Science Foundation
Middleware Initiative (NMI http://www.nsf-middleware.org/default.aspx).

• Enterprise single sign-on (E-SSO), chiamato anche legacy single sign-on, dopo una prima
autenticazione utente, intercetta i prompt del login presentati da una applicazione secondaria e li
inserisce automaticamente nei campi come un loginID o una password. Il sistema E-SSO tiene conto
dell'interazione con le applicazioni che sono incapaci di tirar fuori l'autenticazione, fatta
precedentemente dall'utente, essenzialmente attraverso lo "screen scraping".

• Il Web single sign-on (Web-SSO), anche chiamati Web Access Management (Web-AM), lavora
strettamente con le applicazioni e le risorse che hanno accesso a un web browser. L'accesso alle
risorse web è intercettato sia usando un web proxy server o installando un componente su ogni web
server stabilito. Gli utenti non autorizzati, che tentano di accedere a una risorsa, vengono deviati
verso un servizio di autenticazione e ritornano solo dopo aver effettuato con successo un single sign-
on. I Cookies sono usati molto spesso per tracciare lo stato di autenticazione dell'utente;
l'infrastruttura Web-SSO estrae le informazioni dell'identificazione dell'utente dagli stessi cookies,
passandole ad ogni risorsa web.

• Kerberos è un meccanismo conosciuto alle applicazioni e serve per estrarre interamente le

autenticazioni. Gli utenti si registrano sul server Kerberos, il quale rilascia un "biglietto da visita", che
il loro client software presenterà ai server a cui loro tenteranno di accedere. Kerberos è disponibile
per Unix, per Windows e per piattaforme di elaborazione dati, ma richiede ampie modifiche al codice
dell'applicazione client/server, perciò non è usato da molte "legacy application".

• Federation è un nuovo approccio, anche per applicazioni web, che usa un protocollo basato su degli
standard che permette a una applicazione di accertare una sola volta l'identità di un utente di servizi
diversi, in modo tale da evitare il bisogno di autenticazioni ridondanti. Gli standard per supportare
Federation includono SAML e WS-Federation (http://www-
128.ibm.com/developerworks/library/specification/ws-fed).

23
 Cestrone Pasquale

MANUALE START
• Light-Weight Identity e Open ID, sotto la protezione di YADIS, offrono SSO ripartiti e decentralizzati,
dove l'identità è legata a una URL eseguita facilmente, che può essere verificata da qualsiasi server
che usi uno dei protocolli condivisi.

• JOSSO o Java Open Single Sign-On è un'infrastruttura SSO open source basata su J2EE, che punta a
trovare una soluzione per piattaforme centralizzate di autenticazione dell'utente neutrale. JOSSO usa
i servizi web per accertare l'identità dell'utente, permettendo l'integrazione di applicazioni non-Java
(cioè PHP, Microsoft ASP, ecc.) al Servizio Single Sign-On usando il protocollo SOAP sopra il
protocollo HTTP.

• Shibboleth System è un pacchetto software opensource, basato su standard, per il web SSO tra
organizzazioni o all'interno di un'organizzazione (sistema sviluppato da Internet2)

Principi fondamentali del Single Sign-On

24
 Cestrone Pasquale

MANUALE START

25
 Cestrone Pasquale

MANUALE START

26
 Cestrone Pasquale

MANUALE START

27
 Cestrone Pasquale

MANUALE START

28
 Cestrone Pasquale

MANUALE START

29
 Cestrone Pasquale

MANUALE START

30
 Cestrone Pasquale

MANUALE START

31
 Cestrone Pasquale

MANUALE START
10. CA Siteminder
CA SiteMinder offre affidabilità, disponibilità, scalabilità e gestibilità senza paragoni. Gold standard de facto
per la gestione dell’accesso via Web di classe enterprise, la linea di prodotti CA SiteMinder offre una soluzione
completa che risponde all’esigenza fondamentale di strumenti automatizzati per gestire in modo
centralizzato gli utenti Web e il loro accesso ad applicazioni, servizi Web, portali e servizi cloud.

CA SiteMinder offre la gestione centralizzata della sicurezza necessaria all’organizzazione per autenticare gli
utenti e controllare l'accesso ad applicazioni e portali Web. All’interno delle applicazioni Internet e Intranet,
consente una delivery protetta di informazioni e applicazioni essenziali a dipendenti, partner, fornitori e
clienti. Inoltre è scalabile, per soddisfare le esigenze di business in crescita con strumenti di gestione flessibili,
in grado di supportare l'amministrazione centralizzata o distribuita. CA SiteMinder consente di costruire e
gestire siti Web sicuri.

Funzionalità principali
Single Sign-On (SSO): CA SiteMinder elimina le problematiche poste dai login utente multipli, consentendo il
single sign-on per un accesso senza soluzione di continuità tra più applicazioni Web, portali e domini di
sicurezza diversificati. Anche l'accesso senza problemi alle applicazioni enterprise come SharePoint, SAP,
Siebel, PeopleSoft e Oracle è supportato dalle capacità SSO di CA SiteMinder. L'integrazione con CA Single
Sign-On (CA SSO), il componente SSO enterprise della soluzione CA Identity & Access Management, consente
agli utenti di autenticarsi una volta sola per avere quindi accesso alle applicazioni Web protette da CA
SiteMinder WAM e alle applicazioni non Web, con accesso controllato da CA SSO.

Robusta gestione dell’autenticazione: CA SiteMinder offre una strategia unificata di autenticazione per
garantire il giusto livello di sicurezza all’interno delle applicazioni Internet e Intranet. Questo assicura che le
applicazioni di valore elevato siano protette mediante metodi di autenticazione più solidi, mentre quelle di
valore inferiore potranno essere tutelate da più semplici approcci nome utente/password. CA SiteMinder
offre supporto per la gestione degli accessi per molti sistemi di autenticazione, inclusi password, token,
certificati X.509, smart card, moduli personalizzati, biometria, nonché combinazioni tra più metodi. In
aggiunta, CA SiteMinder consente l’integrazione del contesto di autenticazione nelle policy di autorizzazione.
Ad esempio, quando due metodi di autenticazione sono in uso da parte di una determinata organizzazione
(ad esempio nome utente/password e token con password one-time) e l’utente si autentica con la password
one-time, è possibile che gli vengano concessi diritti più ampi sull’applicazione.

Autorizzazione basata su policy, audit e reporting centralizzati: CA SiteMinder centralizza la gestione degli
accessi per clienti, partner e dipendenti, attraverso applicazioni Web aziendali. Questo elimina la necessità
di una logica di sicurezza ridondante e specifica per singole applicazioni, fornendo un approccio a basso costo
per garantire la capacità dell’azienda di soddisfare i requisiti di conformità. Le policy di CA SiteMinder sono
regole o gruppi di regole che consentono o negano l'accesso a una risorsa. L'accesso può essere limitato
mediante attributi utente, ruoli, gruppi e gruppi dinamici, e determinato in base a criteri geografici o
temporali. L'autorizzazione può avvenire a livello di file, pagina o oggetto. In aggiunta, la policy prevede anche
la "sostituzione di persona" controllata, in cui uno degli utenti autorizzati, ad esempio un rappresentante del
servizio clienti, può accedere alle risorse accessibili da un altro utente. Motore integrato di analisi delle policy,
sistema di reporting e report out-of-the-box supportano le esigenze in evoluzione dell’organizzazione, in
termini di reporting su governance e conformità.

Autorizzazione dinamica: Attiva policy di sicurezza che valutano i dati in tempo reale da una varietà di fonti
locali o esterne, compresi servizi Web e database, per determinare se autorizzare o vietare l’accesso.
Un’autorizzazione più granulare viene ottenuta attraverso la valutazione contestuale, ad esempio limitando
l'accesso a una specifica applicazione (un determinato servizio bancario) ai clienti che rispondono a criteri

32
 Cestrone Pasquale

MANUALE START
specifici (un saldo minimo sul conto). Le policy di autorizzazione possono essere applicate anche in
combinazione con sistemi esterni, quali sistemi di sicurezza basati su rischio.

Gestibilità di classe enterprise: CA SiteMinder offre strumenti di gestione del sistema di classe enterprise,
che forniscono al personale responsabile della sicurezza la possibilità di monitorare, gestire e mantenere più
ambienti in modo più efficiente, compresi ambienti di sviluppo, test e produzione. Questi strumenti
convergenti includono:

• Installazioni automatiche
• Monitoraggio operativo
• Aggiornamenti rolling
• Gestione centralizzata mediante agente Web
• Astrazione della gestione delle applicazioni
• Gestione delegata e separata
• Interfaccia utente amministrativa basata su Web
• Migrazione delle policy di protezione
• Aree di sicurezza
• Capacità di scripting dell’interfaccia

CA SiteMinder è parte della generale strategia di supporto di virtualizzazione di CA, all’interno della quale le
piattaforme della matrice di supporto prodotti sono supportate anche in ambienti virtuali.

Scalabilità e affidabilità: CA SiteMinder è scalabile, per soddisfare requisiti di sicurezza di classe enterprise
in termini di numero di utenti e numero di risorse protette, con assicurando così la possibilità di gestire la
crescita, anche derivante da acquisizioni o partnership. CA SiteMinder è utilizzabile per distribuire
applicazioni business-critical a popolazioni composte da svariati milioni di utenti, con la sicurezza di
prestazioni verificate da test indipendenti, per fornire livelli di velocità delle transazioni, affidabilità e facilità
di gestione significativamente più elevati rispetto alle soluzioni alternative. Affidabilità, disponibilità e
scalabilità sono supportate da funzioni come:

• Bilanciamento del carico dinamico

• Caching bilivello
• Clustering server con policy e failover cluster-to-cluster
• Replica dell’archivio utenti e policy
• Supporto per server SMP a 4 e 8 vie

Accesso sicuro ad applicazioni cloud e siti partner: CA SiteMinder fornisce inoltre una capacità
architettonicamente integrata, concessa in licenza separata, per la federazione basata su browser: gli utenti
possono passare in modo sicuro dai propri siti di partenza (provider di identità) a siti Web ospitati da partner,
clienti e fornitori cloud (service provider). I clienti CA SiteMinder possono interpretare il ruolo di entrambi i
siti web in una federazione. La funzionalità, denominata CA Federation Manager, offre una piattaforma
flessibile e robusta per la federazione delle identità, consentendo alle organizzazioni di sfruttare i vantaggi
del collegamento tra applicazioni di business distribuite in più domini, senza sacrificare la sicurezza. CA
Federation Manager supporta un set completo di standard di federazione, inclusi Security Assertion Markup
Language (SAML) e WS-Federation/Microsoft ADFS. Consente una completa federazione bidirezionale da un
unico sistema di sicurezza Web, con la massima interoperabilità tra le imprese partner. Inoltre, CA SiteMinder
può essere ampliato per garantire la sicurezza dei servizi Web, attraverso l'aggiunta di CA SOA Security
Manager.

33
 Cestrone Pasquale

MANUALE START

CA SiteMinder supporta l’attività online, aumenta la soddisfazione degli utenti, riduce i costi e migliora
controllo e sicurezza IT: L’attività sul Web non si ferma mai e CA SiteMinder consente, in modo efficace e
affidabile, una presenza online sicura, disponibile e accessibile agli utenti giusti. Riconosciuto per le più
avanzate funzionalità di gestione della sicurezza e di amministrazione di siti di classe enterprise, CA
SiteMinder è scalabile, per supportare milioni di utenti e migliaia di risorse protette. CA SiteMinder consente
di raccogliere la sfida della distribuzione delle risorse attraverso il Web, pur mantenendo prestazioni elevate
e alta affidabilità. Controlla chi è in grado di accedere a quali applicazioni e in quali condizioni, migliora
l'esperienza online degli utenti e semplifica l'amministrazione della sicurezza. Applicando le policy,
monitorando e riferendo sulle attività online e sui privilegi degli utenti, CA SiteMinder facilita anche la
conformità alle normative.

34
 Cestrone Pasquale

MANUALE START
Diritti corretti agli utenti corretti: Con CA SiteMinder, la gestione sicura delle identità attraverso sistemi Web
diversificati comporta il controllo de gli accessi da parte del sistema attraverso il contesto degli utenti in
relazione al business (partner, consulenti, clienti...) e i loro diritti verso ogni applicazione. CA SiteMinder
consente agli utenti di connettersi alle informazioni e alle applicazioni di cui hanno bisogno per svolgere il
proprio lavoro, eseguire un ordine o comunque svolgere le operazioni relative all’attività.

Aumentare la sicurezza per ridurre i rischi: CA SiteMinder riduce il rischio di accessi non autorizzati alle
risorse critiche e alle informazioni sensibili, proteggendo il contenuto di un intero portale Web o set di
applicazioni. L’applicazione centralizzata della sicurezza e gli algoritmi di crittografia certificati FIPS
comportano l’assenza di punti deboli in un ambiente Web protetto da CA SiteMinder.

Offrire agli utenti un’esperienza online positiva: CA SiteMinder consente agli utenti di eseguire il login una
sola volta per accedere alle applicazioni Web, coinvolgendoli in un'esperienza online unica e personalizzata,
anziché imporre frustranti login multipli.

Aumentare le opportunità di business: CA SiteMinder consente di distribuire in modo sicuro le applicazioni

Web a più comunità di utenti diversificate, consentendo maggiori opportunità commerciali, con potenziale
aumento dei ricavi. Ampliare CA SiteMinder con la federazione delle identità significa, per l’organizzazione,
poter migliorare la collaborazione con i partner, e quindi i rapporti, per aumentare i profitti, gestire i costi e
ridurre i rischi.

Gestire i costi: CA SiteMinder riduce i costi di amministrazione dell’IT, ma anche il peso della sicurezza sugli
utenti, e quindi il carico di lavoro sull'help desk derivante da credenziali perse o dimenticate. Inoltre, riduce
i costi di sviluppo e manutenzione di applicazioni di sicurezza ridondanti.

Facilitare la conformità normativa: La gestione delle policy centralizzata, l’applicazione, il reporting e

l’auditing supportano la capacità di conformarsi con le normative aventi impatto sull’IT.

35
 Cestrone Pasquale

MANUALE START
Compatibilità CA SSO:
L'applicativo CA Single Sign-ON offre una soluzione sicura di single sign-on , oltre ad un gestione flessibile
degli accessi alle applicazioni o alle web services on-premise(installate localmente), in cloud, da un
dispositivo mobile o da un sito aziendale.

Nello specifico CA-SSO:

• Accelera la disponibilità delle applicazioni offrendo una gamma di opzioni per la gestione
dell'accesso alle applicazioni.
• Potenziare la sicurezza, fornendo un livello di accesso policy comune e un controllo centralizzato
della gestione degli accessi
• Supporta applicazioni web tradizionali, standard di federazione (unione di due o più stati autonomi
sotto un organismo centrale ) delle identità e servizi web, il tutto da un’unica piattaforma integrata
ad alte prestazioni.
Nell’ambiente CA SSO sono incluse molte componenti. Alcune componenti sono richieste per proteggere le
risorse, mentre altri sono opzionali, o solo per implementare specifiche caratteristiche. Queste componenti
funzionano con le risorse, le applicazioni, le directory e database dell’organizzazione per fornire un accesso
sicuro alle risorse nella rete aziendale.

Il tuo ambiente Enterprise:

Le implementazioni di CA SSO sono altamente dipendenti dall’ambiente in cui sono utilizzate. E’ molto
raccomandato sviluppare un piano che scomponga in step l’implementazione, che abbia senso per
l’impresa. Mentre si pianifica la distribuzione, ci sono molte questioni da considerare:

• Sistemi Operativi:
Le componenti di CA SSO sono supportate da molte piattaforme:

o Microsoft® Windows®

o Oracle® Solaris™

o Red Hat® Enterprise Linux®

o Novell® SUSE® Linux

o Hewlett–Packard Company UNIX (HP–UX)

o IBM® AIX®

o IBM z/OS®

• Fornitori di Web Server

E’ possibile installare e configurare CA SSO per proteggere le risorse sui web server

o Apache™ HTTP Server

o Apache Tomcat

36
 Cestrone Pasquale

MANUALE START
o Hewlett–Packard Company (HP) Apache

o IBM HTTP Server

o IBM Lotus® Domino

o Microsoft IIS

o Oracle® HTTP Server

o Red Hat Apache

o Sun Java™ System

• Fornitori di Application Server

È possibile installare e configurare CA Single Sign-On agents per proteggere le risorse sui server
applicazioni J2EE

o Oracle WebLogic®

o IBM WebSphere®

o RedHat JBoss®

• Sistemi di pianificazione delle risorse aziendali

È possibile installare e configurare gli Agents per proteggere le risorse sui sistemi ERP

o Oracle PeopleSoft®
o Oracle Siebel®

o SAP®

• Le Directory Server e i Database

Gli archivi di dati di CA Single Sign-On sono supportati su più server di directory e database

Componenti e Archivi
Lo scopo del seguente diagramma è quello di illustrare i componenti principali in un ambiente CA Single
Sign-On e le loro relazioni generali tra loro:

37
 Cestrone Pasquale

MANUALE START
Descrizione delle componenti del precedente diagramma:

• Policy Server (Richiesto): Un Policy Server opera come punto di decisione Policy (PDP è un
componente di un sistema di controllo degli accessi basato su policy che determina se autorizzare o
meno la richiesta di un utente, in base alle informazioni disponibili (attributi) e alle politiche di
sicurezza applicabili). Lo scopo del Policy Server è valutare ed applicare le politiche di controllo
degli accessi, che successivamente comunica ad un CA Single Sign-On Agent. Un Policy Server
fornisce le seguenti funzionalità:
o Gestione degli utenti basata su determinati criteri
o Servizi di Autenticazione
o Servizi di Autorizzazione
o Servizi Password
o Gestione delle sessioni
o Servizi di controllo/verifica

Il Policy Server interagisce con tutte le altre maggiori componenti.

• CA Single Sign-On Agents (Richiesto): Un Agent (Un'entità software che entra in azione al verificarsi
di una determinata condizione e che svolge un compito per conto di un'altra entità software
oppure per conto di una persona che l'ha delegata a svolgerlo) può risiedere su un web server, su
un sistema Enterprise Resource Planning (ERP è un software di gestione che integra tutti i processi
di business rilevanti di un'azienda (vendite, acquisti, gestione magazzino, contabilità ecc.), ad
esempio si sono sviluppate applicazioni che aiutano i business manager ad implementare
questa metodologia nelle attività di business, quali il controllo di inventari, il tracciamento degli
ordini, il servizi per i clienti, la finanza e le risorse umane.) o su un’applicazione custom. Un
Agent agisce come Policy Enforcement Point (PEP protegge una risorsa e ne permette l'accesso
solo se la verifica di compatibilità con la policy è positiva), intercettando le richieste di risorse
degli utenti e comunicando con il Policy Server per verificare se la medesima richiesta risulta
protetta. Se la risorsa NON E’ protetta, allora l’ Agent permette l’accesso. Invece nel caso in cui
la risorsa E’ protetta l’Agent continua a comunicare con il Policy Server per autenticare e
autorizzare gli user. Un’autorizzazione corretta spinge l’Agent a lasciare che la richiesta di
risorsa arrivi al Server. Inoltre gli Agent:
o Fornire informazioni alle applicazioni Web per abilitare la personalizzazione del contenuto
o Cache informazioni su utenti autenticati e risorse protette per consentire un accesso più
rapido alle risorse
o Abilitano il Single Sign-ON
• CA Single Sign-On Web Services Security Agents (Richiesta per CA SSO Web Services Security): Il
Web Services Security Agent (WSS è un’ estensione di SOAP per estendere la sicurezza ai servizi
web ed è una specifica redatta da OASIS. Il protocollo specifica come può essere rafforzata
l'integrità e la confidenzialità e permette la comunicazione di vari token di sicurezza, come
SAML, Kerberos e X.509. Il principale obiettivo è l'utilizzo della firma XML e della crittazione
XML per garantire la sicurezza end-to-end) agisce come Policy Enforcement Points, che lavora
con le seguenti piattaforme:
o Web server

38
 Cestrone Pasquale

MANUALE START
o J2EE application server

o Custom application

Gli agenti WSS intercettano le richieste di servizi web "grandi" (basati su SOAP). Gli agenti WSS
comunicano quindi con un Policy Server per determinare se la risorsa è protetta. Se la risorsa NON
E’ protetta, allora l’Agent permette l’accesso. Se la risorsa E’ protetta, l’Agent continua a
comunicare con il Policy Server per autenticare e autorizzare gli user. Un’autorizzazione corretta
spinge l’Agent a lasciare che la richiesta di risorsa arrivi al Server. Gli Agent eseguono anche
altre funzioni:
o Cache informazioni su utenti autenticati e risorse protette per consentire un accesso più
rapido alle risorse
o Abilitano il Single Sign-ON
• CA Business Intelligence (Opzionale): CA Business Intelligence è un set di software di reporting e di
analisi, utilizzato da vari prodotti CA, con lo scopo di presentare informazioni e supportare le
decisioni aziendali. Nello specifico i prodotti CA utilizzano CA Business Intelligence per integrare,
analizzare e presentare, attraverso le varie funzionalità di reporting, le informazioni necessarie per
una gestione IT aziendale efficace.
CABusiness Intelligence include SAP BusinessObjects Enterprise, il quale fornisce una complete
suite di gestione delle informazioni, di reporting, e strumenti di query e analisi. CA Business
Intelligence installa SAP BusinessObjects Enterprise come componente autonomo. Questo
componente autonomo viene indicato come Server di Report. L’installazione del Server di Report è
passo separato nel processo di installazione generale.
Il Server di Report compila i report per aiutare ad analizzare l’ambiente CA SSO. Lo scopo di questo
componente è quello di creare i seguenti report:
o Revisione
o Analisi Policy
Per compilare i report il Report Server comunica con le seguenti componenti:
o Il database Central Management Server (CMS – Database di report)
o L’ Administrative UI
o Il Policy Server
o Il database di controllo CA SSO

• Data Stores: L’implementazione CA SSO contiene molti data store. Alcuni sono richiesti, mentre
altri sono opzionale e alcuni sono richiesti solo per implementare specifiche funzionalità.

• Policy Store(Richiesto): Il Policy Store CA-SSO è un deposito dei diritti che risiede in un server di
directory LDAP o in un database ODBC. Lo scopo principale di questo componente è quello di
memorizzare tutti gli oggetti policy-related, includendo:
o Le risorse protette CA SSO
o I metodi usati per proteggere queste risorse
o Gli User o i Gruppi che possono o non possono accedere a queste risorse
o Le azioni che si verificano quando gli utenti ottengono o non ottengono l’accesso a queste
risorse protette
Il Policy Server utilizza queste informazioni, note collettivamente come Enterprise Policy
Management (EPM) o policy, per determinare una risorsa è protetta e se un utente autenticato è
autorizzato ad accedere alle risorse richieste.

39
 Cestrone Pasquale

MANUALE START
• User Store (Richiesto): Una connessione all’ User Store CA SSO è una connessione ad una
directory utente o database esistente nella rete aziendale. Non è necessario utilizzare un user store
proprietario CA SSO. Lo scopo della connessione User Store è rendere i dati utenti disponibili al
Policy Server, che include:
o Informazioni organizzative
o Gli attributi dell’user e del gruppo
o Le credenziali dell’user, come la password
o Gli attributi dell’user come nome e cognome
Il Policy Server usa questa connessione per:
o Verificare le credenziali dell’user quando un Agent inoltra una richiesta per una risorsa
protetta
o Recuperare gli attributi dell’utente, per le funzionalità CA SSO, le quali richiedono dati
utente specifici

• Administrative User Store esterno(Opzionale): Per impostazione predefinita, l’ Administrative UI

usa il policy store come origine per le credenziali di amministratore di CA SSO.
Questa configurazione di default consente di gestire l’ambiente subito dopo la configurazione di un
policy store e l’installazione dell’Administrative UI. Quando si configura un policy store, viene
creato l’account super-utente CA SSO predefinito, chiamato Siteminder. Questo account possiede
tutti i privilegi di sistema e viene utilizzato per accedere all’Administrative UI per la prima volta e
per creare ulteriori amministratori di CA SSO. E’ possibile configurare l’Administrative UI per
utilizzare un administrator user store esterno, ad esempio una directory aziendale. Un
Administrative User Store esterno è una connessione ad un server di directory LDAP o ad un
database ODBC nella rete aziendale. Considera le seguenti informazioni:
o Un Administrative UI può solo connettersi ad un singolo Administrative User Store
o Un Administrative UI può essere configurato per gestire molti Policy Server. Se un
Administrative UI deve gestire molti Policy Server, è necessaria una connessione ad un
administrator user store esterno
o Se si configura più di un’Administrative UI per high-availability (disponibilità elevata), lo
stesso administrative user store esterno rende tutti gli amministratori disponibili per
ciascuna Administrative UI.

• Key Store(Richiesto): Lo scopo di questo componente è di memorizzare le chiavi criptate che i

Policy Server e gli Agent usano per crittografare i dati sensibili. Queste sono:
o Le chiavi che gli Agent utilizzano per crittografare i cookie di CA SSO
o Le chiavi che il Policy Server utilizza per crittografare le informazioni sensibili del policy
store, come le password dell’amministratore.
o Le chiavi che il Policy Server utilizza per crittografare i ticket di sessione , i quali contengono
credenziali e altre informazioni correlate alle sessioni utente
E’ possibile collocare la key store con il policy store, oppure è possibile archiviare le chiavi
crittografiche in una directory o database separato. La necessità di distribuire un key store separato
dipende da:
o Come si implementa il Policy Server e il Policy Store
o Requisiti Single Sign – On
o

40
 Cestrone Pasquale

MANUALE START
• Certificate Data Store(Opzionale): Il Certificate Data Store(CDS) rende disponibili i seguenti
componenti e funzioni per un ambiente CA SSO:
o I certificati del Certificate Authority (CA)
o Chiavi pubbliche e private
o Certificate Revocation Lists(CRL – elenco di revoche di certificati)
o Controlli di revoca OCSP (è un protocollo che permette di verificare la validità di
un certificato senza ricorrere alle liste di revoca dei certificati)

NOTE: Le funzionalità di federazione CA SSO utilizzano il Certificate Data Store. I

certificati utente, che lo schema di autenticazione del X.509 Certificate utilizza per
l’autenticazione, non sono memorizzati nel Certificate Data Store. Mentre questi
certificati utenti sono memorizzati in una directory LDAP/AD o in un ODBC Store(è un
driver o connettore attraverso un'API standard per la connessione dal client al DBMS.
Questa API è indipendente dai linguaggi di programmazione, dai sistemi di database e
dal sistema operativo).

Per impostazione predefinita, il certificate data store è configurato automaticamente e collocato

nel Policy Store. Di conseguenza:
o Non è richiesto uno store esterno separato
o Tutti i Policy Server che condividono una vista comune nello stesso policy store, hanno
accesso alle stesse chiavi, agli stessi certificati e alle stesse liste certificate revocation.
o Tutti gli amministratori che gestiscono lo stesso policy store possono gestire il certificate
data store centralmente, utilizzando l’Administrative UI.

• CA SSO Audit Database (Opzionale): Per impostazione predefinita, il Policy Server scrive gli audit
events (gli eventi di controllo) su un file di testo, noto come Policy Server Log. Lo scopo degli audit
log è tracciare le informazioni su tutte le attività degli utenti, tra cui:
o Tutte le autenticazioni andate a buon fine
o Tutte le autenticazioni fallite
o Tutti i tentativi di autorizzazione andata a buon fine
o Tutti i tentativi di autorizzazione falliti
o Tutti i tentativi di accesso amministrativo
o Tutte le azioni amministrative, come la modifica della password dell’amministratore, la
creazione di oggetti del policy store e le modifiche agli oggetti del policy store.

Tuttavia è possibile configurare un database di controllo autonomo. Al momento di decidere dove

archiviare gli eventi di controllo, considera che:
o Il Report Server richiede una connessione ad un database di controllo per creare report
basati su audit. Il Report Server non può creare report basati su audit da un da un registro
di Policy Server scritto in un file di testo
o Memorizzare i registri di controllo su un database è più sicuro che registrare le
informazioni in un file di testo.
o Se supportato, un policy store può anche funzionare come un database di controllo

• Session Store(Opzionali): Quando CA SSO autentica un utente, il Policy Server emette un ticket di
sessione. Un ticket di sessione contiene le informazioni di base sull’utente e le informazioni di
autenticazione per l’utente. Per impostazione predefinita, CA SSO implementa la gestione delle

41
 Cestrone Pasquale

MANUALE START
sessioni attraverso sessioni non-persistent. Se le sessioni non-persistent sono abilitate, un Agent
scrive il ticket di sessione su un cookie di un browser degli utenti. Tuttavia, alcune funzionalità di CA
SSO richiedono sessioni persistenti. Se le sessioni persistenti sono abilitate, un Agent deve scrivere
il ticket di sessione su un database autonomo. Si distribuisce un session store per i seguenti motivi:
o Se viene implementato un URI di disconnessione, un session store impedisce l’utilizzo di
una sessione dopo che un utente si è disconnesso.
o Fornire supporto per funzionalità che richiedono sessioni utenti permanenti
L’Agent utilizza queste informazioni per identificare gli utenti e fornire informazioni sulla sessione al
Policy Server.

• CA SSO Administrative UI(Richiesto): L’ Administrative UI del CA SSO è una web console di

amministrazione che viene installata indipendentemente dal Policy Server. L’Administrative UI è
destinata alla gestione di tutte le attività correlate al controllo degli accessi, alla federazione, ai
rapporti e all’analisi delle politiche.

Descrizione installazione di CA Single Sign-On

Il documento descrive passo per passo l’installazione di tutte le componenti CA SSO. Il tutto descritto in
questo diagramma:

NOTA: A partire dal 1 ° aprile 2016, i nuovi clienti di CA Single Sign-On non dispongono dei diritti per
accedere o utilizzare CA Report Server di CA Technologies. I clienti che hanno installato CA SSO prima
del 1 aprile 2016 continuano ad avere i diritti per accedere a CA Report Server da CA Technologies ed
utilizzare CA Report Server con CA Single Sign-On.

• L’Agent stabilisce una connessione con il Policy Server, utilizzando le informazioni contenute nel
file di configurazione Host(SmHost.conf). E’ possibili configurare l’Host Configuration Object (HCO),
il quale include molteplici e specifica il metodo che l’Agent utilizza per distribuire le richieste tra i
vari Policy Server.

42
 Cestrone Pasquale

MANUALE START
• Un Policy Server cluster è un gruppo di Policy Server a cui gli Agent distribuiscono le richieste. Un
Cluster può essere configurato per includere i Policy Server solo in uno specifico data center. Il
raggruppamento di Agent con i cluster di diversi Policy Server, evitano il sovraccarico di rete,
bilanciando tale carico si più regioni geograficamente separate.
• Tutti i Policy Server devono connettersi ALLO STESSO Policy Store per una visione comune delle
informazioni della policy. Tuttavia, è consigliabile che la distribuzione includa più Policy Store a cui
gli stessi Policy Server possono eseguire il failover (le funzioni di una componente di un sistema (come
ad esempio un processore, un server, una rete un database e altri) vengono inviate ad una seconda
componente quando la prima ha un problema. Viene utilizzato per rendere i sistemi più resistenti ai
problemi di errori). Un singolo Master Policy Store consente ad ogni Policy Server di comunicare con
il policy store replicato più vicino. In questo modo si migliorano le prestazioni dei Policy Server
separati geograficamente e consente il failover. In caso di errore del Primary Policy Store, il failover
del Police Server passa ad uno store secondario.

- Installare e Configurare il Policy Server

Il Policy Server interagisce con tutti i componenti principali, per valutare e applicare le policy di controllo degli
accessi, che successivamente comunica al CA SSO Agent. Il Policy Server accede ai vari data store contenenti
le sue policy, i dati degli user e le informazioni sulla sessione.

Installare SDK (opzionale)

Il kit di sviluppo software(SDK) fornisce interfacce di programmazione dell’applicazione(API), le quali

consentono di eseguire le seguenti operazioni:

• Creare applicazioni front-end personalizzate, in grado di accedere ai servizi SSO di CA

• Estendere le funzionalità di CA SSO tramite i plug-in del server.
E’ opzionale installare SDK, ma se si possiedono i requisiti, si consiglia di installarlo dopo aver
installato il Policy Server.

- Installare Administrative UI
L’Administrative UI è una web-console amministrativa, installata INDIPENDENTEMENTE dal Policy Server.
L’Administrative UI si utilizza per gestire tutte le attività riguardanti il controllo degli accessi, la federazione,
il reporting e l’analisi delle policy.

Installare il Report Server e il Reporting Database (opzionale)

L’installazione del Report Server è un passaggio separato all’interno del processo di installazione generale.
L’installazione del Report Server consente ad altri prodotti CA di condividere i servizi di Business Intelligence.
Il Report Server compila i seguenti tipi di report per aiutare ad analizzare il proprio ambiente CA SSO:

• Revisione
• Analisi Policy
Inoltre per compilare i seguenti report comunica con queste componenti:

• Il database Central Management Server(CMS)

43
 Cestrone Pasquale

MANUALE START
• L’Administrative UI
• Il Policy Server
• Un database di controllo di CA SSO

- Agent CA SSO
Un Agent CA SSO può risiedere su un web server, un server di applicazione J2EE, su un sistema Enterprise
Resource Planning (ERP) o su un’applicazione custom. Un Agent intercetta una richiesta dell’user, per le
risorse, e comunica con un Policy Server per determinare se la medesima risorsa è protetta. Se tale risorsa
non è protetta, l’Agent consente l’accesso. Ma se la risorsa è protetta, allora l’Agent continua a comunicare
con il Policy Server, per autenticare e autorizzare gli utenti. Un’autorizzazione corretta richiede all’Agent di
lasciare che la richiesta di risorsa proceda al server.

- CA Access Gateway
Il CA Access Gateway è un server autonomo che fornisce una soluzione, basata sul proxy, per il controllo degli
accessi. Inoltre CA Access Gateway funge da gateway singolo, per l’accesso alle risorse aziendali,
indipendentemente dal metodo di accesso alla rete. Una serie di regole proxy configurabili determina in che
modo CA Access Gateway gestisce la richiesta utente. Gli utenti possono accedere alle risorse attraverso più
schemi di sessione, basati sulla mappatura tra tipi di user e host virtuali. Le richieste possono essere
indirizzate ai diversi server di destinazione, in base al tipo di dispositivo utilizzato per accedere alla rete.

Installare Web Agent o CA Access Gateway

E’ possibile sostituire I Web Agent, nel proprio ambiente, con CA Access Gateway, per connettersi, in modo
centralizzato, con più Web Server con più risorse. Quando un utente richiede l’accesso ad una risorsa,
protetta su un Web Server, CA Access Gateway intercetta la richiesta per autenticare l’utente. Se
l’autenticazione ha esito positivo, allora la richiesta viene inoltrata ad un Web Server, in base alla
configurazione delle regole di proxy ed infine la richiesta viene servita.

44
 Cestrone Pasquale

MANUALE START
11. OAM
Vediamo una panoramica di Oracle Access Manager (principale soluzione di Single Sign-On di Oracle per
Oracle Fusion Middleware 11g) che è uno dei componenti principali dalla pila di Identity Management di
Oracle.

Oracle Access Manager (OAM) è costituito fondamentalmente da due sistemi principali:

1. Identity System: per creare/gestire utenti e gruppi, self registration e gestione delle password.
2. Access System: per configurare soluzioni SSO single/multi domain per applicazioni Web e non-Web
based, pagine web e altre risorse. Per configurare la gestione degli accessi (autenticazione e
autorizzazione) per vari tipi di risorse (applicazioni - web o non-Web based, pagine web).

È possibile implementare soltanto l’Identity System o solo l’Access System o entrambi i componenti di Access
Manager.

Utilizzando l’Identity System di access manager è possibile:

• Creare, eliminare o gestire le identity information relative a utenti o gruppi.

• fornire delegated administration and self service on identity (users/groups/resources)
• usare workflow engine per automatizzare le richieste e le approvazioni relative ai dati di identità
• Password Management - Definire multiple policy di password, modificare le password, la gestione
delle password perse ...
• configurare il controllo e il reporting su eventi di identità

Oracle Access Manager – Identity System:

L’Access Manager Identity system di Oracle contiene principalmente quattro applicazioni per fornire le
funzionalità definite sopra:

• User Manager - Applicazione per aggiungere, rimuovere o gestire gli utenti.

• Group Manager - Applicazione per aggiungere, eliminare, gestire gruppi (statici, dinamic, nidificati).
Questa applicazione si utilizza per aggiungere / rimuovere gli utenti dal gruppo o per cearcare i
membri in un gruppo.
• Organization Manager- per gestire le regole del sistema, i privilegi di accesso e flussi di lavoro per
intere organizzazioni.
• Identity System Console- per creare gli amministratori e l’amministratore delegato per l’identity
system e setup identity system application includendo oggetti, classi e attributi.

45
 Cestrone Pasquale

MANUALE START
Oracle Access Manager’s Identity System ha due componenti secondari:

• Identity Server - stand-alone server process che comunica col Directory Server (AD, OID, Directory
server Sun ..)
• WebPass - web server plug-in che comunica tra webserver (Apache, SSL, IIS ..) e Identity Server.

Identity Server serve per gestire le informazioni relative ad utenti, gruppi e altri oggetti memorizzati nel
Directory Server. Ci possono essere uno o più Identity Server in una Access Manager solution. Il WebPass
riceve le richieste degli utenti e le inoltra all’Identity Server. Dopo l'elaborazione di tali richieste da parte
dell’Identity Server, il WebPass riceve risposta dall’Identity Server e lo passa al server web. WebPass può
connettersi a uno a più Identity Server. La comunicazione tra WebPass e Identity Server avviene tramite un
protocollo proprietario di Oracle come "Oracle Identity Protocol". La comunicazione tra Identity Server e il
Directory Server utilizza LDAP (Lightweight Directory Access Protocol).

Oracle Access Manager – Access System

E’ composto dai seguenti 4 sottocomponenti:

1. Access Server: fornisce il servizio di valutazione dinamica delle policy per le risorse e applicazioni
web-based e non-Web based. L’Access Server riceve la richiesta dal WebGate o dal custom
AccessGate, l’Access Server quindi interroga il server LDAP per le regole di autenticazione,
autorizzazione e auditing (revisione).
2. WebGate : è un plug-in web server che intercetta le richieste HTTP dagli utenti per la risorsa Web e
le trasmette all’Access Server per l'autenticazione e l'autorizzazione. (nel nostro caso si va a creare
un’istanza di webgate nel nostro OHS).
3. Policy Manager: gli amministratori utilizzano il policy manager per definire le risorse che devono
essere protette dall’Access system. Il Policy Manager viene implementato sul WebServer con
WebPass e comunica con directory server (OID, AD o iPlanet) per scrivere i policy data. Il Policy
Manager comunica con l’Access Server (utilizzando Oracle Access Protocol) per aggiornare l’access
server in merito a qualsiasi modifica delle policy.
Il Policy Manager contiene i seguenti moduli:
a) Authentication Module
b) Authorization Module

46
 Cestrone Pasquale

MANUALE START
c) Auditing Module
d) Session Management Module
4. Access System Console: consente di configurare l’Access Server ed ha le seguenti tabs (schede):
System Configuration, System Management and Access System Configuration:
a. System Configuration: Per definire:
i. Master and Delegated Access Administrator
ii. Resource type, Policy domain, authentication and authorization schemes.
b. System Management: per gestire la diagnostica, i reports.
c. Access System Configuration:
i. Per visualizzare, aggiungere, modificare o eliminare l’Access Server, l’Access Gate o
l’ Access Server cluster.
ii. b) Per visualizzare e modificare i parametri di autenticazione / autorizzazione ....

Ci può essere uno o più Access Server in una Access Manager solution. Il WebGate riceve le richieste degli
utenti e le inoltra all’ Access Server, dopo l'elaborazione di tale richieste da parte dell’Access Server, il
WebGate riceve risposta dall’ Access server e la passa al Web Server. Il WebGate può collegarsi a uno o più
Access Server. La comunicazione tra WebGate e Access Server avviene tramite protocollo proprietario di
Oracle come "Oracle Access Protocol". La comunicazione tra Access Server e Directory Server utilizza LDAP
(Lightweight Directory Access Protocol)

47
 Cestrone Pasquale

MANUALE START
12. OIM
Oracle Identity Manager è un sistema di gestione delle identità aziendale altamente flessibile e scalabile in
grado di gestire i privilegi di accesso degli utenti all'interno delle risorse IT dell'azienda. Tale sistema consente
di determinare quale utente ha accesso a quale risorsa, in quale momento, in quale modo e per quale motivo.
L'architettura flessibile di Oracle Identity Manager è in grado di gestire i requisiti IT e aziendali più complessi
senza richiedere modifiche a infrastrutture, criteri o procedure esistenti. Grazie alla flessibilità che lo
caratterizza, Oracle Identity Manager è particolarmente efficace nella gestione del flusso costante di
modifiche aziendali che incidono sulle distribuzioni della gestione delle identità del mondo reale. Tale
flessibilità deriva dall'architettura del prodotto, in grado di astrarre le funzioni di attivazione (provisioning)
principali in livelli distinti. Le modifiche al flusso di lavoro, ai criteri, al flusso di dati o alla tecnologia di
integrazione vengono isolate all'interno dei rispettivi livelli funzionali di Oracle Identity Manager, riducendo
in tal modo al minimo l'impatto nell'intera applicazione. Oracle Identity Manager risulta inoltre flessibile in
quanto tutte le configurazioni vengono eseguite mediante la relativa interfaccia utente avanzata. Il prodotto
non utilizza alcun linguaggio di script per l'impostazione, la configurazione o la modellazione dei processi.
Oracle Identity Manager risulta pertanto la soluzione di gestione delle identità aziendali più avanzata sul
mercato.

Oracle Identity Manager può essere utilizzato come punto di gestione unico per le risorse IT
dell'organizzazione. Oracle Identity Manager offre varie soluzioni per l'integrazione con vari tipi di risorse. I
connettori Oracle Identity Manager sono la soluzione di integrazione consigliata.

L'integrazione di un sistema di destinazione con Oracle Identity Manager è composta da due parti:

• Gestione dell’account target

La funzionalità della gestione del target account è ulteriormente suddivisa in due parti:
o Confronto delle risorse mirate: Questo è il processo in cui ogni azione per creare, modificare
o cancellare un account di sistema di destinazione per un utente OIM esistente viene
comunicata e replicata in Oracle Identity Manager.
o Approvvigionamento: Questo è il processo in cui qualsiasi azione per creare, modificare o
eliminare un'identità di sistema di destinazione su Oracle Identity Manager viene comunicata
e replicata sul sistema di destinazione.

• Riconciliazione delle fonti attendibili

Questo è il processo in cui qualsiasi azione per creare, modificare o eliminare le informazioni di
identità degli utenti da fonti autorevoli viene comunicata e replicata in Oracle Identity Manager

Insieme, la riconciliazione e il provisioning sono finalizzati a consentire a Oracle Identity Manager di costruire
un quadro accurato delle identità gestite in tutti i sistemi di destinazione nell'organizzazione.

In termini di flusso di dati, il provisioning fornisce il flusso in uscita da Oracle Identity Manager. Il provisioning
si basa su un modello "push", con il quale Oracle Identity Manager comunica le modifiche al sistema di
destinazione. La riconciliazione fornisce il flusso verso l'interno in Oracle Identity Manager. La riconciliazione
si basa su un modello "push" o "pull", con il quale Oracle Identity Manager viene a conoscenza di qualsiasi
attività legata all'identità sul sistema di destinazione. I sistemi di destinazione che supportano il modello push
dispongono di funzionalità che consentono loro di inviare informazioni sulle modifiche relative all'identità a
sistemi di terze parti come Oracle Identity Manager. Il modello pull viene utilizzato per i sistemi target che
non supportano il modello push. Il modello pull è implementato attraverso il polling periodico del sistema
target per i cambiamenti legati all'identità.

48
 Cestrone Pasquale

MANUALE START
12.1 Integration Solutions
Oracle Identity Manager offre una strategia di soluzioni di integrazione a tre livelli per l'integrazione con
sistemi IT eterogenei sensibili all'identità. Questa strategia a tre livelli è progettata per ridurre al minimo lo
sviluppo personalizzato, massimizzare il riutilizzo del codice e ridurre i tempi di implementazione. I tre livelli
sono:

• Integrazione pronta all'uso con connettori predefiniti e provider di connettori con tecnologia
generica predefinita
• Connettori creati utilizzando provider di connettori di tecnologia generica personalizzati
• Connettori personalizzati creati utilizzando Adapter Factory

12.1.1 Connettori predefiniti

Quando un il connettore predefinito è disponibile per una risorsa di destinazione, è il metodo di
integrazione consigliato. Poiché un connettore predefinito è progettato specificamente per l'applicazione di
destinazione, offre il metodo di integrazione più rapido. I connettori predefiniti supportano le applicazioni
aziendali più diffuse come Oracle eBusiness Suite, PeopleSoft, Siebel, JD Edward e SAP, oltre a applicazioni
tecnologiche come Microsoft Active Directory, Java Directory Server, UNIX, database e RSA ClearTrust. I
connettori predefiniti utilizzano le tecnologie di integrazione consigliate dal sistema di destinazione e sono
preconfigurati con attributi specifici del sistema di destinazione.

12.1.2 Connettori generici di tecnologia

Per integrare Oracle Identity Manager con un sistema di destinazione che non ha un connettore predefinito
corrispondente, è possibile creare un connettore personalizzato per collegare il sistema di destinazione e
Oracle Identity Manager. Se non si desidera utilizzare le funzionalità di personalizzazione di Adapter Factory,
è possibile creare il connettore utilizzando la funzionalità Generic Technology Connector di Oracle Identity
Manager.

12.1.3 Connettori personalizzati

Se non esiste un'interfaccia tecnologica o un repository utente accessibile nel sistema di destinazione, è
possibile sviluppare a connettore personalizzato per il sistema di destinazione. Lo strumento Adapter Factory
nella console di progettazione fornisce un'interfaccia utente definitiva che facilita tali sforzi di sviluppo
personalizzati senza codifica o script.

12.2 Riconciliazione
Oracle Identity Manager offre un meccanismo di controllo centralizzato per gestire utenti e titolarità e
controllare l'accesso degli utenti alle risorse. Tuttavia, è possibile scegliere di non utilizzare Oracle Identity
Manager come repository principale o il punto di accesso front-end degli account utente. Invece, è possibile
utilizzare Oracle Identity Manager per eseguire periodicamente il polling dei sistemi di destinazione per

49
 Cestrone Pasquale

MANUALE START
mantenere un profilo aggiornato di tutti gli account esistenti su tali sistemi. Questa è la configurazione di
riconciliazione di Oracle Identity Manager.

Come mostrato in questa figura, nella configurazione di riconciliazione, Oracle Identity Manager viene
utilizzato solo come un unico archivio aggiornato per tutti i dati di utenti e gruppi di utenti del sistema di
destinazione. Gli utenti vengono creati, eliminati e gestiti dagli amministratori specifici delle risorse locali. La
riconciliazione implica l'uso del scoperta dell'utente e caratteristiche di scoperta dell'account di Oracle
Identity Manager.

12.3 Provisioning
È possibile utilizzare Oracle Identity Manager per creare, mantenere ed eliminare utenti sui sistemi di
destinazione. In questa configurazione, Oracle Identity Manager funge da punto di accesso front-end per la
gestione dei dati utente sui sistemi di destinazione. Dopo il provisioning degli account, gli utenti per i quali è
stato eseguito il provisioning degli account possono accedere ai sistemi di destinazione senza alcuna
interazione con Oracle Identity Manager. Questa è la configurazione di provisioning di Oracle Identity
Manager. La Figura illustra la configurazione di provisioning di Oracle Identity Manager.

Un'operazione di provisioning può essere avviata tramite uno dei seguenti modi:

• Provisioning basato su richiesta

Nel provisioning basato su richiesta, una persona crea una richiesta per un account di sistema di
destinazione. Il processo di provisioning è completato quando un utente OIM con i privilegi richiesti
approva la richiesta e provvede al richiedente l'account di sistema di destinazione.

• Provisioning basato su criteri

50
 Cestrone Pasquale

MANUALE START
Questo tipo di provisioning si riferisce alle risorse concesse agli utenti automaticamente tramite le
policy di accesso. I criteri di accesso vengono utilizzati per definire l'associazione tra gruppi di utenti
(o ruoli) e risorse di destinazione. I gruppi di utenti sono raccolte di utenti a cui si concede l'accesso
a funzionalità comuni, quali diritti di accesso, ruoli o autorizzazioni. Utilizzi i gruppi di utenti per
creare e gestire collettivamente i record dei membri del gruppo.Puoi anche assegnare o rimuovere
le regole di appartenenza a e da questi gruppi. Queste regole definiscono quali utenti possono essere
assegnati a un particolare gruppo di utenti. Per impostazione predefinita, ciascun membro di questi
gruppi di utenti ottiene un account predefinito nel sistema di destinazione. Inoltre, è possibile
utilizzare Oracle Identity Manager per creare processi di approvazione che possono essere eseguiti
come parte del ciclo di provisioning basato su policy.A volte, l'introduzione o la modifica di una
politica di accesso può comportare modifiche ai privilegi assegnati agli utenti che soddisfano i criteri
specificati nella politica. Ad esempio, supponiamo che venga introdotta la seguente politica:
Tutti i project manager che lavorano presso l'ufficio di Londra devono avere accesso al sistema SAP.
Quando questa politica viene introdotta in Oracle Identity Manager, gli account utente SAP vengono
automaticamente forniti a tutti i project manager.

• Provisioning diretto
Questo tipo di provisioning è una funzione specifica dell'amministratore in cui un amministratore di
Oracle Identity Manager fornisce una risorsa a un utente OIM. Il flusso di lavoro per questo tipo di
provisioning non include le fasi di richiesta e approvazione. Esegui il provisioning diretto utilizzando
la console amministrativa e utente di Oracle Identity Manager.

51
 Cestrone Pasquale

MANUALE START
13. OpenID e SAML
OpenID e SAML (Security Assertion Markup Language), come il protocollo CAS, non sono sistemi di
autenticazione in senso stretto, bensì un'estensione dei sistemi tradizionali nel contesto del Web. A
differenza del Central Authentication Service queste due tecnologie permettono di spingersi al di fuori del
perimetro dell'organizzazione, consentendo l'interazione di identità esterne con i servizi locali e viceversa,
costituendo un sistema federato di identità.

FIGURA 1: Schema di autenticazione OpenID (Govoni 2008)

OpenID e un sistema utilizzato da grandi provider di servizi come Yahoo!, Google, Wordpress. Inizialmente
adottato anche da Facebook, e stato in seguito sostituito da Facebook Connect. Si basa sul principio di
decentralizzazione dei ruoli di Identity Provider e Service Provider, non richiede meccanismi di trust esplicito
per funzionare, motivo per cui e adottato soprattutto in contesti dove l'esigenza e distinguere correttamente
gli utenti ma non necessariamente avere certezza sulla loro identità. Si tratta di un sistema snello volto a
risolvere il problema della proliferazione degli account, consentendo agli utenti di riutilizzare la propria
identita registrata presso un OpenID provider, offrendo alle applicazioni la possibilita di affrancarsi dalla
gestione delle anagrafiche affidandosi al protocollo. L'estrema decentralizzazione spinge pero sulle
applicazioni l'onere di supportare i diversi provider, motivo per cui la scena attuale vede una polarizzazione
del supporto solo su pochi provider molto diffusi (Google, Facebook).

SAML (Security Assertion Markup Language) - standard OASIS per lo scambio di dati relativi ad
autenticazione, autorizzazione e dati sull'identità in formato XML - per contro segue un approccio piu
strutturato. Gli elementi costituenti sono i seguenti:

• asserzioni: elementi di base dei messaggi che possono essere scambiati;

• protocolli: le modalità di aggregazione delle asserzioni per la comunicazione
tra le entità coinvolte;
• binding: modalità di trasferimento dei messaggi scambiati;
• profili: istruzioni per l'aggregazione di asserzioni, protocolli e binding per poter
coprire uno specifico caso d'uso.

Il profilo di interesse in questo contesto e il Web browser SSO profile, riportato nella figura seguente, dove
e illustrata la sequenza dei messaggi tra lo User Agent (il browser utilizzato dall'utente), il Service Provider
(l'applicazione o risorsa a cui l'utente vuole accedere) e l'Identity Provider (il fornitore di identita).

52
 Cestrone Pasquale

MANUALE START

FIGURA 2: SAML Authentication Request – Wikipedia

Al completamento dello scambio l'utente avrà una sessione autenticata che potrà permettergli di accedere
ad altre risorse, facenti parte dello stesso contesto di SSO, senza inserire di nuovo le credenziali.

FIGURA 1: Architettura SAML completa

Nel caso di SAML il contesto di Single Sign-On è determinato dalle relazioni di trust in vigore tra Service
Provider, Identity Provider e gli altri componenti della federazione. Infatti per IDP e SP è possibile
determinare relazioni di trust punto-punto, con l'ovvio limite della scalabilità al crescere dei partecipanti,
oppure inserirsi in un contesto centralizzato che raccoglie gruppi di risorse e fornitori di identità che prende
il nome di federazione di identità.

53
 Cestrone Pasquale

MANUALE START

FIGURA 3: Funzionamento di una federazione di identità (Switch Consortium s.d.)

Le federazioni di identita sono normalmente operate da realta nazionali che si occupano di interloquire con
i partecipanti e gestire un servizio centralizzato di condivisione dei metadati. Queste informazioni sono
l'elemento fondante delle relazioni di trust e permettono di mantenere aggiornato l'elenco dei partecipanti
al crescere delle entita. In un'infrastruttura federata di autenticazione si inserisce un elemento necessario
per poter individuare quale IDP utilizzare per verificare l'identita di un utente che richiede l'accesso a un
Service Provider SAML. Il Discovery Service o WAYF (Where Are You From) e un componente software con cui
interagisce l'utente per scegliere l'IDP di appartenenza, in modo da poter effettuare l'autenticazione e
procedere con l'accesso al SP. L'impostazione centralizzata ha diversi vantaggi ma presenta anche alcuni
svantaggi quali la complessita di manutenzione e la costituzione di un Single Point of Failure per l'operativita
della federazione, inoltre il processo di adesione puo essere anche molto lento, a seconda del livello di
formalita (e del ruolo) con cui si vuole entrare a farne parte. Questo livello di precisione nell'operativita ha
fortunatamente il pregio di selezionare partecipanti e utenze con un livello di affidabilita mediamente
elevato.

54
 Cestrone Pasquale

MANUALE START
14. Oauth
Il framework di autorizzazione Oauth 2.0 si propone come ideale complemento di OpenID e si rivolge
ad un contesto più flessibile e dinamico di quello Enterprise a cui sono rivolti di più SAML e WS-*.

La sua nascita è dovuta principalmente a due esigenze dei principali fornitori di appli- cazioni web:

- la necessità di consentire l'interazione tra applicazioni web di diversi fornitori, su

autorizzazione di un utente, utilizzando la propria identità;
- la necessità di poter accedere ai dati di un'applicazione web attraverso un di- spositivo
mobile senza dover reinserire ogni volta le credenziali, attività molto scomoda in mobilità.

Oauth risponde a queste richieste con un modello che prevede quattro attori e una serie di flussi di
funzionamento (flow) tra cui scegliere per meglio rispondere al caso d'uso specifico

FIGURA 1: OAuth protocol (Oracle s.d.)

La comunicazione è basata su REST, secondo la sequenza definita nella figura pre- cedente:
- il Client (che può essere un'applicazione web o nativa) effettua una richiesta di autorizzazione
al Resource Owner (tipicamente l'utente finale);
- il Resource Owner accetta fornendo un Authorization Grant (tipicamente delle credenziali);
- il Client fornisce l'Authorization Grant all'Authorization Server che restituisce un Access Token
- un lasciapassare con scadenza che permette di accedere libe- ramente senza ripetere
l'autorizzazione per un certo periodo di tempo;
- il Client fornisce l'Access Token al Resource Server (che dovrà validarlo con l'Authorization
Server) per accedere alla risorsa protetta.

Un Access Token ha una naturale scadenza, per mantenere l'accesso alla risorsa il Client deve
periodicamente usare un Refresh Token per ottenere un valido Access Token.
Oauth 2.0 è molto usato anche per l'autorizzazione all'accesso di API che possono essere consumate
con l'identità di un utente, in generale è diventato velocemente uno standard di fatto nel mondo delle
applicazioni web.

55
 Cestrone Pasquale

MANUALE START
15. Federation
Le federazioni di identità costituiscono una soluzione tecnologica (e per certi aspetti organizzativa) che
permette agli utenti afferenti ad un'organizzazione di usare la propria identità presso una seconda
organizzazione partecipante, in modo trasparente. A livello nazionale ed internazionale si sono affermate,
soprattutto in ambito accademico e di ricerca, federazioni di identità basate su SAML e gestite dai National
Research and Education Network (NREN, in Italia è il GARR). Beneficio principale delle federazioni di identità
è la ragionevole certezza dell'affidabilità dell'identità presentata ai servizi dai fornitori di identità
partecipanti. Ogni Identity Provider infatti effettua un percorso di accreditamento volto a stabilire la qualità
del suo processo di riconoscimento degli utenti e sottoscrive delle regole di comporta- mento per tutelare la
funzione della federazione e gli altri partecipanti.

Gli elementi costituenti di una federazione, in parte già incontrati sono i seguenti:

• Identity Provider: fornitore dell'identità digitale, assicura la corrispondenza verso un utente reale ed
è responsabile della corretta registrazione e aggiornamento dei dati relativi;
• Service Provider: fornitore del servizio, applicazione web che consuma un'identità digitale federata
ed eventualmente altri attributi;
• Discovery Service: componente software che permette agli utenti di effettuare l'autenticazione su
uno degli Identity Provider individuandolo in modo agevolato (detto anche WAYF - Where Are You
From);
• Metadata Service: servizio di distribuzione delle informazioni costituenti i partecipanti quali i
certificati di firma, crittografia, le descrizioni dei servizi e delle organizzazioni. Inoltre stabilisce quali
sono i partecipanti appartenenti alla relazione di trust.

56
 Cestrone Pasquale

MANUALE START

57
 Cestrone Pasquale

MANUALE START
16. OpenAM
OpenAM è una soluzione software open source per la gestione degli accessi, dei diritti e della federazione di
una piattaforma server. È stato sponsorizzato da ForgeRock fino al 2016. Ora è supportato da Open Identity
Platform Community . OpenAM è nato come OpenSSO , un sistema di gestione degli accessi creato da Sun
Microsystems e ora di proprietà di Oracle Corporation . OpenAM è un fork avviato dopo l'acquisto di Sun da
parte di Oracle.

OpenAM supporta le seguenti funzionalità:

• Autenticazione: OpenAM supporta 20 metodi di autenticazione pronti all'uso. OpenAM ha la

flessibilità di concatenare i metodi insieme al punteggio del rischio adattivo o di creare moduli di
autenticazione personalizzati basati sullo standard aperto JAAS (Java Authentication and
Authorization Service). Windows IWA è supportato per abilitare un ambiente SSO eterogeneo e
applicazioni Web senza interruzioni.

• Autorizzazione: OpenAM fornisce una politica di autorizzazione di regole semplici, con diritti
altamente avanzati e granulari, basati su XACML (eXtensible Access Control Mark-Up Language). Le
politiche di autorizzazione sono astratte dall'applicazione, consentendo agli sviluppatori di
aggiungere o modificare rapidamente la politica secondo necessità, senza modifiche all'applicazione
sottostante.

• Autenticazione del rischio adattiva: Il modulo di autenticazione del rischio adattativo viene utilizzato
per valutare i rischi durante il processo di autenticazione e per determinare se richiedere all'utente
di completare ulteriori passaggi di autenticazione. L'autenticazione del rischio adattivo determina, in
base al punteggio di rischio, se sono richieste più informazioni da un utente al momento dell'accesso.
Ad esempio, un punteggio di rischio può essere calcolato in base all'intervallo di indirizzi IP,
all'accesso da un nuovo dispositivo, al tempo di inattività dell'account, ecc. Ed è applicato alla catena
di autenticazione.

• Federazione: I servizi federali condividono in modo sicuro le informazioni sull'identità attraverso

sistemi eterogenei o confini di domini, utilizzando i protocolli di identità standard (SAML , WS-
Federation , OpenID Connect). Configurare e riconfigurare rapidamente il service provider o le
connessioni del servizio cloud tramite Fedlet, OAuth2 Client, OAuth2 Provider o OpenIG Federation
Gateway. OpenIG Federation Gateway è un componente di OpenAM che fornisce un punto di
applicazione SAML2 conforme e consente alle aziende di aggiungere rapidamente il supporto SAML2
alle proprie applicazioni con poca o nessuna conoscenza dello standard. Inoltre, non è necessario
modificare l'applicazione o installare alcun plugin o agente nel contenitore dell'applicazione.
Strumenti pratici che consentono una semplice configurazione basata su attività di Google Apps,
ADFS2 e molti altri obiettivi di integrazione. OpenAM può anche fungere da hub multiprotocollo,
traducendo per i provider che si affidano ad altri standard più vecchi. Il supporto OAuth2 è uno
standard aperto per la federazione e l'autorizzazione moderne, che consente agli utenti di
condividere le proprie risorse private con token anziché credenziali.

• Single Sign-On (SSO): OpenAM fornisce più meccanismi per SSO, indipendentemente dal fatto che il
requisito abiliti l'SSO tra domini per una singola organizzazione o SSO su più organizzazioni tramite il
servizio federativo. OpenAM supporta molteplici opzioni per l'applicazione dei criteri e la protezione
delle risorse, inclusi gli agenti dei criteri che risiedono su server Web o applicazioni, un server proxy

58
 Cestrone Pasquale

MANUALE START
o OpenIG (Identity Gateway). OpenIG funziona come un gateway autonomo e protegge le
applicazioni Web in cui non è possibile installare un agente di policy.

• Alta disponibilità: Per consentire un'elevata disponibilità per implementazioni su larga scala e
mission-critical, OpenAM fornisce sia il failover di sistema che il failover di sessione. Queste due
funzionalità chiave aiutano a garantire che non vi siano singoli point of failure nella distribuzione e
che il servizio OpenAM sia sempre disponibile per gli utenti finali. Server OpenAM ridondanti, agenti
di policy e load balancer impediscono un singolo punto di errore. Il failover della sessione garantisce
che la sessione dell'utente continui senza interruzioni e nessun dato utente venga perso.

• Accesso allo sviluppatore: OpenAM fornisce interfacce di programmazione dell'applicazione client

con API Java e C e un'API RESTful che può restituire JSON o XML su HTTP, consentendo agli utenti di
accedere ai servizi di autenticazione, autorizzazione e identità dalle applicazioni Web utilizzando i
client REST nella lingua scelta. OAuth2 fornisce anche un'interfaccia REST per la federazione moderna
e leggera, oltre il protocollo di autorizzazione.

59
 Cestrone Pasquale

MANUALE START
17. Service-Oriented Architecture
Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA) si indica
generalmente un'architettura software adatta a supportare l'uso di servizi Web per garantire
l'interoperabilità tra diversi sistemi così da consentire l'utilizzo delle singole applicazioni come componenti
del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente.

Nell'ambito di un'architettura Service-Oriented Architecture è quindi possibile modificare, in maniera

relativamente più semplice, le modalità di interazione tra i servizi, oppure la combinazione nella quale i servizi
vengono utilizzati nel processo. Inoltre, risulta più agevole aggiungere nuovi servizi e modificare i processi
per rispondere alle specifiche esigenze di business. Così facendo, il processo di business non è più vincolato
da una specifica piattaforma o da un'applicazione; ma può essere considerato come un componente di un
processo più ampio e quindi riutilizzato o modificato.

L'architettura orientata ai servizi è particolarmente adatta per le aziende che presentano una discreta
complessità di processi e applicazioni. Infatti, viene agevolata l'interazione tra le diverse realtà aziendali. Le
attività di business ora possono sviluppare processi efficienti sia internamente che esternamente.
Parallelamente aumenta la flessibilità e l'adattabilità dei processi.

Benché molte aziende offrano prodotti che possono formare la base di una Service-Oriented Architecture va
sottolineato che la Service-Oriented Architecture non è un prodotto.

La chiave sta nella totale assenza di business logic sul client SOA, il quale è totalmente agnostico rispetto alla
piattaforma di implementazione, riguardo ai protocolli, al binding, al tipo di dati, alle policy con cui il servizio
produrrà l'informazione richiesta. Tutto a beneficio dell'indipendenza dei servizi, che possono essere
chiamati per eseguire i propri compiti in un modo standard, senza che il servizio abbia conoscenza
dell'applicazione chiamante e senza che l'applicazione abbia conoscenza, o necessiti di averne, del servizio
che effettivamente eseguirà l'operazione.

Service-Oriented Architecture può anche essere vista come uno stile dell'architettura dei sistemi informatici
che permetta la creazione delle applicazioni sviluppate, combinando servizi debolmente accoppiati e
interoperabilità degli stessi. Questi servizi interagiscono secondo una definizione formale, detta protocollo o
contratto, come per i Web Services Description Language indipendente dalla piattaforma sottostante e dalle
tecnologie di sviluppo (come Java, .NET, ecc.). Per esempio, i servizi scritti in Java usando la piattaforma Java
EE e quelli in C# con .NET possono essere utilizzati dall'applicazione sovrastante. Le applicazioni in esecuzione
su una piattaforma possono anche utilizzare servizi in esecuzione su altre, come con i Web services,
facilitando quindi la riusabilità.

Service-Oriented Architecture può supportare l'integrazione e la consolidazione di attività all'interno di

complessi sistemi aziendali (sistemi di EAI) ma non specifica o fornisce la metodologia o il framework per
documentare capacità e potenzialità dei servizi.

I linguaggi di alto livello come Business Process Execution Language e le specifiche come Web Services
Choreography Description Language e WS-Coordination estendono il concetto di servizio, fornendo un
metodo per definire e supportare la coordinazione dei servizi di rifinitura con quelli maggiori, che, di
conseguenza, possono essere inclusi in flussi di controllo e processi aziendali implementati con applicazioni
composte o portali.

60
 Cestrone Pasquale

MANUALE START
18. Algoritmo RSA
In crittografia la sigla RSA indica un algoritmo di crittografia asimmetrica, inventato nel 1977 da Ronald
Rivest, Adi Shamir e Leonard Adleman utilizzabile per cifrare o firmare informazioni.

Nel 1976 Whitfield Diffie e Martin Hellman, crittologi americani, furono i primi a pubblicare un sistema che
si basasse sulla creazione di un cifrario "asimmetrico" composto da "chiavi pubbliche"; anche se pochi anni
prima ci avevano già pensato James H. Ellis, Clifford Cocks, e Malcolm J. Williamson dei servizi segreti
inglesi, la notizia era coperta dal segreto militare e fu rivelata soltanto nel 1997.[1]

Il sistema di crittografia si basa sull'esistenza di due chiavi distinte, che vengono usate per cifrare e
decifrare. Se la prima chiave viene usata per la cifratura, la seconda deve necessariamente essere utilizzata
per la decifratura e viceversa. La questione fondamentale è che, nonostante le due chiavi siano fra loro
dipendenti, non è possibile risalire dall'una all'altra, in modo che se anche si è a conoscenza di una delle
due chiavi, non si possa risalire all'altra, garantendo in questo modo l'integrità della crittografia.

Per realizzare un sistema crittografico pubblico con il cifrario asimmetrico è importante che un utente si
crei autonomamente entrambe le chiavi, denominate "diretta" e "inversa", e ne renda pubblica una
soltanto. Così facendo si viene a creare una sorta di "elenco telefonico" a disposizione di tutti gli utenti, che
raggruppa tutte le chiavi dirette, mentre quelle inverse saranno tenute segrete dagli utenti che le hanno
create e da questi utilizzate solo quando ricevono un messaggio cifrato con la rispettiva chiave pubblica
dell'"elenco" da parte di un certo mittente, ottenendo in questo modo i presupposti necessari alla sicurezza
del sistema.

Per ottenere una discreta sicurezza è necessario utilizzare chiavi binarie di almeno 2048 bit. Quelle a 512 bit
sono ricavabili in poche ore. Le chiavi a 1024 bit, ancora oggi largamente utilizzate, non sono più
consigliabili.[2] La fattorizzazione di interi grandi, infatti, è progredita rapidamente mediante l'utilizzo di
hardware dedicati, al punto che potrebbe essere possibile fattorizzare un intero di 1024 bit in un solo anno
di tempo, al costo di un milione di dollari (un costo sostenibile per qualunque grande organizzazione,
agenzia o intelligence).[3][4]

Esempi pratici
Facendo un esempio pratico, se Alice vuole spedire un messaggio a Bob e non vuole che altri all'infuori di Bob
possano leggerlo, Alice cercherà sull'elenco la chiave pubblica di Bob e con quella potrà cifrare il messaggio.
Essendo Bob l'unico a possedere la chiave inversa, sarà anche l'unico a poter decifrare il messaggio, che
rimarrà così segreto per tutti gli altri, compresa Alice, che non disponendo della chiave inversa non sarà in
grado di decifrare il messaggio da lei stessa creato. Ovviamente il successo di questo sistema si basa
sull'assoluta necessità che Bob sia l'unico ad essere in possesso della chiave inversa. In caso contrario, avendo
entrambe le chiavi, chiunque potrebbe decifrare agevolmente il messaggio. Con questo metodo di cifratura
è possibile anche garantire la provenienza di un messaggio. Riprendiamo l'esempio precedente: Alice questa
volta, prima di cifrare il messaggio usando la chiave pubblica di Bob, lo cifrerà usando la propria chiave inversa
e solo in un secondo momento lo ri-crittograferà utilizzando la chiave pubblica di Bob. Quando Bob riceverà
il messaggio e lo decifrerà usando la propria chiave inversa, otterrà ancora un messaggio crittografato. Quel
dato messaggio necessiterà poi della chiave pubblica di Alice per essere decifrato, garantendo in questo
modo che il messaggio è stato spedito soltanto da Alice, unica a possedere la chiave inversa con la quale era
stato crittografato il messaggio. Più semplicemente, utilizzando questo metodo di cifratura, Alice può
mandare messaggi a tutti, garantendo la provenienza. Infatti, cifrando il messaggio con la propria chiave
inversa, chiunque sarà in grado di leggere il messaggio, decifrandolo con la sua chiave pubblica, assicurandosi
in tal modo che il mittente sia proprio Alice.

61
 Cestrone Pasquale

MANUALE START
L'implementazione tramite algoritmo RSA
È nel 1978 che questo sistema trova la sua applicazione reale, quando i tre ricercatori del MIT Ronald Rivest, Adi Shamir e Leonard
Adleman seppero implementare tale logica utilizzando particolari proprietà formali dei numeri primi con alcune centinaia di cifre.
L'algoritmo da loro inventato, denominato RSA dalle iniziali dei loro cognomi, non è sicuro da un punto di vista matematico teorico,
in quanto esiste la possibilità che tramite la conoscenza della chiave pubblica si possa decifrare un messaggio; ma l'enorme mole di
calcoli e l'enorme dispendio in termini di tempo necessario per trovare la soluzione fanno di questo algoritmo un sistema di
affidabilità pressoché assoluta. Ronald Rivest, Adi Shamir e Leonard Adleman nel 1983 brevettarono l'algoritmo negli Stati Uniti dal
MIT (brevetto 4.405.829, scaduto il 21 settembre 2000); hanno dato inoltre vita alla società RSA Data Security, tutelando così i propri
interessi commerciali. In seguito la Security Dynamics acquisì la società e vendette l'utilizzo degli algoritmi a società come Netscape,
Microsoft e altri. Una variante del sistema RSA è utilizzata nel pacchetto di crittografia Pretty Good Privacy (PGP). L'algoritmo RSA
costituisce la base dei sistemi crittografici su cui si fondano i sistemi di sicurezza informatici utilizzati sulla rete Internet per autenticare
gli utenti. Clifford Cocks, matematico britannico che lavorava per un dipartimento di spionaggio, il GCHQ, aveva descritto un sistema
equivalente in un documento interno nel 1973. I documenti furono posti sotto segreto e, visto il costo relativamente alto delle
macchine necessario a quel tempo per implementarlo, non ci furono ulteriori indagini né prove pratiche e la cosa fu considerata come
una curiosità, per quanto se ne sa. La scoperta di Cocks fu resa pubblica solo nel 1997. Nel 2005 un gruppo di ricerca riuscì a scomporre
un numero di 640 bit (193 decimali) in due numeri primi da 320 bit, impiegando per cinque mesi un cluster Opteron con 80 processori
da 2,2 GHz, potenzialmente decifrando un messaggio codificato con RSA-640. RSA è computazionalmente impegnativo, soprattutto
per quanto riguarda una eventuale realizzazione hardware. Di conseguenza, un uso efficiente è quello di sfruttare RSA per codificare
un unico messaggio contenente una chiave segreta; tale chiave verrà poi utilizzata per scambiarsi messaggi tramite un algoritmo a
chiave simmetrica, come AES. Oggi, insieme a DSS, RSA è uno degli algoritmi più usati per la cifratura di firme digitali.

Operazioni
RSA è basato sull'elevata complessità computazionale della fattorizzazione in numeri primi. Il suo
funzionamento base è il seguente:

Esempio
Ecco un esempio di cifratura e decifratura RSA. I numeri scelti sono volutamente primi piccoli, ma nella realtà
sono usati numeri dell'ordine di 10100.

62
 Cestrone Pasquale

MANUALE START

63
 Cestrone Pasquale

MANUALE START
19. Computer Cluster
In informatica un computer cluster, o più semplicemente un cluster (dall'inglese grappolo), è un insieme di
computer connessi tra loro tramite una rete telematica. Lo scopo di un cluster è quello di distribuire una
elaborazione molto complessa tra i vari computer. In sostanza, un problema che richiede molte
elaborazioni per essere risolto viene scomposto in sottoproblemi separati i quali vengono risolti in
parallelo. Questo ovviamente aumenta la potenza di calcolo del sistema e/o garantisce alta disponibilità di
servizio a prezzo di un maggior costo e complessità di gestione dell'infrastruttura.

I cluster hanno le seguenti caratteristiche: i vari computer risultano come una singola risorsa
computazionale e le varie componenti sono risorse dedicate al funzionamento dell'insieme; il server cluster
è quindi un server ad altissime prestazioni poiché, invece di gravare su un'unica macchina standalone,
suddivide il carico di lavoro (quindi, ad esempio, funzioni di mail server, web server, database server e file
server) su più macchine venendo ad essere di fatto una forma di sistema distribuito.

Attualmente, la clusterizzazione consiste nel connettere, meglio via fibra ottica, X server fisici, quasi sempre
di tipo blade, che condividono Y unità di storage, possibilmente dotati di dischi SSD, il tutto attraverso
switch prestazionali, e di erogare agli utenti i servizi necessari sotto forma di Z istanze virtuali, ivi comprese
risorse in remoto. Questa è la tipica situazione della logica cloud come anche delle reti distribuite
geograficamente (si pensi alle sedi dislocate sul territorio di un'impresa o un ente che ovviamente devono
avere un'unica rete aziendale). Logicamente, le due situazioni non sono disgiunte: è ormai normale che una
rete aziendale multisede utilizzi il cluster comprendendo anche risorse in cloud. Appositi e complessi
software di virtualizzazione e di networking permettono all'administrator di gestire ottimamente il
consolidamento e operare automaticamente il bilanciamento, risultando di fatto indispensabili nel caso
frequente di marche e modelli diversi dell'hardware di rete da integrare nonché dei diversi sistemi operativi
server (domain controller, servizi di rete, programmi applicativi).

Nell'architettura cluster un nodo è una macchina elaborativa ovvero un server fisico o virtuale che prende
parte al grappolo. Per l'utente o i client, il cluster è assolutamente trasparente: tutta la notevole
complessità hardware e software è mascherata; i servizi vengono erogati, i dati sono resi accessibili e le
applicazioni elaborate come se fossero tutte provenienti da un solo mega computer centrale.

Esistono tre tipi di cluster (i primi due sono i più diffusi):

• Fail-over Cluster: il funzionamento delle macchine è continuamente monitorato e quando uno dei
due host smette di funzionare un'altra macchina subentra in attività. Lo scopo è garantire dunque
un servizio continuativo garantendo cioè alta disponibilità di servizio grazie all'alta affidabilità
dovuta alla tolleranza ai guasti del sistema cluster per effetto della ridondanza di apparati;

• Load balancing Cluster: è un sistema nel quale le richieste di lavoro sono inviate alla macchina con
meno carico di elaborazione distribuendo/bilanciando così il carico di lavoro sulle singole macchine.
Questo garantisce tempi minori di processamento di un servizio e minore affaticamento di una
macchina;

• High Performance Computing (HPC Cluster): i computer sono configurati per fornire prestazioni
estremamente alte. Le macchine suddividono i processi di un job su più macchine, al fine di
guadagnare in prestazioni. La peculiarità saliente è che i processi sono parallelizzati e che le routine
che possono girare separatamente saranno distribuite su macchine differenti invece di aspettare di
essere eseguite sequenzialmente una dopo l'altra. GLI HPC sono diffusi specialmente nei Centri di
Elaborazione Dati (CED);

64
 Cestrone Pasquale

MANUALE START
Cluster virtualizzato, oltre alle precedenti caratteristiche combina le tecnologie di clusterizzazione con
quelle di virtualizzazione ottenendo cluster di macchine virtuali su una o più macchine fisiche ottenendo
così il massimo grado di complessità, la massima flessibilità possibile e notevole risparmio sui costi di
esercizio.

Requisiti per formare un cluster di computer

Per ottenere un sistema di computer operanti come un cluster è necessario:
• hardware di rete ad elevate prestazioni
• un sistema operativo distribuito in grado di far funzionare i computer come cluster (per esempio
GNU/Linux, utilizzando OpenMosix)
• un algoritmo parallelizzabile.

Vantaggi
I vantaggi dell'utilizzo di questo sistema sono:
• L’economicità, infatti questi sistemi sono fino a 15 volte più economici dei tradizionali
supercalcolatori rispetto ai quali, a parità di prestazioni, permettono un notevole risparmio sui
componenti hardware.
• La scalabilità, dal momento che le risorse sono distribuite.
• Facilità di aggiornamento e manutenzione.
• Disponibilità di un gran numero di software Open Source per i cluster, come MOSIX, openMosix e
Beowulf.
• Incremento capacità e velocità di calcolo grazie allo sfruttamento di più unità di calcolo, di
un'architettura più potente e maggiore disponibilità di memoria.
• Lo sfruttamento della cooperazione per risolvere problemi complessi.
• L'affidabilità, in quanto il sistema continua a funzionare anche in caso di guasti a parti di esso,
ovviamente con prestazioni inferiori.

Svantaggi
Gli svantaggi principali sono:
• Difficoltà di gestione e di organizzazione di un elevato numero di computer;
• Scarse prestazioni nel caso di applicazioni non parallelizzabili;
• Occupazione di spazio fisico notevolmente superiore a quella di un singolo server;
• Maggiore consumo di energia rispetto a un singolo server.

65
 Cestrone Pasquale

MANUALE START
20. Server-side
Nello scenario dello sviluppo software professionale (ma non solo) Java rende possibili soluzioni pensate
per applicazioni multitier (multi-livello) che utilizzano tutte le capacità e le caratteristiche di internet e delle
reti in genere;

Nel campo delle applicazioni web, o delle applicazioni distribuite in genere, le due figure principali sono il
Client ed il Server. I due sono dei processi, o applicazioni, in esecuzione su macchine differenti che
comunicano scambiandosi informazioni in diversi modi. Abitualmente il Client effettua una richiesta ed il
Server cerca di esaudirla. Per soddisfare le richieste dei Client il server può appoggiarsi a basi di dati, che
contengono le informazioni da elaborare, e che rappresentano il terzo importante elemento di questo tipo
di architettura. Di norma esistono quindi dei Client che formulano delle richieste al Server, che a sua volta
richiede i dati al database che li contiene, in modo del tutto trasparente al client li elabora in base alla
richiesta avuta ed invia il risultato del suo lavoro.

Sun ha messo a disposizione di Java diverse tecnologie che rendono l'utilizzo di questo linguaggio la scelta
più adatta per applicazioni distribuite o enterprise. Nel campo della programmazione web lato server, che è
quello che ci interessa, i nomi che si devono imparare sono Servlet e JSP. Queste tecnologie costituiscono
un importantissimo metodo di sviluppo di applicazioni web-based, e analizzandole meglio scopriremo che il
loro utilizzo è molto simile (per non dire uguale) al modo in cui siamo abituati a lavorare normalmente con
Java.

Le Servlet altro non sono che delle classi che lavorano sul server, e che per poter operare hanno bisogno di
un contesto, un motore che si occupi del loro utilizzo.

19.1 Apache Tomcat

Apache Tomcat è un servlet container Open Source rilasciato dall'Apache Software Foundation. Al
momento è arrivato alla versione 5, ed è proprio questa che utilizzeremo nelle nostre applicazioni.

Requisiti per l'installazione

Per installare ed utilizzare Tomcat è necessario un JRE (Java Runtime Environment) oppure un JDK (Java
Developer Kit), noi utilizzaremo il SUN JDK, liberamente scaricabile dal sito della Sun. Ipotizzando che il JDK
sia installato in /opt/java dovremo inserire la seguente riga nel file /etc/profile.
export JAVA_HOME=/opt/java
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=$JAVA_HOME/lib
dopodichè ricaricheremo in memoria il contentuto del file con (source)
. /etc/profile

Installazione

66
 Cestrone Pasquale

MANUALE START
Cominciamo scaricando il tarball di Tomcat precompilato dal sito http://Tomcat.apache.org/, dopodichè
l'unica operazione da compiere è quella di decomprimerlo in una directory a piacere.

Avvio di Tomcat
Posizioniamoci nella directory "bin" all'interno della cartella di Tomcat, e lanciamo il comando
./startup.sh

per avviare il server. Possiamo ora puntare il nostro browser a http://localhost:8080/ ; Se ci appare la
pagina di default di Tomcat significa che il server è perfettamente funzionante.

Struttura delle directory di Tomcat

Ecco il significato della struttura standard delle directory di Tomcat:
• bin/: contiene gli script per avviare ed arrestare Tomcat

• common/: librerie e classi disponibili per tutte le applicazioni web installate (si veda webapps/) e
rese disponibili anche all'applicazione Tomcat

• conf/: vi risiedono i file di configurazione, principalmente i descrittori in formato xml e i file

properties

• logs/: qui vengono salvati i file di log

• server/: classi e librerie necessarie per il funzionamento di Tomcat, e visibili solo da esso

• shared/: similmente alla directory common/ ogni classe e libreria qui contenuta viene resa
disponibile a tutte le applicazioni web installate; però, a differenza di common/, tali librerie e classi
non sono rese disponibili anche all'applicazione Tomcat

• temp/: directory di lavoro temporanea

• webapps/: in essa risiedono le applicazioni web; basterà copiare qui un archivio .war (web
application resource) perchè esso venga automaticamente deployato da apache; viceversa, basterà
rimuoverlo perchè esso venga un-deployato.

• work/: è la directory dove Tomcat mette i file compilati a partire dalle JSP

Struttura delle directory di un'applicazione web

Normalmente le applicazioni web sono distribuite come archivi .war, generati con l'utility jar, con una
determinata struttura di directory al suo interno.

La directory di più alto livello viene chiamata "document root"; tipicamente al suo interno risiedono i file
statici, ma è possibile posizionarci anche delle JSP. (ovviamente nulla vieta che i files possano anche risiedere
in sottocartelle della docroot)
All'interno della docroot deve essere presente la cartella WEB-INF, dentro la quale risiedono le risorse della
web application. In particolare è obbligatoria la presenza del file web.xml (trattato meglio in seguito), il
descrittore dell'applicazione (descrive le servlet e gli altri componenti che compongono l'applicazione, come
ad esempio parametri di inizializzazione, vincoli per la sicurezza e così via.)
All'interno di WEB-INF possono essere presenti le seguenti cartelle (ma non sono obbligatorie)

67
 Cestrone Pasquale

MANUALE START
• classes/: directory che contiene le classi (compilate) necessarie alla web application; tali classi sono
file con estensione .class, e non archivi .jar; la struttura delle sottodirectory deve essere compatibile
con la suddivisione in package Java

• lib/: vi si possono trovare sempre classi ed eventuali risorse, ma a differenza di classes/ qui ci sono
solo archivi .jar.

• jsp/: è buona norma tenere all'interno di questa cartella le pagine JSP che verranno poi richiamate
dalle servlet, e che non devono essere direttamente richiamabili dall'utente finale.

• tag/: all'interno di questa directory potremo trovare dei custom tag. vedremo la loro utilità in
seguito.

Il descrittore dell'applicazione web: web.xml

Come abbiamo visto prima, ogni applicazione deve essere dotate del file descrittore, il file web.xml all'interno
della directory WEB-INF.Qui è mostrato un file web.xml tipo, con le descrizioni dei tag come commenti xml.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-
app_2_4.xsd">

<!-- nome e breve descrizione della nostra applicazione -->

<display-name>applicazione 1</display-name>
<description>descrizione breve dell'applicazione 1</description>

<!-- i file indice, simile al DirectoryIndex di apache -->

<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>

<!-- dichiariamo ora la presenza di una servlet, e assegnamo un nome, in questo caso
servletIndice -->
<servlet>
<servlet-name>servletIndice</servlet-name>
<servlet-class>it.pluto.journal.java.SimpleIndexServlet</servlet-class>
</servlet>

<!-- ora diciamo a Tomcat di ridirigere tutte le richieste per index.html verso la servlet con
nome servletIndice -->
<servlet-mapping>
<servlet-name>servletIndice</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
</web-app>

Servlet e jsp, queste sconosciute

Cosa sono Servlet e JSP?
Una servlet è un componente web sviluppato in Java che genera contenuto dinamico, il cui scopo è quello di
estendere le funzionalità di un servlet containter, mentre le JSP, Java Server Pages, sono la tecnologia,
complementare a quella delle servlet (come avremo modo di vedere meglio in seguito), per la creazione di
pagine web dinamiche. Questi standard sono molto diffusi in quanto dispongono di caratteristiche
migliorative che li differenziano dalle altre tecnologie disponibili, come CGI, PHP e ASP, e che possiamo
riassumere in diversi punti:
• Efficienza: il modello di esecuzione delle servlet è più efficiente rispetto a quello di una applicazione
CGI: nel modello CGI viene creato un nuovo processo per ogni richiesta da esaudire, nel caso delle

68
 Cestrone Pasquale

MANUALE START
servlet, invece, ad ogni richiesta corrisponde la creazione di un thread, operazione molto meno
onerosa per il server.
• Portabilità: un'applicazione web sviluppata in Java è indipendente dal server web e dal sistema
operativo: essa è portabile su tutte le piattaforme per cui esista una Virtual Machine e fornisce quindi
una maggiore flessibilità.
• Robustezza: un aspetto importante delle servlet è la robustezza: il codice Java gira all'interno della
Virtual Machine che è un elemento isolato rispetto al sistema operativo. Eventuali errori di
programmazione non possono creare malfunzionamenti tali da danneggiare il corretto
funzionamento del web server.
• Scalabilità: l'architettura delle servlet consente in modo piuttosto naturale di introdurre tecniche di
bilanciamento del carico (load balancing) suddividendolo tra più server.
• Potenza: la persistenza di una servlet su più richieste (una servlet rimane in memoria fino a quando
non viene terminata) consente di condividere facilmente informazioni tra i thread corrispondenti e
di sincronizzare le richieste; questo semplifica notevolmente, ad esempio, la realizzazione di
applicazioni di tipo collaborativo.
• Accesso alle API standard: basandosi sulla piattaforma Java, le servlet possono accedere ad un ampio
ventaglio di API quali JDBC (Java Database Connectivity) per l'accesso ai database relazionali, JAXP
(Java API for XML Processing) che permette di trattare con documenti XML, JCA (Java2EE Connection
Architecture) che consente l'integrazione di applicazioni esistenti, ecc.
• Librerie di base: il codice di implementazione delle servlet può fare affidamento su un ampia gamma
di funzioni presenti nella libreria di base di Java e nelle sue estensioni, che è estremamente completa
(supera di diverse lunghezze quelle disponibili in PHP o ASP). Questo aspetto può comportare un
netto risparmio del tempo di sviluppo, in quanto molte funzionalità non devono essere implementate
ma possono essere semplicemente riutilizzate.

Ma che differenza c'è tra una Servlet e una JSP?

Sono sostanzialmente la stessa cosa. Una pagina JSP, che consente di inserire al suo interno componenti
dinamiche (che vengono eseguite ad ogni accesso alla pagina e possono essere utilizzate per generare output
personalizzato), è, in effetti, una servlet, nel senso che essa, per poter essere eseguita, viene trasformata in
una servlet equivalente. In particolare i componenti dinamici vengono trasformati in opportuni frammenti di
codice java, mentre il contenuto statico viene convertito in istruzioni di output. Ma allora che bisogno
abbiamo di avere sia le servlet che le jsp? Dal punto di vista delle funzionalità nessuno, ma la giustificazione
sta nelle diverse professionalità a cui si rivolgono.Nello sviluppo di applicazioni web-based di una certa
complessità sono/possono essere coinvolte figure con specializzazioni molto diverse: da un lato i
programmatori, preposti allo sviluppo della logica dell'applicazione, dall'altro i grafici/web designer, che si
occuperanno dell'interfaccia utente dell'applicazione (livello di presentazione).Tipicamente i primi hanno
competenze che vanno dalla conoscenza del linguaggio di programmazione alla progettazione della base di
dati, i secondi si focalizzano sulle tecnologie di web-publishing (html, xhtml, css, etc...).Con servlet e JSP ci si
rivolge a entrambe le categorie: mentre i programmatori si troveranno a loro agio nello sviluppo di servlet, i
web designer potranno concentrarsi sullo sviluppo delle pagine JSP, senza che venga a loro chiesta alcuna
conoscenza del linguaggio Java. Nella pratica quindi, gli unici elementi estranei al loro dominio con cui
dovranno confrontarsi saranno i tag JSP forniti dai programmatori (custom tag).Anche se le due figure
coincidono la separazione dei livelli di logica e presentazione è utile; ad esempio si possono facilmente
effettuare delle modifiche sull'interfaccia grafica senza correre il rischio di modificare la logica applicativa.

L'architettura di un'applicazione
L'architettura di un'applicazione è sostanzialmente la struttura, definita dal progettista, che dovrà avere
l'applicazione stessa: è quindi un elemento che vincola e definisce la forma e la sostanza del futuro lavoro di

69
 Cestrone Pasquale

MANUALE START
sviluppo. Il modo più efficiente per progettare un'architettura applicativa consiste nella scomposizione in
componenti separati che possano essere sviluppati, modificati o aggiornati indipendentemente dall'intera
applicazione; questo consente alle applicazioni di essere sviluppate in ambienti di collaborazione in team e
porta, inoltre, alla scrittura di un codice più facile da gestire rispetto alle applicazioni basate su un progetto
centralizzato. A proposito di quest'ultima affermazione, infatti, occorre precisare che, integrare del codice
Java in una pagina JSP, per quanto potente ed utile possa essere, è intrinsecamente pericoloso: più se ne
inserisce più sarà difficile avere accesso alla pagina, e, inoltre, il codice Java amalgamato con il linguaggio
HTML diventerà più difficile da leggere. Un sistema che evita questo inconveniente poichè consente di
mantenere il codice Java distinto dalla pagina JSP è rappresentato dall'uso di servlet per l'elaborazione dei
dati, e l'uso delle jsp (richiamate dalle servlet stesse) per la presentazione dei dati elaborati.

La maggior parte delle applicazioni web organizza i vari componenti in più livelli logici:
• logica della presentazione: coinvolge l'interfaccia utente e gli elementi basati sul web come HTML
o XML. Si occupa della visualizzazione delle informazioni o di come l'applicazione sceglie di
visualizzarle, ma non di come tali informazioni vengono recuperate;
• logica di controllo: si occupa di "controllare" il flusso dell'applicazione e funge da collegamento tra
l'interfaccia utente e l'applicazione stessa. La logica del controllo riceve e interpreta la richiesta http
decidendo il passo successivo da far intraprendere all'applicazione in base all'input dell'utente;
• logica applicativa : conosciuta anche come "logica di business", rappresenta il centro
dell'applicazione stessa poichè è responsabile di ciò che di fatto l'applicazione svolge.
L'unione di questi livelli è meglio conosciuta con il nome di "paradigma MVC (model, view, controller)",
molto famoso per la sua flessibilità e potenza.

Per approfondimenti visita il sito: http://www.pluto.it/files/journal/pj0711/j1.html

70
 Cestrone Pasquale

MANUALE START
21. Replica di Active Directory e ruoli FSMO
Il database di Active Directory non ha una struttura monolitica ma è organizzato in partizioni o naming
context che identificano strutture gerarchiche di oggetti, ciascuna delle quali costituisce un'unità di
replicazione indipendente. Le partizioni Active Directory possono essere di tipo generale oppure di tipo
applicativo (Active Directory Partition ADP).

Le partizioni generali possono essere di tre specie:

• Schema Partition. Contiene la definizioni degli oggetti (attributi e classi) utilizzabili in Active Directory
(user, group, computer, organizational unit, etc...) e delle regole di utilizzo. Esiste una sola Schema
Partition per ogni ciascuna foresta.

• Configuration Partition. Contiene informazioni generali sulla struttura e la composizione di una

foresta (site, subnet, partizioni che compongono la foresta, dc, etc...). Esiste una sola Configuration
Partition per ogni ciascuna foresta.

• Domain Partition. Contiene informazioni sugli oggetti creati in ogni dominio (user, group, computer,
organizational unit, etc...). Esiste una sola Domain Partition per ogni dominio appartenente alla
stessa foresta.

Le informazioni della Schema Partition e della Configuration Partition sono comuni a tutti i domini della
foresta e quindi verranno replicate a tutti i DC della foresta, mentre le informazioni della Domain Partition
sono private del dominio e quindi verranno replicate solo ai DC dello stesso dominio.

Le partizioni applicative possono essere di due specie:

• ADP builtin. Sono quelle dedicate al DNS (DomainDnsZones e ForestDnsZones) create

automaticamente all'atto della creazione del dominio, nel caso si scelga di installare e configurare il
servizioDNS dal wizard Dcpromo.

• ADP custom o personalizzate. Possono essere create manualmente per ospitare informazioni
riguardanti applicazioni integrate in Active Directory (AD-aware)

Il processo di replica di Active Directory mantiene allineate le Directory Partition dei DC tramite una tipologia
multimaster incrementale che consente di effettuare modifiche su qualsiasi DC e far sì che questo fornisca
agli altri DC soltanto le differenze rispetto all'ultima sincronizzazione avvenuta. Per minimizzare i conflitti
dovuti a modifiche dello stesso oggetto su DC diversi Active Directory implementa la replica a livello di singolo
attributo, I DC, infatti, a seguito di una modifica aggiornano lo stamp associato all'attributo che è compostato
da un Version Number (incrementato ad ogni modifica), un Timestamp (data e ora della modifica) e da un
Server GUID (contenente il GUID del DC su cui è avvenuta la modifica). Nella comparazione degli stamp si
considera il Version Number maggiore, nel caso ugualianza si considera il Timestamp maggiore e se anche il
Timestamp è uguale si valuta il Server GUID.

Allo scopo di evitare conflitti di replica non risolvibilit tramite la comparazione degli stamp, Active Directory
introduce l'amministrazione centralizzata di alcune operazioni, in altre parole alcune attività possono essere
eseguite esclusivamente a seguito dell'autorizzazione data dal DC in possesso del ruolo associato alla
specifica tipologia di operazione. Tali ruoli sono definiti flexible o Floating Single Master Operations (FSMO)
in quanto è possibile spostare un ruolo assegnandolo ad un altro DC.

71
 Cestrone Pasquale

MANUALE START

I ruoli FSMO sono cinque:

• Schema Master. Lo Schema Master è l'unico DC della foresta che possiede una copia i scrittura della
Schema Partition (ciò significa che la modifica dello schema può essere seguita da un qualunque DC,
ma prevede la connessione diretta con lo Schema Master).

• Domain Naming Master. Il Domain Naming Master è unico nella foresta e viene contattato quando è
necessario creare un dominio per verificare che non sia già stato definito e ottenere un identificatore
GUID univoco. Il Domain Naming Master è responsabile anche dell'autorizzazione alla cancellazione
di un dominio, della validazione durante le operazioni di modifica dei nomi di dominio tramite il tool
RENDOM.EXE e della creazione e cancellazione di una Application Directory Partition.

• Relative Identifier Master. Il Relative Identifier Master è unico nel dominio ed è responsabile della
distribuzione dei pool contenenti le sequenze univoche dei Relative ID (RID) ai DC del dominio. I RID
sono utilizzati dai DC durante la creazione degli oggetti Security Principal (User, Group o Computer)
per attribuirgli identificativi Security ID (SID) univoci.Il Relative Identifier Master si occupa anche di
autorizzare lo spostamento di un oggetto in un altro dominio, tramite ad esempio l'Active Directory
Migration Tool, per evitare che lo stesso oggetto possa essere spostato in due domini diversi.I DC del
dominio ricevono un pool di 500 RID dal Relative Identifier Master e quando la quantità disponibile
raggiunge circa le 100 unità il DC contatterà il Relative Identifier Master per ottenere un nuovo pool.
Un SID è composto da 4 elementi S-1-5-Y1-Y2-Y3-Y4:

o S-1 che indica la revisione del SID (al momento è in uso la 1)

o 5 che definisce l'autorità di emissione del SID (5 indica Windows NT, 2000 o 2003 Server, per
i well know SID si utiliza 0 o 1)

o Y1-Y2-Y3 è la porzione del domain SID (uguale per tutti i Security Principal del dominio)

o Y4 rappresenta il relative ID del dominio.

• PDC emulator. il PDC emulator è unico nel domino e viene utilizzato come fonte di replica (master-
slave) degli update della Domain Partition verso i BDC NT nel caso in cui il livello funzionale del
dominio sia Windows server 2003 Interim o Windows 2000 Mixed Mode. il PDC emulator viene
inoltre contattato da client precedenti Windows 2000 su cui non è installato l'Active Directory client
durante la fase di cambio password degli account e per offrire piena compatibilità verso essi. Il PDC
emulator assolve anche la funzionalità di Domain Master Browser e indipendentemente dal livello
funzionale del dominio ha i seguenti compiti:

o Diminuire il tempo di convergenza nei cambi password.

o Essere la fonte di sincronizzazione del Windows Time Service (in una foresta i DC di un
dominio usano il PDC emulator del proprio dominio come time source e a loro volta i PDC
emulator dei vari domini della foresta usano come time source il PDC emulator del Forest
Root Domain il quale può essere sincronizzato su un time server esterno tramite il comando
net time \\servername /setsntp:TimeServer).

72
 Cestrone Pasquale

MANUALE START
o Essere utilizzato di default dallo snap-in di creazione o modifica di un Group Policy Object.

o Autorizzare il raise del livello funzionale del dominio.

• Infrastructure Master. l'Infrastructure Master è l'unico DC nel domino che ha il compito di mantenere
aggiornata la relazione GUID-SID-DN degli utenti/gruppi definiti nei domini esterni a quello di
appertenenze dell'Infrastructure Master, ma utilizzati anche nei gruppi del suo dominio (phantom
record). In caso di modifica del Distinguished Name (DN) (per es. spostamento nel domino) o del SID
(per es. spostamento in altri domini) di tali utenti/gruppi la visualizzazione dei membri dei gruppi che
li contengono non deve produrre incoerenze. Per ottenere tale risultati l'Infrastructure Master
verifica e aggiorna periodicamente eventuali differenze tra il proprio database locale di phantom
record e le informazioni nei Global Catalog server.

73
 Cestrone Pasquale

MANUALE START
22. Glossario – Definizioni
CONCETTO DEFINIZIONE
Apache Tomcat Apache Tomcat (o semplicemente Tomcat) è un
web server (nella forma di contenitore servlet) open
source sviluppato dalla Apache Software
Foundation. Implementa le specifiche JavaServer
Pages (JSP) e servlet, fornendo quindi una
piattaforma software per l'esecuzione di
applicazioni Web sviluppate in linguaggio Java. La
sua distribuzione standard include anche le
funzionalità di web server tradizionale, che
corrispondono al prodotto Apache.
Architettura hw/sw di tipo multi-tier Nell'ingegneria del software, il termine architettura
multi-tier o architettura multi-strato (spesso
definita con l'espressione inglese n-tier
architecture) indica un'architettura software in cui
le varie funzionalità del software sono logicamente
separate ovvero suddivise su più strati o livelli
software differenti in comunicazione tra loro (nel
caso di applicazioni web questi strati sono la logica
di presentazione, l'elaborazione dei processi e la
gestione della persistenza dei dati). Ciascuno strato
è in comunicazione diretta con quelli adiacenti
ovvero richiede ed offre servizi allo strato adiacente
in maniera concettualmente simile a quanto accade
con le architetture di rete a strati (in linguaggio
strettamente informatico si dice che ciascuno strato
è client-server per gli strati adiacenti, fatta
eccezione per gli strati estremi che sono solo client
o solo server).
Three-tier è un'architettura client-server in cui
l'interfaccia utente, i processi logico funzionali
("regole aziendali"), l'archiviazione informatica dei
dati e l'accesso ai dati sono sviluppate e mantenute
come moduli indipendenti, la maggior parte delle
volte su piattaforme separate
Load Balancer In informatica il load balancing, in italiano
bilanciamento del carico, è una tecnica
informatica utilizzata nell'ambito dei sistemi
informatici che consiste nel distribuire il carico di
elaborazione di uno specifico servizio, ad esempio
la fornitura di un sito web, tra più server,
aumentando in questo modo scalabilità e
affidabilità dell'architettura nel suo complesso. In
pratica se arrivano 10 richieste per una pagina web
su un cluster di 3 server, alle prime 3 risponderà il
"primo" server, a 3 il "secondo" ed alle ultime 4 il
"terzo". La scalabilità deriva dal fatto che, nel caso
sia necessario, si possono aggiungere nuovi server
al cluster, mentre la maggiore affidabilità deriva
dal fatto che la rottura di uno dei server non

74
 Cestrone Pasquale

MANUALE START
compromette la fornitura del servizio (fault
tolerance) agli utenti; non a caso i sistemi di load
balancing in genere integrano dei sistemi di
monitoraggio che escludono automaticamente dal
cluster i server non raggiungibili ed evitano in
questo modo di far fallire una porzione delle
richieste di servizio degli utenti. Viene da sé che
affinché l'architettura sia in high availability (HA)
anche il sistema di load balancing deve essere
costituito da un cluster in HA. Per ottenere il load
balancing in genere si interviene o a livello
applicazioni o di rete della pila ISO/OSI. Nel primo
caso si ha una maggiore flessibilità, non sempre
utile, ma nel secondo caso si riescono a gestire
moli di traffico decisamente maggiori.
Caching Il Web caching è la caching di documenti web
(pagine HTML, immagini, ecc.) per permettere di
ridurre l'uso della banda e il tempo di accesso ad
un sito web. Una web cache memorizza copie di
documenti richiesti dagli utenti, successive
richieste possono essere soddisfatte dalla cache se
si presentano certe condizioni. Le Web cache di
solito raggiungono picchi d'efficienza nell'ordine
del 30%-50%, e migliorano la loro efficienza al
crescere del numero di utenti.
Concetto AS-IS e TO-BE Manager ed analisti tendono a migliorare
l'efficienza e l'efficacia dei processi aziendali,
ovvero a ridurre i costi e ad accrescere la qualità
intesa come soddisfazione del cliente. In questo
campo, il Business Process Modeling (BPM) è
l'attività di rappresentazione dei processi aziendali
nelle due ottiche:
• la situazione attuale, detta "as-is"
• la situazione futura desiderata, "to-be"
La mappatura dei processi reali ("as-is") e di quelli
a tendere ("to-be") sono due attività di analisi
nettamente distinte, che portano a definire i
miglioramenti necessari per passare dai processi
rilevati nell' "as-is" a quelli formalizzati nel "to-be".
Gli interventi possono essere di tipo incrementale
ed essere inclusi nell'ambito del BPM, oppure di
tipo radicale, aprendo così la tematica della
reingegnerizzazione dei processi aziendali
(Business Process Reengineering o BPR). Gli
interventi possono riguardare sia la tecnologia che
l'organizzazione, e comportano normalmente
anche una attività di formazione sui nuovi processi.
Connection pool In ingegneria del software , un pool di connessioni
è una cache di connessioni al database mantenuto
in modo che i collegamenti possono essere
riutilizzati quando sono richieste future richieste al
database. I pool di connessione vengono utilizzati

75
 Cestrone Pasquale

MANUALE START
per migliorare le prestazioni dell'esecuzione di
comandi su un database. Apertura e gestione di
una connessione al database per ciascun utente, è
costoso e spreca risorse. Nel pool di connessioni,
dopo aver creato una connessione, questa viene
inserita nel pool e viene utilizzata di nuovo in
modo che non sia necessario stabilire una nuova
connessione. Se vengono utilizzate tutte le
connessioni, viene creata una nuova connessione
che viene aggiunta al pool. Il pool di connessioni
riduce anche la quantità di tempo che un utente
deve attendere per stabilire una connessione al
database.
Domain Controller (DC) In informatica, nell'ambito delle reti gestite con
Microsoft Windows Server System, un domain
controller (DC) è un server che, nell'ambito di un
dominio, attraverso Active Directory (AD), gestisce
le richieste di autenticazione per la sicurezza (login,
controllo dei permessi, ecc.) e organizza la
struttura del dominio in termini di utenti, gruppi e
risorse di rete fornendo dunque un servizio di
directory service. Un dominio può a sua volta far
parte di un dominio di livello superiore il cui server,
che esegue AD, si chiama Primary Domain
Controller.
In altri sistemi operativi le medesime funzioni sono
svolte da applicazioni open source su piattaforma
Linux, quali CentOS su cui si può poi installare
Samba che espleta le funzioni di DC supportante
un framework simile ad AD. In pratica, il concetto
di DC, di origine Windows, ora è utilizzato in senso
generale anche all'infuori di tecnologie Microsoft.
Database ODBC In informatica Open DataBase Connectivity (ODBC)
è un driver o connettore attraverso un'API
standard per la connessione dal client al DBMS.
Questa API è indipendente dai linguaggi di
programmazione, dai sistemi di database e dal
sistema operativo. ODBC si basa sulle specifiche di
Call Level Interface (CLI) di SQL, X/Open (ora parte
di The Open Group) e ISO/IEC. È stata creata
dall'SQL Access Group e la sua prima release risale
al settembre 1992.
ODBC è un'interfaccia nativa grazie alla quale si
può accedere tramite linguaggi che siano in grado
di chiamare funzioni di librerie native. Nel caso di
Microsoft Windows, questa libreria è una DLL. La
prima versione è stata sviluppata su Windows;
altre release sono state scritte per UNIX, OS/2 e
Macintosh.
In aggiunta al software ODBC, c'è bisogno di un
driver specifico per poter accedere ad ogni diverso
tipo di DBMS. ODBC permette ai programmi che lo

76
 Cestrone Pasquale

MANUALE START
usano di inviare ai database stringhe SQL senza che
ci sia bisogno di conoscerne le API proprietarie.
Genera automaticamente richieste che il sistema di
database utilizzato sia in grado di capire.
In tal modo, i programmi possono connettersi a
diversi tipi di database utilizzando più o meno lo
stesso codice.
Un JDBC-ODBC Bridge è un driver JDBC che
impiega un driver ODBC per connettersi al DBMS.
Questo driver traduce le chiamate a metodi JDBC
in chiamate a metodi ODBC. Il bridge, in genere,
viene utilizzato quando non esiste un driver JDBC
per un certo DBMS (il che accadeva spesso quando
JDBC era ancora poco diffuso, mentre oggi è
abbastanza raro).
UnixODBC è l'implementazione ODBC più usata per
piattaforme UNIX.
DHCP In telecomunicazioni e informatica il Dynamic Host
Configuration Protocol (DHCP) (protocollo di
configurazione IP dinamica) è un protocollo di rete
di livello applicativo che permette ai dispositivi o
terminali di una certa rete locale di ricevere
automaticamente ad ogni richiesta di accesso a
una rete IP (quale una LAN) la configurazione IP
necessaria per stabilire una connessione e operare
su una rete più ampia basata su Internet Protocol,
cioè interoperare con tutte le altre sottoreti
scambiandosi dati, purché anch'esse integrate allo
stesso modo con il protocollo IP. Il protocollo è
implementato come servizio di rete ovvero come
tipologia di server: ad es. nei sistemi Unix e Unix-
like è implementato nel demone dhcpd, in quelli
basati su Active Directory di Microsoft e/o
Windows Server dal servizio server dhcp.
DNS Il sistema dei nomi di dominio (in inglese: Domain
Name System, DNS), è un sistema utilizzato per la
risoluzione di nomi dei nodi della rete (in inglese:
host) in indirizzi IP. Il servizio è realizzato tramite
un database distribuito, costituito dai server DNS. Il
DNS ha una struttura gerarchica ad albero
rovesciato ed è diviso in domini (com, org, it, ecc.).
Ad ogni dominio o nodo corrisponde un
nameserver, che conserva un database con le
informazioni di alcuni domini di cui è responsabile
e si rivolge ai nodi successivi quando deve trovare
informazioni che appartengono ad altri domini.
Ogni nome di dominio termina con un “.” (punto).
Ad esempio l'indirizzo wikipedia.org termina con il
punto. La stringa vuota che segue il punto finale è
chiamata dominio radice (DNS root zone). I server
responsabili del dominio radice sono i cosiddetti
root nameservers.

77
 Cestrone Pasquale

MANUALE START
EJB In informatica gli Enterprise JavaBean (EJB) sono i
componenti software che implementano, lato
server, la logica di business di un'applicazione web
all'interno dell'architettura/piattaforma Java EE
espletando servizi a favore della parte di front-end
ovvero per la logica di presentazione di
un'applicazione web. Rappresentano dunque uno
strato software residente su un application server
all'interno di un'architettura software di tipo multi-
tier.Le specifiche per gli EJB definiscono diverse
proprietà che questi devono rispettare, tra cui la
persistenza, il supporto alle transazioni, la gestione
della concorrenza e della sicurezza e l'integrazione
con altre tecnologie, come JMS, JNDI, e CORBA. Lo
standard attuale, EJB 3.2, completato nella
primavera del 2013[1], differisce notevolmente
dalla versione 2.1 delle specifiche, in quanto
introduce la possibilità di effettuare dependency
injection e di effettuare mediante annotations le
configurazioni che precedentemente avvenivano
mediante XML. Gli EJB necessitano di un EJB
container tipicamente implementato all'interno
degli application server assieme al servlet
container per la parte di front-end.
EJB Session Stateless Gli EJB Session Bean sono delle classi con dei
metodi invocabili da remoto (semplificando molto
possiamo dire che sono come le servlet, ma le
servlet hanno solo due metodi doget e dopost, i
session invece possono avere tutti i metodi che
vogliamo). Sono composti da una classe e due
interfacce. Per poter invocare un EJB Session
bisogna avere una delle interfacce. Le interfacce
sono dette locali o remote, in basa a dove
permettono di richiamare il session. Da remoto
vengono utilizzati i protocolli distribuiti come RMI-
IIOP (Remote Method Invocation o RMI è una
tecnologia che consente l’invocazione remota dei
metodi);
Gli EJB Session sono transazionali, ossia
permettono di gestire le transazioni.
Esistono due tipi di session bean:

• stateful: viene memorizzato lo stato fra

una richiesta e l’altra del client, ossia
garantisce che tutti i campi dell’EJB
Session saranno salvati per la successiva
richiesta dello stesso client.
• stateless: non viene mantenuto alcun stato
e vengono utilizzati per modellare quelle
elaborazioni che si completano con una
sola richiesta

78

Port Forwarding
Funzione di Commit , Recovery
Funzione di Rollback
79
Cestrone Pasquale
MANUALE START
Nelle reti informatiche il port forwarding è
l'operazione che permette il trasferimento dei dati
(forwarding) da un computer ad un altro tramite
una specifica porta di comunicazione. Questa
tecnica può essere usata per permettere ad un
utente esterno di raggiungere un host con indirizzo
IP privato (all'interno di una LAN) mediante una
porta dell'IP pubblico dello stesso. Per eseguire
questa operazione si ha bisogno di un router in
grado di eseguire una traduzione automatica degli
indirizzi di rete, detta NAT. Questo permette a
computer esterni di connettersi a uno specifico
computer della rete locale, a seconda della porta
usata per la connessione. Ad esempio:
• il forwarding della porta 8000 dal router a
un computer interno permette a quel
computer di usare il sistema Shoutcast.
Nei sistemi Linux, il port forwarding può essere
realizzato tramite il sistema netfilter/iptables. Per
tale sistema sarà necessario modificare la tabella
nat aggiungendo l'obiettivo DNAT alla catena
PREROUTING, e l'obiettivo SNAT alla catena
POSTROUTING. Operativamente, l'utente dal
browser del proprio PC con un indirizzo "http:// IP
del router" accede alle opzioni di configurazione
del router, nel quale dichiara una sincronizzazione
fra una porta del router e la corrispondente nel
proprio PC. Ad esempio nei programmi di file
sharing, si potranno dichiarare le porte TCP1,
UDP2, TCP3 (per l'accesso remoto). Le tre porte
andranno impostate nel PC come predefinite per i
protocolli TCP e UDP, e per l'accesso da remoto;
nel router in una scheda per il port forwarding si
dovranno inserire una start port del router e una
end port, quella del PC, che saranno sincronizzate.
Perché il router riconosca il computer, è necessario
creare un indirizzo IP statico. L'utente deve
configurare sul PC l'ip del router come gateway
predefinito, nel router sceglie un indirizzo IP fra
quelli disponibili, nella configurazione del router
trascrive l'IP scelto nell'elenco degli IP statici e vi
aggiorna di conseguenza il range IP degli indirizzi
disponibili.
Un'operazione di commit rende permanenti tutte
le modifiche eseguite sotto il controllo del commit
dopo la precedente operazione di commit o
rollback. Il sistema rilascia anche tutti i blocchi
correlati alla transazione.
Un'operazione di rollback elimina tutte le
modifiche apportate dopo la precedente
 Cestrone Pasquale

MANUALE START
operazione di commit o rollback. Il sistema rilascia
anche tutti i blocchi correlati alla transazione.
Disaster Recovery Il Disaster Recovery (brevemente DR, in italiano:
Recupero dal Disastro), in informatica ed in
particolare nell'ambito della sicurezza informatica,
si intende l'insieme delle misure tecnologiche e
logistico/organizzative atte a ripristinare sistemi,
dati e infrastrutture necessarie all'erogazione di
servizi di business per imprese, associazioni o enti,
a fronte di gravi emergenze che ne intacchino la
regolare attività.
Group Policy In informatica le Group Policy (criteri di gruppo in
italiano) è una caratteristica della famiglia
Microsoft Windows NT dei sistemi operativi. Le
group policy sono un insieme di regole che
controllano l'ambiente di lavoro di utenti e
computer. Forniscono la gestione centralizzata e la
configurazione di sistemi operativi, applicazioni e le
impostazioni degli utenti in un ambiente Active
Directory. In altre parole, le group policy in parte
controllano ciò che gli utenti possono o non
possono fare su un sistema informatico. Anche se
le group policy sono più spesso viste in uso per gli
ambienti aziendali, sono anche comuni in altri
ambiti come nelle scuole, nelle imprese più piccole
e altri tipi di organizzazioni. Il criterio di gruppo è
spesso utilizzato per limitare determinate azioni
che possono rappresentare potenziali rischi di
protezione, ad esempio: per bloccare l'accesso al
Task Manager, limitare l'accesso a determinate
cartelle, disabilitare il download di file eseguibili,
disabilitare l'uso di unità esterne (penne USB,
dischi ottici) e così via.
Intranet In informatica e telecomunicazioni l'intranet è una
rete aziendale privata che utilizza il protocollo
TCP/IP, ma può estendersi anche con collegamenti
WAN e VPN. Spesso tale rete o è completamente
isolata dalla Rete Internet esterna (es. LAN),
rimanendo a solo uso interno, oppure comunica
eventualmente con la rete esterna e le altre reti,
attraverso opportuni sistemi di comunicazione e
relativa protezione(come ad esempio un firewall).
A volte il termine è riferito, a livello logico e non
infrastrutturale, solo alla rete di servizi più visibile,
il sistema di siti che formano uno spazio web
interno (ad esempio a un'azienda o ad una
organizzazione). In altre eccezioni il termine può
essere inteso come il sistema di informazioni e
servizi di utilità generale accessibili dalla rete
interna. Quando una parte della intranet viene
resa accessibile a clienti, partner o altre persone
esterne all'organizzazione, tale parte diventa una

80
 Cestrone Pasquale

MANUALE START
extranet. Se a livello tecnologico l'intranet può
essere definita come la rete informatica interna
basata sul protocollo TCP/IP, negli ultimi anni il
concetto ha assunto una forma diversa,
oltrepassando gli aspetti tecnologici per impattare
fortemente sull'organizzazione dell'impresa.
IPTABLE Iptables è un potente firewall integrato nel kernel
Linux ed è una parte del progetto netfilter. Può
essere configurato direttamente, oppure usando
uno dei vari frontends oppure una delle GUI.
iptables è utilizzato per gli IPv4 mentre ip6tables è
usato per gli IPv6.
JBoss In informatica WildFly, precedentemente noto
come JBoss AS o semplicemente JBoss, è un
application server open source che implementa le
specifiche Java EE. WildFly è un sistema
multipiattaforma, interamente realizzato in Java.
Originariamente creato dalla società "JBoss Inc.",
nel 2006, il sistema è stato acquistato da Red Hat
per 420 milioni di dollari e viene gestito come
progetto open source, sostenuto da un'enorme
rete di sviluppatori. Componenti del prodotto:

• Clustering
• Failover (comprese le sessioni)
• Load balancing
• Distributed caching (utilizzando JBoss Cache, un prodotto
standalone)
• Distributed deployment (farming)
• Enterprise JavaBeans
• supporto per Aspect-Oriented Programming(AOP)
(vedi Programmazione orientata agli aspetti)
• Integrazione con Hibernate(per la persistence
programming; JPA)
• Supporto per Web Service JAX-RPC (Java API for XML for
Remote Procedure Call)
• Integrazione con Java Message Service
• Integrazione con J2EE Connector Architecture (Java
Connector Architecture)
• Integrato con JACC (Java Authorization Contract for
Containers)
• JSP/Servlet (Undertow)
• RMI IIOP (JacORB, alias Java and CORBA)
• JTA (Java Transaction API)
• JDBC
• SAAJ (SOAP with Attachments API for Java)
• JNDI (Java Naming and Directory Interface)
• JAAS (Java Authentication and Authorization Service)
• JavaMail
• Deployment API
• Management API

Legacy In informatica, un sistema legacy (ereditato, che è

un lascito del passato) è un sistema informatico,

81
 Cestrone Pasquale

MANUALE START
un'applicazione o un componente obsoleto, che
continua ad essere usato poiché l'utente (di solito
un'organizzazione) non intende o non può
rimpiazzarlo. Legacy equivale a versione
"retrodatata" (rispetto ai sistemi/tecnologie
correnti). In alcuni casi ricorrere alla
versione/ambiente legacy è obbligatorio per poter
accedere a determinate condizioni/ambienti
operativi (ad esempio succede per la
configurazione di avvio del computer o quando
occorre installare vecchi dispositivi hardware). In
pratica: modalità di avvio legacy nel BIOS per
aggirare le impostazioni UEFI oppure l'utilizzo di
driver legacy per poter utilizzare una periferica
datata su sistemi operativi più recenti. Con questo
termine si indicano i sistemi IT che utilizzano
tecnologie meno recenti (di solito si tratta di
sistemi informatici con architettura hardware
centralizzata, ovvero con un mainframe) e per
questo motivo sono molto difficili da interfacciare
con i sistemi più recenti. Per tale interfacciamento
si può ricorrere a sistemi middleware, ma il costoso
utilizzo di questi ultimi spesso decreta la
sostituzione del legacy con tecnologie odierne. Il
termine può essere usato per riferirsi a sistemi
antiquati. Le ragioni che inducono a mantenere
sistemi legacy sono soprattutto dovute ai costi
sostenuti a suo tempo per la loro implementazione
e ai costi da sostenere per la migrazione a nuovi
sistemi.
Middleware In informatica con middleware si intende un
insieme di programmi informatici che fungono da
intermediari tra diverse applicazioni e componenti
software. Sono spesso utilizzati come supporto per
sistemi distribuiti complessi con architetture
multitier. L'integrazione dei processi e dei servizi,
residenti su sistemi con tecnologie e architetture
diverse, è un'altra funzione delle applicazioni
middleware. Esso oggi identifica una serie di
strumenti come DBMS, Web server, Application
server, sistemi di gestione dei contenuti ed altri
strumenti basati sul concetto di sviluppo e
pubblicazione di applicazioni e contenuti. Gli
sviluppi attuali si dirigono verso XML, SOAP, servizi
Web e architetture orientate al servizio.
Alcuni middleware contengono il codice sorgente
completo, altri rilasciano una semplice interfaccia
API per una libreria binaria precompilata. Alcuni di
questi possono essere licenziati in maniera
differente, solitamente per garantirsi un incasso
maggiore nella vendita del relativo codice. Un
esempio tipico di utilizzo del middleware è il

82

Operazioni di mission-critical
Primary Domain Controller
83
Cestrone Pasquale
MANUALE START
"gestore delle transazioni", ovvero un componente
che è interposto tra l'utente e il "gestore del
database", o l'applicazione in generale, o il sistema
client/server; in queste situazioni, il middleware
accelera il completamento delle richieste
dell'utilizzatore, raggruppandole, riducendo il
numero delle richieste di collegamento al
database, e rendendo ogni collegamento il più
efficiente possibile. Esempi di questo tipo di
programmi sono CICS, IBM WebSphere MQ, Tibco,
Tivoli, TradeXpress di Generix Group, Tuxedo e
Apache Tomcat. L'utilizzo di uno strato software
aggiuntivo, il middleware appunto, può consentire
un più elevato livello di servizio per gli utenti, ed
un più elevato livello di astrazione per i
programmatori. Può inoltre facilitare la
manutenzione, la stesura e l'integrazione di
applicazioni. Tale ruolo è, per certi versi,
un'evoluzione del ruolo del middleware, che in
partenza era limitato a ricercare l'efficienza nel
sistema. Lo sviluppo delle tecnologie internet ha
portato molti degli originali produttori a rivedere la
loro offerta per migliorare l'integrazione con il
nuovo strumento, ma ha portato anche alla nascita
di nuovi attori nel mercato come Mercator, Vitria,
e Webmethods. Alcuni consorzi come la "Apache
Software Foundation" e la "ObjectWeb
consortium" hanno tra i loro compiti, il facilitare lo
sviluppo di piattaforme middleware open source.
I Mission Critical System sono sistemi relativi a
informazioni, attrezzature o altre risorse di
un'impresa o di un progetto essenziali per la
corretta operatività dell'organizzazione. I requisiti
principali di questi sistemi sono la sicurezza dei
dati, la massima disponibilità e la scalabilità delle
prestazioni. Esempi di Mission Critical System sono
gli ATM, dati sulla contabilità e le registrazioni dei
clienti, le partenze degli shuttle oppure per
esempio il sistema di raffreddamento del nocciolo
di un reattore nucleare. Tutti quei sistemi insomma
che non possono mai essere disconnessi o
disalimentati per nessuna ragione se non per la
sicurezza del personale coinvolto nella missione.
Il Primary Domain Controller (o PDC) di un dominio
è un server in una rete con sistemi Windows NT
che si occupa di gestire il dominio su cui è eseguita
la Active Directory (AD) principale ovvero quello
che supporta l'intera rete, anche formata da diversi
domini (nel linguaggio Windows "foresta" di
domini). Pertanto, i server che eseguono i domini
aggiunti al dominio primario non sono dei PDC ma
 Cestrone Pasquale

MANUALE START
dei DC (Domain controller). Nel caso di dominio
semplice ovvero con un'unica struttura AD allora il
PDC coincide con l'unico DC e quindi si potrebbe
parlare unicamente di DC. Molte volte viene
affiancato al PDC un sistema di backup col nome di
Backup Domain Controller.[1] Per cautelarsi contro
eventuali guasti o errori del PDC, poteva essere
presente un Backup Domain Controller (BDC) che
conservasse copie di sola lettura del database
(però questi non conteneva tutti i dati come il
primo). Tuttavia la presenza del BDC sempre
sincronizzato insieme al PDC comportava un
rallentamento consistente delle attività a causa
dell'eccessivo traffico della rete. Infatti in Windows
2000 il PDC è sostituito da Active Directory,
perfezionato rispetto alla versione precedente.
Per definizione, un PDC può essere svolto solo da
un server Microsoft (invece, i DC possano essere di
altre piattaforme a cominciare dai sistemi Linux),
sebbene un software come Samba possa simulare
molto bene un PDC (o, meglio, la sua active
directory). Primary domain controller e domain
controller sono concetti che pur di origine
Microsoft ora sono utilizzati in senso generale,
anche disgiunti da ambienti non
Microsoft/Windows in senso stretto.
Provisioning Di seguito è riportata la sequenza di passaggi per il
processo di provisioning diretto in Microsoft Active
Directory:
1. La risorsa IT per il sistema di destinazione è
collegata all'oggetto risorsa selezionato per
l'operazione di provisioning. Quando si
inviano i dati di provisioning, questi dati e i
valori dei parametri della risorsa IT
vengono trasmessi all'attività di processo.
Ad esempio, le informazioni provenienti
dalla risorsa AD Server IT e dal modulo di
processo UD_ADUSER vengono trasmesse
all'attività Crea processo utente.

2. La task di processo trasmette le

informazioni all'adattatore a cui è
associato. Nell'esempio descritto nel
passaggio precedente, l'attività Crea
processo utente trasferisce le informazioni
all'adattatore adpADCSCREATEUSER.

3. L'adattatore inoltra la richiesta all'API di

Microsoft Active Directory.

4. L'API del sistema di destinazione crea

l'account utente sul sistema di

84
 Cestrone Pasquale

MANUALE START
destinazione e restituisce un codice di
risposta all'adattatore, che lo riporta al
task di processo. A seconda del codice di
risposta ricevuto, l'attività di processo
visualizza l'esito dell'operazione di
provisioning su Oracle Identity Manager
Administrative and User Console. Il
messaggio viene registrato anche nel file di
registro dell'application server.
Specifiche end-to-end L'end-to-end (da estremità a estremità) è uno dei
principi della progettazione delle reti di computer e
viene applicato su diversi protocolli di rete come il
protocollo UDP. Il principio end-to-end afferma
che, se si hanno due applicazioni che comunicano
tramite una rete, tutte le funzioni e le operazioni
specifiche richieste da tali applicazioni, come il
controllo di errori, devono essere realizzate ed
eseguite in modo completo nei nodi terminali (o
end point) e non nei nodi intermedi (o
intermediate node) della rete. In caso contrario,
cercando di ottenere delle funzioni operando sul
canale di trasmissione invece che sui nodi estremi,
si potrebbero non soddisfare i requisiti delle
applicazioni oppure si potrebbe penalizzare le
applicazioni presenti su altri nodi della rete. Come
conseguenza si afferma un nuovo modello di rete
"stupida" con terminali "intelligenti" (in
precedenza avveniva il contrario: rete
"intelligente" e terminali "stupidi"). Internet è una
rete basata sul modello Internet Protocol Suite e
adotta la coppia di protocolli TCP/IP: il protocollo
IP si occupa solo dell'instradamento della
comunicazione lungo i nodi della rete, mentre il
protocollo TCP stabilisce una connessione
affidabile. In questo caso la parte IP è la parte
"stupida" presente in tutti i nodi della rete, mentre
la parte TCP è la parte "intelligente", presente nei
nodi terminali (host). Di conseguenza, nella
trasmissione dati tra due processi client/server,
l'entità TCP di un host (Client) comunica
direttamente con l'entità TCP dell'altro host
(Server) senza alcun'altra entità TCP intermediaria
del livello di trasporto.
Sun Microsystem Azienda della Silicon Valley produttrice di software
e semiconduttori nota, tra le altre cose, per avere
prodotto il linguaggio di programmazione Java.
I prodotti Sun includevano server e workstation
basati sulle CPU SPARC, i sistemi operativi SunOS e
Solaris, il file system di rete NFS, il linguaggio di
programmazione Java, la suite OpenOffice.org ed
insieme ad AT&T, Sun partecipò alla
standardizzazione di Unix System V Release 4.

85

MicroStrategy Web
Cloudera Manager
Talend Administration Center
86
Cestrone Pasquale
MANUALE START
Prodotti di minor successo possono essere
considerati il gestore di finestre NeWS, la GUI
OpenLook e le prime versioni di Unix thin client
senza disco.Il 27 gennaio 2010, la Sun Microsystem
è stata acquistata dalla Oracle Corporation per 7,4
miliardi di dollari. La Sun Microsystems, Inc. è stata
quindi rinominata Oracle America, Inc.
MicroStrategy Web è un'applicazione Web
utilizzata nel contesto della Piattaforma Dati. La
nuova soluzione di gestione degli accessi basata su
CA SSO v12.7 sarà configurata come un fornitore
affidabile di autenticazione per MicroStrategy
Web: CA SSO fungerà da punto di riferimento per
l'applicazione delle policy e tutte le richieste di
MicroStrategy Web che passano attraverso CA SSO
Web Agent saranno arricchite con proprietà utente
aggiuntive dopo l'accesso. Tali proprietà saranno
poi elaborate a fini di profilazione da MicroStrategy
Web.
• On-premises (Secure Enterprise):
MicroStrategy può essere distribuito on-
premises su diversi sistemi operativi. Le
distribuzioni possono essere personalizzate
in modo da rispondere alle specifiche
necessità delle organizzazioni installando
diverse combinazioni di componenti
MicroStrategy.
• Cloud: MicroStrategy può essere
distribuito anche su cloud, consentendo ai
reparti IT di creare applicazioni di BI che
aggiungono rapidamente valore. Paga solo
ciò di cui hai bisogno e amplia la tua
configurazione man mano che il business
cresce aggiungendo licenze e capacità
server.
Cloudera Manager è un'applicazione Web utilizzata
nella soluzione Data Platform, il cui modello
attuale di gestione degli accessi sfrutta gli account
utente e i gruppi archiviati in un repository
OpenLDAP esterno che viene poi integrato con RSA
AM per fornire l'autenticazione multi-fattore.
L'approccio proposto si basa sul modello di accesso
Single Sign-On (Single Sign-On) avviato dal
fornitore di servizi.
Talend Administration Center è un'applicazione
Web utilizzata nel contesto della Piattaforma Dati,
la cui attuale soluzione di gestione degli accessi
sfrutta un repository esterno OpenLDAP che
fornisce autenticazione multi-fattore e un DB
interno. Tra la nuova soluzione di Access
Management basata su CA SSO v12.7 e Talend sarà
 Cestrone Pasquale

MANUALE START
garantita una partnership a livello di federazione.
L'approccio proposto si basa sul modello di accesso
Single Sign-On (Single Sign-On) basato sull'identità
del fornitore.
Google Cloud Platform L'approccio utilizzato per implementare la Google
Cloud Platform è una partnership di federazione
tra la nuova soluzione di Access Management
basata su CA SSO v12.7 e GCP(Google Cloud
Platform), utilizzata per fornire servizi e
funzionalità nell'ambito del progetto Data
Platform. La soluzione proposta si basa sul
presupposto che GCP supporti pienamente lo
standard SAMLv2.0 e possa agire come fornitore di
servizi in una SSO avviata da SP.
Qvantel Questo servizio collega più fornitori di servizi con
diversi fornitori di identità. Come servizio di
intermediazione, il broker di identità è
responsabile di creare un rapporto di fiducia con
un fornitore di identità esterno al fine di utilizzare
le proprie identità per accedere ai servizi interni
esposti dai fornitori di servizi. L'approccio proposto
si basa sul CA Single Sign-On come fornitore di
identità che utilizza il protocollo OpenID Connect
1.0.

87