Soluzione per evitare doppio hop dal client> servizio Web> SQL Server

Question

Il mio progetto invoves un utente che si collega dal client al servizio web, e quindi servizio web a SQL Server. I servizi web e SQL Server sono in macchine separate. A causa dei requisiti di sicurezza, non possiamo utilizzare modalità mista in SQL Server, solo l'autenticazione di Windows.

Stiamo vivendo la questione "doppio-hop" tra il servizio Web e SQL Server. Stiamo utilizzando l'autenticazione NTLM e fare non vogliono configurare Kerberos a causa della curva di spese generali e di apprendimento. Noi, inoltre, non vuole avere il servizio web e SQL Server sullo stesso computer.

Da quello che ho capito, tutti i nostri requisiti rendono questo scenario impossibile da risolvere. Tuttavia, uno sviluppatore si avvicinò con questo suggerimento:

1) Invia le finestre username e password dal client al servizio Web sotto SSL crittografia

2) In qualche modo convertire le finestre username e password in un token di sicurezza che potrebbero essere autenticati da SQL Server

Per fare un'analogia, suona come avremmo fatto un RUNAS nel codice C # per la connessione a SQL Server. Non ci sarebbe alcuna autenticazione per il servizio Web, solo tramite SQL Server.

Le mie domande:

1) Se la soluzione proposta possibile?

2) In caso affermativo, come sarebbe fatto?

3) Tutte le risorse di Internet per aiutarmi a capire come si potrebbe fare?

Answer 1

No, questo non è possibile. Il processo client fa non accedere alla password utente, e quindi non può inviarlo al livello di servizio web. Il cliente avrebbe dovuto chiedere esplicitamente l'utente per la sua password. Se il processo client ha la password ed è disposto a inviarlo al servizio web quindi, in teoria, la WebService può creare un token per l'utente / password (utilizzando LogonUser ) e quindi connettersi a SQL Server utilizzando tale token. Questa cosiddetta soluzione è così pieno di molteplici problemi di sicurezza che non vale la pena di discutere. Se la tua squadra insistere su di esso, fare un servizio web che fa questo, chiedere a un membro del team di connettersi ad esso, e una volta entrato in possesso delle sue credenziali (che invierà il vostro servizio la sua Password , ricordi? ) connettersi al server di scambio e inviare una mail al CEO con il testo 'Fire me, che sono un idiota'. O cambiare la sua banca di deposito diretto e spiegare in HR. Usa la tua immaginazione ... Spero che ora è un po 'più chiaro il motivo per cui andando verso il basso il percorso che proponiamo è un pessima idea .

Basta usare Kerberos.

A proposito, se è necessario autenticarsi al back-end a causa di regolamentazione governativa, quindi tenere a mente che l'autenticazione e audit sempre venire con un requisito di 'non-ripudio', e l'invio della password per il servizio web in modo che l'autenticazione sui vostri flagrante contraddizione con tale obbligo, dal momento che il servizio web in grado di fare qualsiasi operazione che vuole mascherato come l'utente. Questo è ciò che la delega Kerberos è vincolata delegazione.

Answer 2

Questo non poteva essere fatto. Pensateci, se le applicazioni potrebbero semplicemente generare token di sicurezza in questo modo, a cosa sarebbe? Avrete bisogno di Kerberos per superare questo problema.

Modifica:. Anche il runas analogia non si applica nel caso di un cliente che cerca di autenticazione in due sistemi in successione, dal momento che runas richiede solo un singolo hop, anche quando si passa l'utente