Mauro Dalfreddo

Finalmente trovo un po’ di tempo per continuare la trattazione iniziata in un mio articolo precedente dei Motivi per veicolare il contesto utente fino al database, e a questo rimando dando per scontati alcuni argomenti.

Sono già stati evidenziati i benefici e le caratteristiche dell’utilizzo dell’autenticazione integrata e del contesto utente anche fino all’ultimo livello applicativo (tier). E’ stata poi spiegata la configurazione da  utilizzare in un’archiettura a 3-tier (IE-IIS-SQL) tutta implementata in un unica macchina (single server).

Per capire come il security context di un utente possa essere veicolato esternamente ad un server da un servizio ad un altro,  bisogna comprendere i protocolli di autenticazione utilizzati.

NTLM e Kerberos a confronto

Il protocolli di autenticazione supportati da Windows sono NTLM (NT Lan Manager, fino dalla versione 4.0)  e Kerberos (da Win 2000 in poi).  Mentre NTLM si basa su un meccanismo di  challenge/response (ovvero lo scambio di un hash criptato tra client e server), Kerberos basa la sua architettura sull’esistenza di server autenticatori (KDC, Key distribuition center), che distribuiscono tikets (cifrati e firmati e quindi affidabili) ai client per utilizzare specifici servizi.

I pregi di Kerberos sono:

• lo standard aperto, basato sull’RFC 4120
• la maggiore velocità, poiché, diversamente da NTLM, il servizio non deve verificare la validità dell’utente/client presso un DC, ma gli basta semplicemente il ticket stesso
• la mutua autenticazione, poichè non solo il client si autentica al servizio (come NTLM),  ma il client stesso è certo dell’identità del servizio, poichè solo quello può leggere il ticket fornito
• supporto per il logon tramite smart card
• supporto per la delega dell’autenticazione (Authentication delegation o Authentication forwarding): grazie a questa caratteristica un servizio può accedere ad un risorsa remota per conto di un utente.

Quet’ultimo punto sta a significare che un utente A può dare diritti ad un’entità intermedia B per autenticarsi ad un terzo server C, come se
l’entità B fosse l’utente A stesso. Il server C baserà le sue decisioni autorizzative sull’identità di A invece che su quella di B.

E’ possibile iterare questo schema per più livelli applicativi distribuiti (multi-tier applications) solamente utilizzando Kerberos e non NTLM, semplicemente perchè NTLM non supporta la delegation! Quindi NTLM funziona su un’architettura a single server solo perchè il security context dell’utente viene creato alla sua connessione al primo livello sul server (dopo l’autenticazione) ed è disponibile poi per i livelli applicativi sucessivi.

Nell’implementazione Microsoft di Kerberos, il servizio stesso è altamente integrato con Active Directory (AD) e tutti i dati e le credenziali sono memorizzati in essa

(continua…)

Filed under : Active Directory, Kerberos, SQL Server, Web, Windows Autentication

0 Comment »

Recentemente ho avuto la necessità di forzare il cambio utente in un’applicazione asp.net che utilizza Windows Autentication come sistema di autenticazione.

L’idea è stata presa dai siti di Micorsoft Office Sharpoint 2007 (MOSS): di default l’accesso viene effettuato con l’utente corrente di dominio; al bisogno è presente un link nel menù per cambiare l’utente connesso; viene presentato quindi il popup standard per l’immissione delle credenziali, dopo la nuova autenticazione l’utente viene ripresentata la pagina corrente…

I requirement erano simili, ovvero l’utente Windows connesso all’applicazione asp.net su IIS non doveva essere necessariamente quello loggato sulla macchina con il CTRL+ALT+CANC. La problematica è connessa anche col fatto che i siti di una intranet sono tutti trusted di default, per cui Explorer effettua tramite la Windows Authentication un’autenticazione implicita (single sign-on). 

I vantaggi del cambiamento di profilo sono palesi: l’utente non deve scollegarsi e riconnettersi a Windows, chiudendo tutte le applicazioni, oppure eseguire Internet Explorer con l’opzione “Run as”; deve solo cliccare un link…

Il trucco sta nello spedire al browser uno status code 401 “Access denied”, per cui il browser richiede all’utente ulteriori credenziali e richiama la pagina nuovamente.

Nella pagina desiderata, o nella master page, inserire il link alla pagina del cambio utente:

<a href="AccessDenied.aspx?loginasanotheruser=true">Cambio profilo</a>

In AccessDenied.aspx  
 

<%@ Page Language="C#" autoeventwireup="true"%>

<%

if (Session.IsNewSession)  Response.Redirect("default.aspx", true);

Session.Abandon();

Response.StatusCode = 401;

Response.StatusDescription = "Access Denied";

%>

Questa pagina controlla se la sessione è appena stata creata, e nel qual caso reinvia l’utente, che si è appena autenticato ad IIS, alla home page. Viceversa viene reimpostato lo status cose a 401. Il client richiede nuovamente le credenziali e la pagina aspx viene eseguita nuovamente solo se queste sono valide (è IIS infatti che effettua questa verifica).

Al posto di redirezionare il client alla home page è possibile ritornare sulla pagina appena precedente; basta passare a AccessDenied.aspx un parametro con il valore di window.location; ma questa è un’altra storia…

Filed under : Active Directory, Software, Web, Windows Autentication

0 Comment »