Autenticazione Active Directory per il prodotto SaaS

Question

Dopo alcuni aiuti teorici sull'approccio migliore per consentire a un prodotto SaaS di autenticare gli utenti contro il server Active Directory interno (o altro LDAP) di un tenant.

L'applicazione è ospitata, ma esiste un requisito che i titolari possono delegare l'autenticazione al loro provider di gestione utenti esistente come AD o OpenLDAP ecc. Strumenti come lo scambio di hosting di Microsoft Online supportano la sincronizzazione aziendale di AD.

Supponendo che il client non desideri inoltrare la porta 389 al proprio controller di dominio, qual è l'approccio migliore per questo?

Answer 1

Dopo aver fatto qualche ricerca e parlando con alcuni amministratori di sistema che avrebbero gestito questo, abbiamo optato per due opzioni, che dovrebbero soddisfare la maggior parte delle persone. Li descriverò qui per coloro che erano anche interessati al risultato.

servizio di autenticazione installato nella del ORGANIZZATIVI DMZ

Se gli utenti desiderano utilizzare l'autenticazione con un server locale di Active Directory che saranno tenuti a installare un agente nella loro DMZ e la porta aperta 443 ad esso. Il nostro servizio sarà configurato per accedere a questo servizio per eseguire l'autenticazione.

Questo servizio si trova nella DMZ e riceve richieste di autenticazione dall'applicazione SaaS. Il servizio tenterà di collegarsi alla directory attiva con queste credenziali e restituire uno stato per indicare il successo o l'insuccesso.

In questo caso l'autenticazione basata su moduli dell'applicazione non cambierà e l'utente non sarà a conoscenza dell'autenticazione dietro le quinte.

OpenID

Simile al primo approccio, un servizio verrà installato nella DMZ del cliente, e sarà aperto la porta 443. Questo sarà un fornitore OpenId.

L'applicazione SaaS sarà un consumer OpenId (è già per Facebook, Twitter, Google etc login).

Quando un utente desidera accedere, verrà presentato il provider OpenId, chiedendo loro di inserire il nome utente e la password. Questa schermata di accesso verrebbe pubblicata dalla DMZ del client. L'utente non inserirà mai il nome utente o la password nell'applicazione SaaS.

In questa istanza, l'autenticazione basata su form esistente viene sostituita dall'autenticazione OpenId dal servizio nel DNZ del client.

Una terza opzione che stiamo analizzando è Active Directory Federated Services, ma questa è proprietaria di Active Directory. Le altre due soluzioni supportano qualsiasi autenticazione basata su LDAP su Internet.

Answer 2

Che dire di una connessione LDAPS alla directory dell'utente del cliente? Possono disattivare questo firewall in modo che solo i tuoi server abbiano accesso se sono preoccupati che siano pubblici. Dal momento che è SSL, è sicuro dall'inizio alla fine. Tutto ciò di cui hai bisogno è il certificato della CA di emissione (se non è pubblico). Ho faticato a farlo funzionare per un progetto web interno nella DMZ e c'è una reale mancanza di guide online.Così ho scritto uno quando avevo ottenuto che funziona:

http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/

Answer 3

Forse questo potrebbe aiutare ...

Questo fornitore, Stormpath, offre un servizio che fornisce: autenticazione degli utenti, la gestione degli account utente, con allacciamenti alle directory on-premise dei vostri clienti.

Answer 4

La soluzione migliore è implementare un'autenticazione SAML per l'applicazione SaaS e quindi registrarsi con provider di identità come Okta o OneLogin. Una volta fatto ciò, puoi anche collegarlo con ADFS per fornire Single Sign-On per la tua applicazione web tramite Active Directory.

Sto solo facendo questa ricerca da solo e questo è quello che ho trovato, avrò più aggiornamenti una volta che l'implementazione è stata eseguita. Spero che questo ti dà abbastanza parole chiave per fare un'altra richiesta google

Answer 5

mia comprensione è che ci sono tre possibili soluzioni:

1. installare qualcosa sul controller di dominio di catturare tutte le modifiche utente (aggiunte, eliminazioni, la password modifiche) e inviare aggiornamenti al server remoto. Sfortunatamente non c'è modo per il sito web di conoscere le password iniziali dell'utente - solo quelle nuove una volta cambiate.

2. Fornire l'accesso per il server Web per la connessione al controller di dominio tramite LDAP/WIF/ADFS. Ciò significherebbe probabilmente l'apertura di porte in ingresso nel firewall dell'azienda per consentire un IP specifico.

3. Altrimenti, ignorare nomi utente/password e utilizzare invece email-based authentication. Gli utenti dovrebbero semplicemente autenticarsi via e-mail una volta ogni 3-6 mesi per ciascun dispositivo.

Devo iniziare a implementare questo progetto per un progetto imminente e mi sto seriamente appoggiando all'opzione n. 3 per semplicità.