Integrazione Kerberos, Active Directory e OpenAM

Per permettere il SSO sfruttando le credenziali Windows, OpenAM offre un modu- lo di autenticazione denominato WindowsDesktopSSO, il quale sfrutta le funzionalità Kerberos di Active Directory.

GSSAPI Anche se non fanno parte direttamente del protocollo Kerberos, descrivere le GSSAPI è propedeutico alla comprensione del resto del libro. Le Generic Security

Service Application Programming Interface (GSSAPI) sono un framework che fornisce servizi di sicurezza alle applicazioni. Lo scopo della nascita delle GSSAPI era creare un "abstraction layer" attraverso delle API standard per l’autenticazione, in modo che ogni programma potesse implementare l’autenticazione astraendosi dal sistema di autenticazione sottostante.

SPNEGO Come abbiamo accennato precedentemente, le GSSAPI forniscono un

set di API generiche che si astraggono dal meccanismo di autenticazione sottostante. Quando due applicazioni parlano tra loro attraverso le GSSAPI e sfruttano lo stesso meccanismo di autenticazione, si dice che hanno stabilito un contesto di sicurezza (se- curity context). Il problema di questo meccanismo è che le due entità devono sapere a priori quale meccanismo di autenticazione hanno a disposizione e quindi quale possono usare: GSSAPI non prevede un meccanismo di “handshake” tra i due peer per sapere quale meccanismo di sicurezza hanno in comune e stabilire quindi un security context. Il Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) è stato creato appositamente per determinare, durante una connessione tra due peer, quali sono i meccanismi di autenticazione disponibili e selezionare il miglior meccanismo comune. SPNEGO viene usato in Windows 2000 per negoziare quali sono i meccanismi di auten- ticazione supportati (tipicamente Kerberos e NTLM) e scegliere il migliore: ad esempio, se un sistema Windows 98 deve colloquiare con un server Windows 2003, SPNEGO sce- glierà il meccanismo NTLM perchè Windows 98 non supporta Kerberos. Al contrario, se un Windows XP colloquierà con un server Windows 2003 selezionerà Kerberos in quanto supportato da entrambi e reputato migliore di NTLM. Vediamo un po’ più da vicino il comportamento di SPNEGO. Chi avvia la connessione propone un meccanismo di autenticazione o una lista ordinata di sistemi di autenticazione; il destinatario sce- glie: può accettare il meccanismo di sicurezza proposto, può sceglierne uno dalla lista proposta oppure può rigettare i valori proposti. Successivamente il destinatario della trasmissione informa chi ha dato inizio alla connessione sulla sua scelta. Questo mecca- nismo potrebbe essere lento su connessioni non particolarmente veloci (tipicamente le WAN o le intefacce radio) per cui SPNEGO tenta subito di proporre un meccanismo di autenticazione al setup della connessione, in modo da minimizzare i tempi nel caso in cui il meccanismo proposto vada bene al destinatario della connessione. SPNEGO è alla base di tutti i meccanismi di autenticazione di Windows, inclusi la condivisione file e stampanti, LDAP, IPSec. Microsoft ha anche applicato SPNEGO alle connessioni Web (HTTP), estendendo il meccanismo dell’autenticazione. Sostanzialmente SPNEGO vie-

ne incapsulato nell’header di HTTP con la keyword WWW-Authenticate: Negotiate e un base64 encoding del risultato delle API. Tutti i successivi dialoghi tra il client e il server verranno veicolati attraverso questo meccanismo fino al completamento della sessione SPNEGO. Il meccanismo di SPNEGO su HTTP verrà utilizzato per realizzare il modello di Single Sign-On per quanto riguarda l’autenticazione Web.

Caso d’uso Supponiamo che un utente si sia già autenticato al dominio Windows controllato da Active Directory accedendo, quindi, al proprio desktop.

1. L’utente prova ad accedere ad una applicazione protetta da un Policy Agent. 2. La richiesta viene intercettata dal Policy Agent, il quale verifica se l’utente si è

già autenticato con OpenAM.

3. Assumendo che l’utente non si sia ancora autenticato con OpenAM, il Policy Agent indirizza l’utente verso il pannello di login di OpenAM, in particolare verso il modulo di autenticazione di WindowsDesktopSSO;

4. OpenAM, inizialmente, controlla se l’utente si è già autenticato controllando se è presente un SSOToken salvato come cookie. Nel caso in cui non fosse presente, invia un SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) verso il browser dell’utente. Il browser dovrà essere configurato in maniera opportuna per SPNEGO, altrimenti restituirà un errore con stato 401.

5. L’utente negozia un TGT (Ticket Granting Tiket) con il KDC (Key Distributor Center), che nl nostro caso è l’Active Directory.

6. Il TGT ottenuto dal browser dell’utente viene restituito ad OpenAM. 7. OpenAM decifra il TGT mediante una chiave configurata precedentemente. 8. OpenAM autentica l’utente con il KDC(AD) utilizzando il TGT decifrato. 9. Il KDC risponde con un messaggio di autenticazione avvenuta con successo e

restituisce il principal name.

10. OpenAM crea una sessione locale per l’utente autenticato.

11. OpenAM redirige l’utente verso l’applicazione protetta richiesta in origine. Questa volta la richiesta presenta un SSOToken incluso come cookie.

12. Il browser dell’utente richiede la risorsa protetta.

13. Il Policy Agent intercetta la richiesta e, trovando l’ SSOToken, lo valida con OpenAM e memorizza il risultato dell’autenticazione.

14. Il Policy Agent, se opportunamente configurata una politica di autorizzazione su OpenAM, controlla se l’utente possiede o meno le autorizzazioni necessarie per accedere alla risorsa richiesta. Il risultato della valutazione viene memorizzato.

15. Se il risultato della valutazione fatta dal Policy Agent garantisce l’accesso all’u- tente, la richiesta viene passata all’applicazione protetta, la quale restituirà la risorsa richiesta dall’utente.

Configurazione modulo di autenticazione WindowsDesktopSSO di OpenAM Il modulo di autenticazione WindowsDesktopSSO è un modulo precaricato su Ope- nAM mirato ad effettuare l’autenticazione per gli utenti utilizzatori di desktop Win- dows. Esso consente ad un utente che è già stato autenticato dal KDC di autenticarsi automaticamente ad OpenAM senza l’immissione di ulteriori credenziali.

Il DNS è uno dei componenti chiave di una infrastruttura basata su Active Directory. Spieghiamo adesso come configurare OpenAM come client Kerberos.

1. creare un utente OpenAM su Active Directory;

2. generare un keytab per l’utente creato. Supponiamo che l’utente che rappresenta il server OpenAM si chiami openam, e che il dominio Active Directory creato sia iamboo.example.com. Il keytab si genera da linea di comando (cmd) del Windows Server in questo modo:

ktpass -out openam.HTTP.keytab -pass 1********7 -mapuser openam -princ HTTP/[email protected]

-ptype KRB5_NT_PRINCIPAL -target IAMBOO.EXAMPLE.COM -kvno 0

3. Il keytab appena generato, va salvato sulla stessa macchina che ospita il server OpenAM.

4. Il passo successivo è quello di configurare il modulo WindowsDesktopSSO. En- triamo su OpenAM come amministratore, selezioniamo il nostro Realm e spostia- moci sulla sezione Authentication. Qui è possibile aggiungere alla nostra catena di autenticazione il modulo WindowsDesktopSSO, assegnandogli un nome. 5. Configuriamo il modulo:

(a) Service Principal: HTTP/[email protected]; (b) Keytab File Name: C:/tomcat/webapps/openam/

6. Kerberos Real: IAMBOO.EXAMPLE.COM;

(a) Kerberos Server Name: win-bf1u7ir0lvj.iamboo.example.com; (b) Return Principal with domani name: non spuntato;

(c) Authentication Level: 0;

(d) Search for the user in the realm: spuntato.

7. Salvare la configurazione e aggiungere il modulo alla catena di autenticazione. (a) sempre sulla stessa sezione, scorrere la pagina fino in fondo alla voce “Au-

thentication Chaining”;

(b) Cliccare sulla catena già esistente ed aggiungere il modulo appena creato; (c) Salvare

8. Logout del sistema.

Come esposto precedentemente, è necessario che il browser sia configurato in maniera opportuna per SPNEGO, altrimenti restituirà un errore con stato 401.

Una descrizione dettagliata su come impostare i browser è ottenibile al link http:// www.oracle.com/technetwork/articles/idm/weblogic-sso-kerberos-1619890.html.

2 Integrazione SugarCRM

SugarCRM è un software di CRM open source, un acronimo che in inglese è tradotto come: Customer Relationship Management, cioè Gestione delle Relazioni con i Clienti. Esso rappresenta una piattaforma che gira attorno al concetto della fidelizzazione del cliente, e si applica all’interno di un’azienda che è orientata non solo al cliente, ma anche all’ambiente circostante, con il quale l’azienda stabilisce le relazioni, ed è possibile organizzare, all’interno dell’azienda stessa, delle aree che sono in rapporto, in modo diretto o indiretto, con lo stato di soddisfazione del cliente.

SugarCRM si appoggia interamente a MySQL per il DataBase e l’archiviazione dei dati, utilizza Apache come web server e come linguaggio di programmazione all’interno viene usato il PHP.

• Community Edition; • Professional Edition: • Enterprise Edition.

La versione utilizzata nell’azienda Iamboo è la versione Community, liberamente scari- cabile dal sito ufficiale

http://www.sugarcrm.com/download-sugarcrm-community-edition-free-b.

2.1 Prerequisiti

2.1.1 Apache2

Affinchè sia possibile eseguire SugarCRM, è necessaria l’installazione del server HTTP Apache, ottenibile al link http://httpd.apache.org.

2.1.2 PHP5

SugarCRM è scritto in PHP, ottenibile al linkhttp://php.net/downloads.php.

2.2 SugarCRM

1. Una volta scaricato il file, scompattiamolo e ridenominiamolo in sugarcrm; 2. Copiamolo all’interno della cartella /opt;

3. Creiamo il file di configurazione /etc/apache2/sites-available/www.sugarcrm.it con il seguente contenuto:

# # www.sugarcrm.it # <VirtualHost *:80>

ServerAdmin [email protected] ServerName www.sugarcrm.it ServerAlias sugarcrm.it # Indexes + Directory Root.

DirectoryIndex index.html index.htm index.php DocumentRoot /opt/sugarcrm

Alias /simplesaml /opt/sugarcrm/htdocs/simplesamlphp/www </VirtualHost>

Agendo in questo modo, risulta possibile installare più siti web all’interno dello stesso server. Al momento, l’unico sito di nostro interesse riguarda l’applicazione web Sugar- CRM, ma nulla toglie che sul server si vogliano ospitare, in futuro, altre applicazioni o che altre applicazioni web siano già presenti.

Leggendo il file di configurazione si può notare che è stato creato un alias, mediante il quale sarà possibile raggiungere la pagina iniziale di SimpleSamlPhp.

1. Nel passo quattro si è definito il sito “disponibile”. Tuttavia questo deve essere ancora abilitato. Per far ciò, Debian include due comodi comandi a2ensite e a2dissite, i quali si preoccupano di abilitare i siti disponibili.

a2ensite www.sugarcrm.it

2. Eseguiamo il seguente comando per rendere effettiva la modifica:

/etc/init.d/apache2 reload

3. Digitando sul browser www.sugarcrm.it, verrà presentato il wizard di configura- zione di SugarCRM.

2.3 SimpleSamlPhp

SimpleSAMLphp è un’applicazione scritta in PHP che fornisce l’autenticazione e l’au- torizzazione delle infrastrutture incentrata sulla Security Assertion Markup Language (SAML). SimpleSAMLphp può essere utilizzato per implementare un Identity Provider (IdP), il fornitore delle identità degli utenti o un Service Provider (SP), il servizio che richiede particolari attributi all’ Idp per permettere o meno l’accesso ad uno specifico utente.

Nel caso specifico di SugarCRM, SimpleSAMLphp viene utilizzato come Service Provi- der. Non appena si prova ad accedere a SugarCRM (ad esempio, digitando www.iamboo- sugarcrm.it nella barra degli indirizzi del browser), la richiesta viene presa in carico da SimpleSAMLphp.

2.3.1 Installazione

1. Spostarsi su /opt/sugarcrm e creare una nuova cartella: la chiameremo htdocs. Spostiamoci al suo e digitiamo il seguente comando:

svn co http://simplesamlphp.googlecode.com/svn/trunk simplesamlphp

2. Al termine del download, spostiamoci all’interno della cartella simplsamlphp e digitiamo i seguenti comandi:

cp -r config-templates/*.php config cp -r metadata-templates/*.php metadata

3. Tenendo conto del file di configurazione creato al paragrafo 2.2, digitando sul browser www.sugarcrm.it/simplesaml, ci verrà presentata la pagina iniziale di SimpleSamlPhp.

4. Selezioniamo la tab Federazione;

6. Copiamo l’URL contenente i metadata di nostro interesse: ci servirà per la configurazione dell SP su OpenAM descitta al paragrafo 2.4.2.

2.4 Configurazione OpenAM

Affinchè vi sia una corretta integrazione con OpenAM, è necessario che sia instaurato un rapporto di fiducia tra SP (SimpleSAMLphp) e Idp (OpenAM), ovvero che entrambi facciano parte dello stesso Circle Of Trust (COT).