[Linuxtrent] Re: Single sign on con kerberos e LDAP
- From: azazel <azazel@xxxxxxxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Wed, 21 Jul 2010 03:12:06 +0200
>>>>> "Giuliano" == Giuliano Natali <diaolin@xxxxxxxxxxx> writes:
Giuliano> On Mar, Luglio 20, 2010, 12:44 pm, azazel wrote:
azazel> kerberos dall'applicazione web al (ad esempio)
azazel> database. Senza quel pezzo di infrastruttura il single
azazel> sign-on su applicazioni custom non si può fare. L'opzione
azazel> che è descritta nel documento e cioè quella di utilizzare
azazel> mod_auth_kerb e cgi è poco utile.
Giuliano> Hmmmm, interessante. E quindi????
Giuliano> era solo una considerazione sull'assenza o sai di più????
É una considerazione che volta a far emergere un problema che a prima
vista non si nota e che se non risolto, cosa che non sono riuscito
ancora a fare, di fatto il single sign-on in ambiente Linux si può fare
solo per applicazioni e servizi che non devono richiedere autorizzazioni
ad altri servizi. In questo gruppo di applicazioni rientrano ad esempio
tutti quei servizi che:
- non hanno bisogno di storage: pam (per lo più), ssh
- che hanno uno storage embedded: imap, smtp, ldap
- che si connettono ad uno storage esterno con un'unica autenticazione
decisa al momento della configurazione del servizio: imap (backend
sql), smtp (local delivery con backend sql), ldap (storage sql)
Questo insieme di applicazioni è certamente molto esteso e a questo
possono essere aggiunte tutte quelle applicazioni web, che devono
"girare" l'identità dell'utente ad un altro servizio, ma che possono
funzionare in modalità CGI. In questa modalità il browser negozia con il
mod_auth_kerb di apache l'identità dell'utente e arricchisce l'ambiente
di esecuzione dello script CGI con informazioni riguardanti il ticket
che lo script può utilizzare direttamente per connettersi ad esempio ad
un server Postgres configurato con autenticazione GSS o Kerberos (ormai
deprecata in PG) con le _autorizzazioni concesse all'utente che sta
facendo girare il browser_, questo è il nocciolo della questione.
Se si vuole ottenere la medesima cosa per un servizio web che deve fare
delle connessioni ad uno storage con le autorizzazioni concesse
all'utente che sta interagendo con l'applicazione e che necessita di
gestire questo pool di connessioni in tandem con la gestione del pool
sessioni utente (ad esempio attraverso l'utilizzo dei cookies) è tutto
un altro paio di maniche e non sono ancora riuscito a sbrogliare la
matassa, veramente molto intricata.
Per fare un esempio, gli scenari tipici di applicazioni con queste
necessità sono:
- webmail moderna + dovecot/cyrus/pippopluto imap configurato con
autenticazione GSS/Kerberos + postfix e sasl-gssapi
- amministrazione web + openldap + sasl-gssapi
- applicazione custom moderna in python/perl/..cough...java/php + database
postgres + autenticazione GSS
I problemi sono svariati e risiedono un po' in tutti i livelli della
catena di connessione, che nel caso di un applicazione web è
sostanzialmente:
browser == HTTPS con GSS/Negotiate ==> web server ==> web app con auth
GSS/Kerberos ==>
MIT/Heimdal Kerberos client lib e libgss ==> Storage/altro servizio con auth
GSS/Kerberos
Su applicazioni in ambiente Winzozz con AD+Kerberos+IIS+Storage (MSSQL
server?) questo pare funzionare da documentazione che si trova in giro e
che da quanto ho capito sfrutta una caratteristica del
dell'infrastruttura Kerberos M$ chiamata "ticket delegation", che
permetterebbe appunto ad un primo servizio di "inoltrare" il ticket
ricevuto dal client ad un secondo servizio. Questo nelle due
implementazioni Kerberos è nominato come flag "ok_as_delegate" sui
tickets, ma non si capisce ancora bene a che punto sia l'implementazione
e comunque è una caratteristica del ticket che si sovrappone alla
funzione svolta da un altro flag, il "forwardable" (utilizzato ad
esempio da sshd per ricreare l'ambiente Kerberos dell'utente quando
questo è già in possesso di un TGT e si logga su un'altra macchina con
autenticazione Kerberos/GSS) e di mezzo molto spesso c'è la libgss ma
anche per lei non capisco bene a che punto sia l'implementazione di
questa funzionalità, la doc eseistente sembrano essere rfc e
draft-rfc...
azazel
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: