Applicazione Web - Autenticazione utente in tutti i domini

Question

Un nostro cliente ci ha contattato per sviluppare un'applicazione e, come al solito, l'ambito cresce di giorno in giorno.

Inizialmente è iniziato come un'app dedicata confinata nella loro rete aziendale. L'autenticazione utente è stata stabilita acquisendo il login di Windows dell'utente e utilizzando un database SQL Server per ospitare i diritti di accesso. Tutto abbastanza diretto.

Ora vogliono quanto segue:
- Applicazione da basare sul Web
- Applicazione da ospitare al di fuori della rete aziendale
- L'autenticazione utente funziona allo stesso modo (non utilizzare password, solo accessi a Windows)

Per complicarlo ulteriormente, vogliono che le varie funzioni dell'applicazione siano utilizzabili da un'altra applicazione che genera solo richieste HTTP.
- L'utente accede alla rete aziendale
- L'utente avvia l'applicazione aziendale
- L'utente elabora i dettagli del cliente
- L'utente fa clic su un pulsante
- L'applicazione aziendale invia una richiesta HTTP alla nostra app Web ospitata
- La richiesta HTTP includeva l'autenticazione necessaria e i dettagli del cliente
- L'autenticazione dell'utente è completata "automaticamente" (nessun coinvolgimento umano)
- I dati dei clienti vengono trasmessi in modo sicuro

Sono molto entusiasti di farlo per loro, poiché il nostro approccio iniziale era proprio quello che volevano. Vogliono ancora che lo facciamo anche se tali app Web ospitate non sono la nostra specialità. Quindi ora mi avvicino agli esperti;
- Qualcuno ha qualche consiglio su come affrontarlo?
- Qualcuno ha qualche avvertimento sulle possibili insidie ??da evitare?

Answer 1

Fondamentalmente stanno parlando dell'accesso federato. Dovresti ospitare un punto di autenticazione all'interno della loro rete che a sua volta inoltra un token all'applicazione che lo analizza e consente (o interrompe l'accesso). Questo è piuttosto standard e MS fornisce una buona base per questo nel Geneva Framework . Ciò funzionerà anche per le chiamate ai servizi Web, a condizione che possano modificare l'applicazione per utilizzare WSFed come protocollo e parlare con un servizio token di sicurezza che emette silenziosamente il token di autenticazione. Nella maggior parte dei casi utilizzerai SAML per questo. Ha anche il vantaggio aggiuntivo che i dettagli di autenticazione non vanno mai al di fuori della loro rete aziendale.

Il suggerimento dell'autenticazione basata su certificato è interessante, ma richiede più lavoro nella realizzazione di un'infrastruttura PKI. Questo può essere costoso.

CardSpace non funzionerà - non è silenzioso come sembrano volere. OpenID è anche un dispositivo di avviamento, non è nemmeno silenzioso.

Punti extra se stai guardando Azure: i bit di autenticazione di Azure usano anche SAML / WSFed sotto il cofano, e contengono bit di Ginevra. Quindi, se ti trasferissi nel cloud, ognuno dei tuoi clienti dovrebbe semplicemente configurare una pagina di accesso all'interno della propria rete - tutto ciò che dovresti fare è fidarti di quella pagina per emettere token di autenticazione e analizzarli secondo le tue regole.

Answer 2

Forse la comunicazione WCF con autenticazione basata su certificato, ovvero ad utenti esterni che utilizzano il servizio, l'azienda fornisce loro un certificato valido. Ciò non richiederebbe quindi una password per il nome utente ma indirizzerebbe l'utente direttamente.

Answer 3

Hai già dato un'occhiata a SAML ?

Answer 4

Scopri Windows CardSpace poiché si integra con il tuo accesso a Windows e consente l'SSO scenario che richiedono.

Answer 5

A seconda di come è costruita l'app, è possibile giocherellare con machineKey in web.config per consentire le chiamate AJAX con Single Sign-On (SSO). Ciò implicherebbe una piccola app asp.net all'interno della rete aziendale solo per inviare token di autenticazione e reindirizzare alla tua app ospitata.

Se le due app condividono la stessa macchinaKey, il sistema di autenticazione asp.net consentirà felicemente agli utenti di accedere alla tua app ospitata.

Ci sono problemi con questo approccio:

• Introduci un'altra dipendenza nel tuo sistema (l'app di autenticazione all'interno della rete aziendale.) Sarà un'app semplice, ma incontrerai problemi quando provi a diagnosticare problemi se non hai accesso.
• È necessario che il servizio ospitato sia nello stesso dominio dell'app di autenticazione (quindi il ticket di autenticazione nel cookie HTTP viene passato.)
• È inoltre necessario un certificato SSL per il servizio ospitato per proteggere le informazioni. (Non proprio un aspetto negativo di per sé, probabilmente vorrai farlo comunque.)
• Poiché tu e il tuo cliente avrete un KeyKey condiviso, vincolerete un'istanza della vostra app a quel particolare client.

Answer 6

Userei un provider / server OpenID privato per questo.