Come funziona SSO con Active Directory per cui gli utenti sono connessi in modo trasparente a un'app Web Intranet?

Mi è stato detto che è possibile creare un'applicazione Web che non richiede un accesso. L'utente accede a Windows, che esegue l'autenticazione tramite una ricerca di Active Directory (LDAP). Quindi, dovrebbero essere in grado di accedere alla mia webapp e non visualizzare mai un prompt di accesso. Questi clienti si sono riferiti a questo come Single Sign On (forse in modo errato e parte della mia confusione).

Ma, da quello che ho letto Single Sign On dai documenti Tomcat è:

La valvola Single Sign On viene utilizzata quando si desidera dare agli utenti la possibilità di accedere a una qualsiasi delle applicazioni Web associate al proprio host virtuale e quindi riconoscere la propria identità da tutte le altre applicazioni Web sullo stesso host virtuale.

Questo è perfettamente chiaro per me. L'utente deve effettuare il login una volta e può accedere a tutte le webapp su un'istanza di tomcat. Ma quello che devo fare è in qualche modo lasciarli accedere senza mai fornire credenziali al mio server Tomcat.

Quindi, affinché questo funzioni, immagino:

• L'utente effettua una richiesta per alcune pagine
• Il server non vede alcun token di sessione e quindi richiede al client alcune credenziali.
• Il browser client senza alcun intervento da parte dell'utente fornisce alcune credenziali al server.
• Quindi, utilizzando quelle credenziali fornite dal browser dei client, effettua una ricerca in un LDAP.

Ho visto alcuni esempi che utilizzano i certificati lato client ... in particolare il sistema DoD PKI che ha un senso per me perché in quei casi configuri Tomcat per richiedere certificati lato client , ma semplicemente accedendo a Windows non vedo come questo funzionerebbe e quali informazioni il browser passerebbe al server ecc. È per questo che NTLM è usato?

Prima di tutto - e nel caso in cui altri utenti visitino questa pagina - ci sono solo alcuni metodi di autenticazione che ti consentono di eseguire SSO prontamente. Questi sono NTLM e Kerberos . LDAP - d'altra parte - non ti darà mai SSO prontamente.

NTLM è in realtà NTLMv1 e NTLMv2. Questi sono molto diversi e NTLMv1 è obsoleto a causa di gravi problemi di sicurezza. Dovresti evitare le soluzioni di autenticazione Java che non riescono a identificare correttamente se supportano NTLMv1 o NTLMv2 perché usano solo la parola "NTLM" nella loro documentazione. È probabile che lo sviluppatore di detta soluzione di sicurezza non conosca se stesso, motivo in più per cercare la scala antincendio.

Contrariamente alla credenza tradizionale, sia NTLMv1 che NTLMv2 sono completamente documentati da Microsoft, ma troverete comunque soluzioni che affermano di aver "retroingegnerizzato" il protocollo. È vero che questo era necessario prima che Microsoft documentasse i protocolli che credo intorno al 2006 o al 2007. Comunque NTLMv1 è un no-no. Non c'è nulla di sbagliato in NTLMv2 di per sé, ma Microsoft ha gradualmente eliminato NTLM (in qualsiasi forma) in tutti i suoi prodotti a favore dell'autenticazione Kerberos. NTLMv1 è morto da molto tempo e NTLMv2 è ora utilizzato da Microsoft solo nei casi in cui non è disponibile alcun controller di dominio. In conclusione: NTLM (in qualsiasi forma) non è proprio la strada da percorrere. Dovremmo effettivamente salutare Microsoft per aver adottato un approccio basato sugli standard qui.

Questo ti lascia con Kerberos. Microsoft ha creato un protocollo per la negoziazione e il trasporto di informazioni di autenticazione su HTTP. Questo è noto nei prodotti Microsoft come " Autenticazione integrata di Windows " ma è stato definito come uno standard ufficiale con il nome di SPNEGO . Questo è ciò che dovresti cercare. SPNEGO supporta sia NTLMv2 che Kerberos come meccanismo di autenticazione sottostante, ma per i motivi sopra indicati dovresti scegliere come target Kerberos anziché NTLMv2.

Ho integrato con successo diverse applicazioni Tomcat (in esecuzione su Linux / Solaris) con Active Directory utilizzando il Progetto SPNEGO su SourceForge . Ho trovato che questo è l'approccio più semplice. Questo ti dà SSO prontamente simile a quello che fa ad esempio un server Sharepoint. Questo è probabilmente ciò che i tuoi utenti si aspetteranno quando parleranno di "SSO". Ottenere la configurazione Kerberos corretta, generare chiavi e impostare account "fittizi" in Active Directory può essere una seccatura, ma una volta capito bene funziona come un incantesimo.

L'unica cosa che non mi piace del progetto SPNEGO su SourceForge è che non capisco quanto spesso esegue l'autenticazione. Il mio brutto sospetto è che lo faccia per ogni visualizzazione di pagina piuttosto che una volta per ogni sessione. Forse mi sbaglio in questo. Comunque: questo evidenzia un'altra cosa da considerare nelle soluzioni SSO: non si desidera implementare una soluzione che "spam" il proprio provider di identità (diciamo Active Directory) con richieste non necessarie.

In un ambiente Windows Active Directory, Single Sign On viene utilizzato per indicare che visitare una pagina Web interna comporta le autorizzazioni di accesso a Windows e il server Web può agire su di esse. È qualcosa per cui NTLM è usato, ma le implementazioni più recenti usano invece Kerberos.

Se apri un sito Web Sharepoint Server, sa chi sei senza bisogno di un nome utente e una password di accesso, ma questo funziona solo per i siti Web interni sulla stessa rete, non credo abbia molto senso che funzioni su un sito Web pubblico. (Non capisco se intendi "host virtuale" come in un vhost Apache o come in un server ospitato in outsourcing).

Ecco un documento Microsoft che descrive come funziona l'autenticazione Kerberos su un server Web che esegue IIS / ASP.Net: http://msdn.microsoft.com/en-us/library/ff647076.aspx

Sembra possibile fare con Apache / Tomcat / Java. Ecco un PDF che descrive un'implementazione dell'Università del Regno Unito di questo: http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf e un progetto Codeplex per questo: http://tomcatspnego.codeplex.com/ e Openfire ne hanno alcuni documentazione relativa al lavoro generalmente con Java / Kerberos qui ( http://community.igniterealtime.org/docs/DOC-1060 ).

Sembra che tu stia descrivendo ciò che Microsoft chiama Autenticazione integrata di Windows.

Sembra che Tomcat supporti l'autenticazione di Windows, in base a questo articolo .

Per cominciare, non puoi evitare il login. Se vuoi identificare gli utenti, devi averli registrati. Dimentica NTLM, Kerberos viene in soccorso: può fare tutto in modo completamente trasparente.

SingleSignOnValve non è quello che stai cercando. Se usi Tomcat 7, puoi usare SpnegoAuthenticator immediatamente ma su 6 devi usare questo .