ARCHITETTURA DI NOVELL SECURELOGIN

Architettura di Novell SecureLogin
( estratto documentazione offerta tecnica )
La soluzione proposta è quella di Novell, basata su Novell SecureLogin 7.0 SP1.
Novell SecureLogin fornisce strumenti di autenticazione e automatismi di single sign-on verso
differenti reti ed applicazioni all’interno di una Organizzazione. Una delle prerogative principali
del prodotto è quella di poter essere utilizzato come unico punto di ingresso alla rete aziendale
ed alle sue risorse.Ogni qualvolta l’utente (Workstation) cerchi di accedere ad una applicazione
(applicazioni Win32, Web, o Java, applicazioni pubblicate via Citrix Terminal Server, sessioni di
emulatore terminale, etc.), il SecureLogin Client intercetta l’evento, effettua il recupero delle
credenziali utente ed esegue l’autenticazione sul sistema target per conto dell’utente.
SecureLogin memorizza le credenziali degli utenti in maniera criptata all’interno di un directory
server (aderente allo standard LDAP v3) ed effettua il caching in un formato criptato all’interno
della Workstation dell’utilizzatore finale (per ottimizzare il tempo di sign-on o 6 di 43 garantire il
funzionamento a utenti laptop). L’unico utente abilitato a sbloccare i dati criptati contenuti
nella cache della Workstation rimane sempre e comunque l’utente stesso. L'amministratore
non ha in alcun modo accesso alla copia delle credenziali dell'utente.
L'architettura di NSL è su 2 livelli: agent sulle postazioni e back-end rappresentato
dall'infrastruttura di directory o LDAP. Non sono presenti middleware o repository aggiuntivi.
Anche la console di amministrazione dialoga direttamente col back-end senza intermediari.
Novell Secure Login: l’architettura
I dati memorizzati da SecureLogin sono il record delle credenziali di autenticazione utente e le
istruzioni riguardanti la modalità di utilizzo di tali credenziali, ovvero gli script di login sulle
applicazioni o sugli emulatori su cui effettuare single sign-on. Per la memorizzazione delle
credenziali, SecureLogin può avvalersi di svariate alternative:
•
•
•
•
un qualsiasi directory compatibile con le specifiche LDAP v3;
Microsoft Active Directory anche sia in Application Mode (ADAM);
Novell eDirectory;
Novell eDirectory + Secret Store Server.
L'uso di ActiveDirectory come back-end è tipicamente associato alla connessione fra client
NSL e ActiveDirectory via normale client Windows (in alternativa è possibile usare AD come
LDAP server "puro"). Ciò apporta almeno due benefici:
•
•
non dovere introdurre un’ulteriore infrastruttura di back-end,
ereditare la robustezza e affidabilità server-side dell'infrastruttura AD esistente.
NSL può usare ADAM in congiunzione ad Active Directory (AD per autenticazione di rete,
ADAM per memorizzare dati, policy e configurazioni) qualora il cliente non voglia estendere lo
schema di Active Directory. La connessione fra NSL e ADAM è necessariamente in LDAPS (in
generale, qualora si desideri usare un LDAP server come back-end, la connessione è
obbligatoriamente in LDAPS per NSL). Il vantaggio di usare ADAM per NSL, è quello di non
dovere estendere lo schema di AD con gli attributi di NSL. SLManager è lo strumento di NSL
deputato all'amministrazione quando il back-end è di tipo LDAP server. L'infrastruttura ADAM
in alta disponibilità è potenzialmente distribuita tanto quanto quella AD per meglio servire le
postazioni distribuite geograficamente. Nel caso si usi come repository Novell eDirectory ci si
può avvalere del Secret Store, una estensione funzionale di eDirectory che permette un livello
di riservatezza superiore a quello disponibile in caso si usi SecureLogin avvalendosi di altre
piattaforme LDAP. Il Secret Store infatti prevede per ciascun utente la conoscenza sia di una
Password (soggetta a variazione periodica ed eventualmente passibile di ovveride da Help
desk o amministratori) sia di una Passphrase (non soggetta a variazione, classicamente
definita come risposta ad una challenge question, ad es: nome della maestra elementare).
Il modello a doppia chiave permette di gestire in maniera sicura il password ovveride di cui
all’esempio di caso d’uso seguente: se un utente dimentica la propria password e l'help desk
la sovrascrive, prima di poter usare nuovamente NSL verrà chiesto all'utente di ridigitare la
Passphrase. In altre parole, le credenziali segrete mantenute nel secret store sono soggette a
lock in seguito al password ovveride (ma non in seguito a password change effettuato da parte
dell'utente stesso) e sono sbloccate solo in seguito all'inserimento della Passphrase. Questo
modello esclude la possibilità per operatori di Help Desk o amministratori di impersonare utenti
terzi previo password ovveride. In caso la Passphrase venga dimenticata l'help desk può solo
resettare totalmente l'utente, cancellando integralmente tutti o segreti. Le credenziali sono
memorizzate cifrate sia lato server (directory) e sia sulla cache locale all'agent sulla
postazione utente. La cifratura è tale che nemmeno un amministratore può leggerle (ma solo
eventualmente resettare una password come operazione di help desk). La cifratura può
essere di tipo 3-DES o AES. La comunicazione fra client NSL e server (AD, eDir, LDAP)
avviene sempre in modalità riservata e cifrata (protocolli nativi per AD/eDir, LDAPS per server
LDAP). Dal punto di vista funzionale, NSL supporta autenticazioni con username/password e
autenticazioni forti (integrazione con smart card ad es.) e combinazioni di più fattori di
autenticazione. La totalità delle configurazioni specifiche per il funzionamento dell'agent sulla
workstation vengono caricate a tempo di esecuzione dall'agent prelevandole dal directory
server. Non sono quindi memorizzate sulla workstation stessa.
Sono infatti memorizzate centralmente sul directory:
•
•
•
tutte le policy di funzionamento dell'agent,
tutti gli script di automazione del logon sulle applicazioni, questo implica che, quando
viene aggiunto o modificato lo script di integrazione di una applicazione, non sono
necessarie ridistribuzioni di software sugli agent,
tutte le credenziali di ciascun utente per ciascuna applicazione.
In altre parole, la configurazione in fase di installazione dell'agent richiede solo dei parametri
di base del tipo:
•
•
•
quale tipo di directory server viene utilizzato (AD, eDirectory, Altro LDAP),
qual è l'indirizzo dei directory servers,
in quale modalità il prodotto deve funzionare (con o senza SecretStore, con o senza
Novell Client).
Strumenti di amministrazione
Gli strumenti di amministrazione (iManager per Novell eDirectory, SLManager per LDAP server
e ADAM, snap-in ad hoc per la MMC per Microsoft ActiveDirectory) dialogano col back-end e
non ne influenzano la scalabilità (si può agire su un qualsiasi directory server, le configurazioni
vengono automaticamente replicate su tutti). L'amministrazione server-side di NSL in ambiente
AD è effettuata con snap-in ad hoc per la Microsoft Management Console forniti col prodotto e
installabili su una qualsiasi workstation assieme al "Remote Server Administration Tools for
Windows 7 " o equivalente per WinXP/AD2003. Non è quindi necessario avere diritti di
amministratore di dominio e accedere a un domain controller per amministrare NSL.
Le best practice consolidate in diversi anni di progetti hanno portato a definire 2 ruoli per
l'amministratore di NSL ("SecureLogin Administrator" e "SecureLogin Help Desk"). Questo tipo
di approccio permette di delegare l'amministrazione ordinaria della soluzione a un gruppo di
operatori autonomi senza interferire con la gestione generale dell'infrastruttura AD e senza
possibilità di effetti collaterali (l'insieme di attributi NSL che estendono lo schema sono
indipendenti da tutto il resto).
Application Definition
Le application definition sono gli scripts che contengono la definizione del comportamento
dell'agent di NSL rispetto alle maschere di autenticazione su applicazioni Win32/.NET, web
(anche con Applet Java), Java (supporto specifico anche per Oracle Forms) ed emulatori di
terminali. La creazione di tali scripts avviene mediante l'uso di una procedura guidata (wizard)
che permette di costruire passo-passo lo script in maniera grafica e intuitiva. Lo script può
essere poi affinato successivamente. Il linguaggio di scripting di SecureLogin permette inoltre
di implementare procedure di login sofisticate: ad esempio sopporta la gestione di differenti
script di login per versioni diverse della stessa applicazione.
NSL permette di associare un set di credenziali a N applicazioni e ogni utente può avere M set
di credenziali. Ad ogni applicazione può quindi essere associato un differente set di credenziali.
In generale, la relazione fra l'insieme delle applicazioni e quello delle credenziali è di tipo N:M.
Il prodotto inoltre fornisce un set di script preconfigurati per le seguenti applicazioni:
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
ActiveSync*
Cisco* VPN
Citrix Program Neighborhood
Citrix Program Neighborhood - Farm Login Failure
Citrix Program Neighborhood - Server
Citrix Program Neighborhood - Agent
Citrix Program Neighborhood - Agent v10.x
GroupWise Windows Application v5.5, v6.0, v7.0, and v8.0
3.1.9 Lotus* Notes* R8
3.1.10 MEDITECH* x and 4.x
3.1.11 Microsoft Internet Explorer 6, 7, and 8
3.1.12 Microsoft Networking Client
3.1.13 Microsoft Outlook*
3.1.14 Microsoft Outlook Express
3.1.15 Microsoft SQL
3.1.16 Microsoft Windows Live ID
3.1.17 MSN Messenger 4.5 and 4.7
3.1.18 Novell Groupwise Messenger 2.0
3.1.19 Novell Groupwise Notify Client
3.1.20 Novell Groupwise 7.0 Web Login
3.1.21 Novell iManager Web Login
3.1.22 Quick Finder
3.1.23 SAP - SAPlogon.exe
3.1.24 SAP R/3 Login
3.1.25 Trillian*
3.1.26 VNC 3.0 and 4.0
3.1.27 Windows Live Messenger 5.0, 6.0, 7.5, 8.1, and 2009
3.1.28 Windows Remote Desktop 6
3.1.29 Yahoo! Messenger 8.1
3.1.30 Yahoo! Messenger 8.1 Alternate
3.1.31 AbsoluteTelnet
3.1.32 Attachmate* Extra
3.1.33 Attachmate Extra 2000
3.1.34 Attachmate KEA!
3.1.35 Attachmate Personal Client
3.1.36 Chameleon HostLink*
3.1.37 CRT
3.1.38 Eicon Aviva*
3.1.39 GLink
3.1.40 HBO* Star Navigator
3.1.41 IBM* Personal Communications
3.1.42 IDXTerm Healthcare
3.1.43 Info Connect
3.1.44 Microsoft Telnet 2000
3.1.45 Microsoft Telnet NT
3.1.46 Microsoft Telnet Win 9x
3.1.47 Mocha W32 Telnet
3.1.48 NetTerm 4.2
3.1.49 NS/Elite*
3.1.50 Passport TN 3270E
3.1.51 PowerTerm*
3.1.52
3.1.53
3.1.54
3.1.55
QVT
QWS3270 Plus
SDI TN3270
TeraTermPro
3.1.56 TinyTERM
3.1.57 ViewNow*
3.1.58 Wall Data Rumba*
3.1.59 Wall Data Rumba 2000
3.1.60 Wall Data Rumba Web To Host
3.1.61 WinComm
3.1.62 Window Telnet VT
3.1.63 WRQ Reflection*
3.1.64 Citrix Web Portal
3.1.65 CNN Member Services
3.1.66 eBay
3.1.67 Fidelity.com Web Login
3.1.68 Hotmail
3.1.69 Onebox.com
3.1.70 Qantas Frequent Flyer
3.1.71 Yahoo! Mail
3.1.72 Monster.com
Random Password Generation Client e Server side
NSL permette di implementare modelli di generazione random della password gestiti client
side: l'agente sulla workstation effettua la sostituzione della password su una data
applicazione con una password casuale non nota all'utente. La nativa integrazione tra le
componenti della suite IAM Novell permette anche l'implementazione di un modello server side
di Random password management usando esclusivamente componenti di prodotto e senza
sviluppi custom. Tutti i driver di Novell Identity Manager …..comprendono la possibilità di
generare password random e di scrivere le credenziali nel repository di NSL (sia esso il
SecretStore o meno). E' quindi possibile evitare all'utente la necessità di sapere anche la
password iniziale di accesso ad una applicazione in quanto Novell Identity Management può
“dirla” a Novell Secure Login in fase di provisioning dell'utenza. Ciascuna operazione di
provisioning quindi provvederà sia alla definizione della password (random) per l'applicazione
specifica (es SAP, Notes, ecc.) sia all'aggiunta della stessa password alla lista delle credenziali
di accesso per NSL. Rispetto al modello Client side, la disponibilità aggiuntiva del modello
Server side permette di gestire il refresh delle password random anche in modalità batch a
frequenza configurabile senza che l'utente ne venga informato o che debba necessariamente
accedere all'applicazione.
Uso di Smart Card in Secure Login
Per sua natura SecureLogin utilizza un approccio di tipo “store-and-forward” nella gestione
delle credenziali di SSO memorizzando gli ID utente e le password nello storage server side.
Ne consegue l'estrema importanza della sicurezza del repository delle credenziali di
SecureLogin.L'uso congiunto di smart card e SecureLogin rende disponibili funzionalità utili ad
aumentare la sicurezza delle credenziali. Ad esempio:
•
•
•
Uso della smart card per criptare le credenziali di SecureLogin,
Salvataggio anche sulla smart card delle credenziali di SSO delle applicazioni,
richiedere il log on a mezzo smart card per lanciare ed amministrare il SSO.
SecureLogin usa un processo di encryption a due livelli per mettere in sicurezza utenti,
credenziali e dati sensibili. Tutte le password utente sono criptate mediante una “chiave
utente”, mentre tutti i dati relativi all’utente, inclusi i campi password, sono criptati usando
una “chiave master”. Il risultato è una encryption a due livelli, dove i valori di password sono
criptati due volte: una volta con la chiave utente e una volta con la chiave master, mentre tutti
gli altri dati sono criptati una volta sola con la chiave master.L’utilizzo di SecureLogin
unitamente ad una smart card fornisce un livello aggiuntivo di sicurezza perché la chiave usata
per decodificare i dati è salvata sulla smart card, e l’autenticazione avviene mediante un
duplice fattore: la smart card (possesso) e il PIN (conoscenza di informazione). Se si seleziona
l’opzione “uso della smart card per criptare i dati di SSO”, perché SecureLogin venga caricato
gli utenti devono prima inserire la smart card e fornire il PIN personale.
Integrazione con sistemi di Identity management
In questo paragrafo descriviamo come NSL si potrà integrare con un altro prodotto Novell:
Identity Manager (IDM). Il modulo di “Credentials Provisioning” di Novell Identity Manager
(IDM) consente di effettuare il provisioning delle credenziali usate per connettersi a una
applicazione con Novell SecureLogin (NSL) all'attivazione dell'account specifico, a un cambio
password o a un qualsiasi altro evento in ambito identity management. Si osservi che non è
necessario che il repository utenti dell'applicazione acceduta via NSL sia integrato nella
soluzione di Identity Management.
I vantaggi derivanti dal provisioning automatizzato delle credenziali (e successive modifiche)
ha un duplice beneficio: - semplificazione delle procedure di delivery e manutenzione della
soluzione di Enterprise Signle Sign On (ESSO) - rafforzamento della sicurezza complessiva.
Se un sistema è connesso via IDM e acceduto via NSL, è infatti possibile effettuare
provisioning di password generate casualmente e sconosciute agli utenti. In questo modo, gli
utenti possono accedere a queste applicazioni solo attraverso NSL. Qualora si decida di
richiedere un’autenticazione forte per l'accesso a NSL, il beneficio è ereditato da tutte le
applicazioni. È possibile inoltre cambiare le password in automatico per quelle applicazioni che
non prevedono la funzionalità di cambio password nativamente. Anche la passphrase di NSL
(meccanismo di ulteriore sicurezza per sbloccare NSL sul client) può essere gestita dal modulo
di Credentials Provisioning. Qualora IDM non sia parte della soluzione, è l'utente o
l’amministratore di sistema a inserire le proprie credenziali per ogni applicazione al primo uso,
in modo che NSL le registri.
Architettura della soluzione
Al fine di avere un minor impatto possibile con l'attuale configurazione di rete presente in
ospedale, il backend verrà installato in macchine separate contenenti due istanze di Active
Directory in Application Mode (ADAM) in replica multimaster. In questo modo non sarà
necessario aggiungere schemi all'Active Directory di produzione, in quanto tutti i dati relativi a
Novell Secure Login saranno memorizzati nelle istanze ADAM. Gli utenti saranno quindi
autenticati dall'Active Directory attualmente utilizzato, e NSL accederà alle istanze ADAM per
reperire informazioni riguardo a configurazioni, template, policy ed account degli utenti.
Occorre notare che, anche se ADAM non conterrà informazioni sulle credenziali AD dell'utente,
NSL manterrà in memoria la password AD dell'utente, in modo da poter automatizzare
l'accesso ad applicativi che effettuano l'autenticazione su Active Directory.
Active Directory ed Adam verranno sincronizzati tramite il tool ADAM Synchronizer, tramite cui,
quando un utente viene creato su AD, viene aggiunto automaticamente anche su ADAM.
La cancellazione di un utente e le modifiche di Organizzation Unit invece non sono
sincronizzate automaticamente, ma mediante task che verranno schedulati o potranno essere
eseguiti manualmente. La gestione di utenze viene effettuata tramite Novell SLManager, che
estende i tool di amministrazione di ADAM in modo da supportare la gestione delle funzionalità
di Novell SecureLogin.