come implementare il single sign on in .Net?

Question

Qual è la soluzione migliore per implementare il single sign on in un'applicazione .net? Ho cercato su Google e trovato poche soluzioni, ma non sono molto convinto di queste soluzioni.

L'utente accede al sito Web1 e quindi si sposta sul sito Web2. In che modo website2 saprà che l'utente ha effettuato l'accesso? Immagino passando qualche token nell'url che verrà controllato dal sito web2 nel database per la validità. Ciò significa che ho bisogno di eseguire il marshalling di tutti gli URL nel sito Web1 che richiede sito2?

In secondo luogo se l'utente continua a navigare sul sito Web2 per dire 1 ora e quindi passa al sito1. A quel punto, la sessione del sito Web 1 è scaduta, quindi l'utente vedrà una pagina di accesso, vero? Ma questo comportamento è sbagliato secondo la funzionalità single sign on.

Answer 1

Penso che tu abbia frainteso il funzionamento del Single Sign-On.

Consente di considerare sito1 e sito2 che desiderano utilizzare il profilo di accesso singolo.

Un sito Web di accesso viene creato su identityProvider. Questo è l'unico posto in cui appare una schermata di accesso.

Quando l'utente visita il sito1 e sceglie di accedere al sito Web1, invia l'utente alla schermata di accesso su identityProvider. L'utente accede a identityProvider che elimina il proprio cookie di accesso per il suo dominio (e forse consente all'utente di salvare le proprie informazioni di autenticazione in modo che non vengano mai più richieste). Quindi reindirizza il browser al sito Web1 includendo un token nella richiesta che website1 apre, acquisisce informazioni sull'identità e esegue i propri bit di accesso (eliminando il proprio cookie di autenticazione che dura per quanto vuole).

Quindi l'utente visita il sito Web2 e seleziona l'accesso. Website2 rimbalza l'utente su identityProvider, che sa già chi è l'utente e, se l'utente ha scelto di salvare le proprie informazioni di accesso, si autentica in silenzio e poi reindirizza nuovamente al sito2 con un altro token che website2 si apre e quindi esegue i propri bit di accesso.

C'è un sacco di sicurezza intorno ad esso, limitando i token a particolari siti web, i token da inviare a siti web whitelist ecc ecc

Quindi, per affrontare le vostre preoccupazioni

1. utente accede consentendo solo sito1 e quindi passa a sito2. In che modo website2 saprà che l'utente ha effettuato l'accesso? Non è così. website2 deve prima richiedere le informazioni di autenticazione dal sito di single signon.
2. Ciò significa che devo eseguire il marshalling di tutti gli URL nel sito Web1 che richiede il sito2? No, a meno che tu non crei anche il sito web1 come fornitore di identità. Anche in questo caso, sarebbe doloroso, meglio avere reindirizzamenti website2 al provider di identità se è necessario un token.
3. In secondo luogo se l'utente continua a navigare sul sito Web2 per dire 1 ora e quindi passa al sito1. A quel punto, la sessione del sito Web 1 è scaduta, quindi l'utente vedrà una pagina di accesso, vero? - Dipende da come si configura website1 e da quanto tempo dura il cookie di autenticazione.
4. Ma questo comportamento è errato in base alla funzionalità Single Sign-On. No non lo è. Single signon non significa che ottieni un token floating condiviso tra i siti. Ogni sito Web che utilizza il single sign-on crea ancora il proprio cookie di autenticazione. Ciò che potrebbe accadere è se l'utente torna al sito web1 rileva un cookie di autenticazione scaduto, quindi invia nuovamente l'utente alla pagina di single signon dove sono autenticati (silenziosamente) e un nuovo token viene reindirizzato al sito1 che crea un nuovo cookie di autenticazione per sé.

Answer 2

MS ha fatto un articolo su di esso all'interno della Enterprise a pochi anni fa - abbiamo set-up i campioni, ma mai attuata per davvero - Single Sign-on

Answer 3

L'approccio ufficiale di Microsoft è via Active Directory Federation Services (che avvolge SAML con autenticazione AD). Questo ha le caratteristiche che stai cercando - ma è forse troppo pesante per un'applicazione web pubblica.

Answer 4

Suppongo che non si desideri utilizzare l'autenticazione di Windows con Active Directory, ecc. Un metodo consiste nel passare da una sessione autenticata a un'altra utilizzando un token di sicurezza sulla stringa di query, come descritto.

Entrambe le applicazioni utilizzano la stessa chiave di crittografia pubblica per codificare/decodificare il token di sicurezza. Come dici tu, questo funziona bene se hai dei collegamenti di transizione predefiniti e limitati tra i siti, ma se vuoi essere in grado di utilizzare qualsiasi collegamento di pagina tra le app devi generare quegli URL al volo in modo che contengano il token.

Il modo in cui si gestiscono i timeout è che il token di sicurezza contiene anche una scadenza. Genera un nuovo token di sicurezza ogni richiesta di pagina o quando crei un nuovo collegamento tra le app.

In genere il token di sicurezza contiene un ID utente e un timeout e il controllo di accesso restituisce l'id utente o null se il timeout è scaduto.

Non è una soluzione rapida per la codifica in modo corretto e sicuro. Forse puoi trovare uno pre-costruito su Code Project?

Answer 5

È possibile utilizzare diversi meccanismi SSO per diverse applicazioni in base all'applicazione.

• mezzo della macchina Config

• Single Sign-on in un secondo Level Domain

• Cross Domains Using Common database (Attuazione dovrebbe essere presa cura da noi)

Tuttavia, potrebbe vedere il servizio "SSO Out-of-box" da Live, Google, Yahoo, Facebook ecc. Per fornire l'autenticazione supportando SAML. Questo ci aiuterà a sbarazzarci dei problemi mantenendo la nostra implementazione del servizio SSO.

Se avete bisogno di una conoscenza di base come il lavoro SSO, è possibile fare riferimento here

Answer 6

controlla questo link con l'utilizzo di OAuth e fornitori sociali, offre una moltitudine di funzionalità di autenticazione già cotti in .Net Microsoft training video on OAuth and single sign on with social providers