2013-01-24 18 views
7

Attualmente sto cercando una soluzione per il problema sopra indicato. Probabilmente eseguiremo l'autenticazione della form su .NET.Single Sign On con 2 sottodomini, uno Java, uno .NET

Ho un'app ASP.NET MVC in esecuzione su a.mydomain.com e un'app basata su Java in esecuzione su b.mydomain.com.

Qual è l'approccio migliore in modo che non debba accedere a ciascuna app. Dite, quando accedo allo a.mydomain.com e poi apro Java b.mydomain.com, e controllerà e vedrò che sono già registrato?

La classe WCF AuthenticationService dovrebbe funzionare correttamente? Posso fare una richiesta AJAX dal codice JavaScript di b.mydomain.com per verificare se sono già connesso all'app .NET?

risposta

2

Finché mydomain.com non è nella lista di suffissi pubblico (http://publicsuffix.org/list/), a.mydomain.com può mettere un cookie del dominio a .mydomain.com

(notare che è possibile solo scendere di un livello nella cookie di mettere: a.b.mydomain.com non può mettere un .mydomain.com cookie)

Il cookie verrà inviato b.mydomain.com (così come *.mydomain.com e mydomain.com) e può essere usato come un token per aprire una sessione. Quindi, essere sicuri di controllare l'intero * .mydomain.com sottodominio e renderlo HTTPOnly e protetto (https)

Response.SetCookie(new HttpCookie("myCookieName", "myCookieValue") { HttpOnly = true, Domain = ".myDomain.com", Secure=true }); 

Alcune parti della soluzione Atlassian Folla http://www.atlassian.com/software/crowd/overview sono basati su questo meccanismo di cookie

Così si potrebbe :

  1. Abilita autenticazione moduli su a.dominio.com
  2. al login di successo costruire un cookie myToken cui valore contiene UserID e hashing userId con chiave di hashing conosciuto da a.myDomain.com e b.myDomain.com
  3. impostare il cookie con il dominio .mydomain.com
  4. quando utente inserisce b.myDomain.com, controllare il lato server dei cookie (in java) per la corrispondenza tra l'userid e il valore hash
  5. se il cookie è corretta, sessione aperta per l'utente id utente

Nota che non lo farà essere in grado di accedere al lato client del cookie (quindi nessuna gestione dei cookie js, tranne se i t è lato server js, ad esempio nodejs)

+0

così potrei semplicemente abilitare l'autenticazione dei form su .NET .. e quindi il cookie verrà automaticamente passato all'altro sottodominio? :/ e quindi hanno solo bisogno di controllare se quel cookie esiste in javascript ??? sono via di qui? E questo non sarebbe molto male? e aperto ad attaccare ?? –

+0

@NeilHosey Ho modificato il mio risponditore. Spero che questo aiuti – jbl

+0

Ma il b.mydomain.com sarà in grado di determinare quale utente è effettivamente connesso? è una buona idea conservare questi dati nel cookie? insieme alle informazioni sull'autismo per l'accesso a parti del sistema? –

1

L'utilizzo di una soluzione esistente Java o .NET non è probabile che funzioni sull'altra piattaforma. Sono necessarie diverse funzionalità:

  1. Tracciamento del client con un identificatore per il riconoscimento (sessione, cookie).
  2. Possedere sia l'applicazione Java che .NET essere in grado di ottenere le informazioni correlate.

Come si può fare?

  1. Questo è in realtà abbastanza semplice. Stai utilizzando lo stesso dominio per poter inserire un cookie nel browser per tutti i domini, il che significa che le richieste a * e b * avranno entrambi il cookie inviato al server. Sia Java che .NET hanno eccellenti funzionalità per il posizionamento dei cookie.
  2. Questo dipende dal vostro back-end. Quali sono i sistemi che utilizzano per la memorizzazione persistente? Se si dispone di qualcosa come un database MySQL a cui sono connessi entrambi i sistemi, è possibile creare una tabella con le informazioni di accesso per ogni identificatore memorizzato per l'autenticazione. Se segui questa strada, abbi un po 'di time-out per invalidare le vecchie autenticazioni.

Se si dispone di entrambe queste informazioni, è possibile eseguire l'autenticazione su ciascun sistema.

1

Si consiglia di utilizzare uno dei protocolli aziendali ISO, Oauth2 o federazione ws. Questo ti dà la massima flessibilità nel comporre i tuoi servizi, non puoi solo federare questi due ma, successivamente, espandere facilmente il tuo ambiente applicativo. Entrambi i protocolli non hanno bisogno che le app si trovino nello stesso dominio.

Sebbene ciò possa sembrare complicato per le vostre esigenze, lo fate una sola volta e il problema è risolto per sempre, indipendentemente da ciò che accadrà in futuro alle vostre applicazioni.

+0

grazie. li esaminerò. L'id piuttosto una soluzione semplice sebbene come sembra a me essere un problema semplice, io non ho la conoscenza in questa area –

Problemi correlati