Autenticazione LDAP e sessioni

Question

Autenticazione LDAP e sessioni

#1 da (2 voti)
#2 da (2 voti)

3

Data un'applicazione Web con accesso basato su modulo e una directory centrale: l'utilizzo del binding LDAP (veloce) in un'applicazione con l'utente effettivo presenta numerosi vantaggi (rispetto all'utilizzo di un utente del servizio e al controllo della password). Significa soprattutto che il server di directory valuterà se l'accesso è effettivamente consentito. Può quindi controllare gli accessi e contare i tentativi falliti e l'applicazione non ha bisogno di sapere come confrontare gli hash delle password o verificare la presenza di blocchi di account / scadenze / limiti di tempo.

Tuttavia, c'è una domanda su cosa fare se una sessione di accesso (ad esempio alimentata da un cookie di sessione http) persiste per un periodo più lungo e l'utente è stato nel frattempo eliminato o escluso.

L'approccio più semplice sarebbe quello di legare di nuovo regolarmente. Questo ha tuttavia il problema che o infastidisce l'utente (dato che deve dare di nuovo la password) o significa che devo mantenere la password nella sessione degli utenti, quindi posso autenticarmi di nuovo. Esiste un altro metodo (ampiamente supportato)?

In caso contrario, che cosa si farebbe? Utilizzando un servizio bind per cercare il DN e verificare se è stato modificato (eventuali attributi modificati)? Immagino che questo non coprirà il tipo di restrizioni "valido fino a".

C'è (se GSSAPI non è usato) un modo per avere una sessione che rappresenta un token che può essere validato contro il server LDAP (e se sì, posso accedervi da un client LDAP in Java?)

Il mio prodotto software supporta tutti i tipi di altri metodi alternativi come SSO con SAML o SiteMinder, Kerberos e così via. Ma il metodo LDAP è lì per alcuni clienti e voglio ottimizzare specificamente quella parte.

authentication active-directory ldap session-management

posta eckes 04.02.2015 - 08:31

fonte

2 risposte

Leggi altre domande sui tag authentication active-directory ldap session-management

Se creo un server Web domestico, i computer che utilizzano il mio Wi-Fi saranno vulnerabili? Qual è la cosa peggiore che qualcuno possa fare con il mio codice di sblocco del telefono?

score 2 · Answer 1

Da ciò che potrebbe percepire, il tuo problema non è specifico di Active Directory. Avresti ancora questo problema se fosse basato su SQL o qualsiasi altro tipo di back-end di autenticazione. Quello che dobbiamo risolvere è: come manteniamo la consapevolezza dello stato dell'account utente connesso senza ricordare le credenziali dell'account o chiedendo di autenticare nuovamente la sicurezza E non abbandonare la sicurezza?

La risposta è semplice: Non possiamo. L'unico modo per assicurarsi che l'utente sia ancora valido è ricontrollare al servizio auth.

La tua unica opzione dovrebbe essere timeout più lunghi (penso che non abbiamo bisogno di entrare nel merito del perché non dovremmo mantenere le credenziali dell'utente, vero?), ma questo è esattamente il motivo per cui stai affrontando questa coerenza di stato problema.

Questo è il motivo per cui abbiamo una categoria di vulnerabilità appropriata per quel tipo di problema . Devi semplicemente NON abilitare lunghi periodi di timeout di sessione o (secondo alcune persone) sessioni di lunga durata.

Puoi provare qualcosa su quel SSO menzionato da @Abu. Ma questo si apre a un altro problema sul modo in cui Windows autentica perché NTLM è danneggiato e quindi la configurazione Kerberos predefinita, come spiegato nel link precedente. Naturalmente, è possibile configurare Kerberos correttamente in modo che non utilizzi la crittografia interessata, ma anche che sia necessario un piano di gestione dell'infrastruttura stretto (e non sono nemmeno sicuro che annullerebbe la sessione al momento l'account viene eliminato, bloccato, ecc.).

La sicurezza viene sempre a scapito dell'usabilità. Parla con il tuo manager, spiegagli la situazione e fai tutto ciò che sceglie. In un modo o nell'altro, sarà a conoscenza dei pro e dei contro della sua decisione, che si tratti di minore sicurezza (alcuni server compromessi o cancellati?) O di alcune e-mail che si lamentano della riautenticazione (a seconda del timeout scelto).

Da dove guardo la questione, l'impatto della minore sicurezza in questo caso supera di gran lunga l'impatto della seconda opzione.

Ma solo tu puoi dire dove fa più male.

score 2 · Answer 2

L'uso di un solo BIND non è garantito per limitare l'accesso agli utenti desiderati. Ad esempio, dovrai anche controllare se l'utente è bloccato, ad es. l'attributo userAccountControl.

Se si è veramente preoccupati di memorizzare le credenziali in memoria e si desidera una rapida sospensione dei diritti degli utenti tramite LDAP, è possibile mantenere la sessione aperta con query periodiche degli attributi appropriati. Questo ha altri problemi, ma risolverà questa preoccupazione.

Tuttavia, ritengo che si stia stimando eccessivamente la necessità di allontanare rapidamente un utente da un'applicazione quando le informazioni sulla directory dell'utente cambiano. Se devi davvero liberare rapidamente l'utente, dovresti disporre di un meccanismo nell'applicazione per invalidare la sessione dell'utente.

Credo anche che tu sia eccessivamente preoccupato di archiviare le credenziali dell'utente in memoria. Questo è un obiettivo relativamente difficile, e se le credenziali dell'utente sono così sensibili, allora non dovresti usare nulla che possa essere immagazzinato in memoria, ma piuttosto usare qualcosa come l'autenticazione a più fattori in cui uno dei fattori di presenza è limitato nel tempo o sicuro crittograficamente, ad es SecurID o PC / SC.