trasparente all'utente su più siti (single sign-on + single sign-off)

Question

Ho diversi siti in diversi ambiti: example.com, example.org, mail.example.com e passport.example.org. Tutti i siti hanno un aspetto comune e lo dovrebbe condividere la stessa base di utenti.

e in tal caso estremo voglio ancora tutti i siti a trasparente (per quanto possibile) le sessioni utente quota con le seguenti proprietà chiave:

1. Single sign-on. Quando utente accede al passport.example.org e visite qualsiasi altro sito - dovrebbe essere trattato come loggato

   gli utenti registrati ottenere “Ciao, $username“saluto nella testata del sito e diversi menu di navigazione, messa in vendita di servizi che hanno accesso. . Se non ha effettuato l'accesso, invece di saluto c'è un collegamento "Accedi", che punta a passport.example.org/signon.

   L'elenco dei domini trusted è noto, quindi è abbastanza semplice implementare con OpenID o con qualche protocollo homebrewn leggero. Quando l'utente per prima cosa visita il sito , lo sto reindirizzando a un endpoint di autenticazione speciale a passport.example.org, che poi reindirizza automaticamente a lui indietro, con informazioni di identità (o "non firmato" identità anonima) incluso. Per la maggior parte dei browser questo è completamente trasparente. Ovviamente, sto usando i valori nonce per combattere i loop di reindirizzamento.

2. Single sign-off. Quando l'utente fa clic su "firma" nell'intestazione di qualsiasi sito la volta successiva che visita un sito, deve essere considerato "non connesso".

   OpenID non è stato progettato per questo. La mia idea attuale (ho già un'implementazione parzialmente funzionante) è quella di inviare non l'identità dell'utente, ma il token di sessione "globale" e condividere la tabella delle sessioni globali (global_session_token ↔ relazione utente) nel DB.

3. Supporto per robot e utenti senza chiave. I siti stanno avendo aree pubbliche, che dovrebbero essere accessibili da dagli user-agent senza alcun supporto per i cookie.

   Per questo motivo, il reindirizzamento di cui ho parlato in (1) diventa un problema, perché per ogni singola richiesta di pagina, finirò con il lancio di user-agent su auth endpoint e ritorno. Non solo questo confonderà i robot, ma inquinerà il mio database di sessione con le sessioni di decesso alla nascita molto rapidamente. E sicuramente non voglio visualizzare "hey, non hai i cookie abilitati, vai via!", Sarebbe estremamente scortese e deludente. Mentre richiedo il supporto dei cookie per l'accesso, voglio che gli utenti leggano liberamente a cosa servono i siti e così via - senza alcuna restrizione.

   E io esplicitamente non voglio mettere ID di sessione negli URL ad eccezione di alcuni trasparenti reindirizzamenti cross-domain che ho menzionato. Credo che fare questo sia un problema di sicurezza e in generale una brutta cosa.

   E qui sono quasi fuori dalle idee.

Okay, so che e 'difficile, ma Google in realtà fa questo in qualche modo con (google.com, google.sacco-di-gTLD, gmail.com e così via), giusto? Quindi questo dovrebbe essere possibile.

sarei grato sia per Description Protocol idee (che sarebbe il migliore) o link ai sistemi (sia il codice per leggere o semplicemente vivere siti per guardare e imparare su) già attuare con successo una cosa del genere.

Per riassumerlo: Diversi domini senza radice comune, base utente condivisa, accesso singolo, accesso singolo, nessun cookie richiesto per la navigazione anonima.

Tutti i siti si trovano sulla stessa rete (ma si trovano su server diversi) e parzialmente lo condividono lo stesso database PostgreSQL (che si trova nei diversi schemi dello stesso database). La maggior parte dei siti sono scritti con Python/Django, ma alcuni usano PHP e Ruby on Rails. Mentre sto pensando a qualcosa di framework- e linguistico-agnostico, sono grato di indicare eventuali implementazioni. Anche se non sarò in grado di usarli, se avrò l'idea di come è fatto, forse sarò in grado di realizzare qualcosa di simile.

Answer 1

Bene, lasciatemi spiegare un po 'più avanti. (Tutti gli URL sono fittizi!) Come ho detto, il visitatore va a http://www.yourwebpage.com e indica che vuole accedere. Viene reindirizzato a http://your.loginpage.org?return=http://www.yourwebpage.com/Authenticated dove dovrà fornire il suo nome utente e password.
Quando le sue informazioni sull'account sono valide, ritornerà alla pagina fornita nell'URL di accesso, ma con un parametro aggiuntivo che verrà utilizzato come ID. Così, va a http://www.yourwebpage.com/Authenticated?ID=SharedSecret dove SharedSecret sarebbe un ID temporaneo, valido per 30 secondi o meno.
Quando viene chiamata la pagina di autenticazione, la pagina chiama quindi un metodo condiviso tra yourwebpage.com e loginpage.org per cercare le informazioni sull'account di SharedSecret per recuperare un ID più permanente. Questo ID permanente viene memorizzato nella sessione Web di yourwebpage.com e non deve MAI essere mostrato all'utente.
Il metodo condiviso potrebbe essere qualsiasi cosa. Se entrambi i server si trovano sullo stesso computer, potrebbero entrambi accedere allo stesso database. In caso contrario, potrebbero comunicare con un altro server tramite i servizi Web. Questa sarebbe una comunicazione da server a server, quindi non importa se l'utente è un robot o non ha alcun supporto per i cookie. Questa parte non verrà notata dall'utente.
L'unica cosa che dovrai affrontare è la sessione per l'utente. Normalmente agli utenti verrà inviato un ID di sessione memorizzato in un cookie ma può anche far parte dell'URL come parte di una richiesta GET. È comunque un po 'più sicuro avere l'ID di sessione all'interno di una richiesta POST, aggiungendo un campo di input nascosto al modulo.

Fortunatamente, diversi linguaggi di sviluppo Web forniscono già il supporto di sessione in modo da non doversi nemmeno preoccupare di mantenere sessioni e inviare ID di sessione. La tecnica è interessante, però. E devi essere consapevole che le sessioni dovrebbero sempre essere temporanee poiché c'è il rischio che l'ID di sessione venga compromesso.

Se devi gestire più siti su domini diversi, dovrai prima lavorare su alcune comunicazioni server-server. La cosa più semplice sarebbe lasciare che condividessero lo stesso database ma è meglio creare un servizio Web attorno a questo database, per una protezione aggiuntiva. Assicurati che questo servizio Web accetti solo richieste dai tuoi domini solo per aggiungere un po 'più di protezione.
Quando si dispone di connessioni da server a server, l'utente sarà in grado di passare da un dominio all'altro e fino a quando si passa lungo un ID di sessione nel nuovo dominio, l'utente avrà effettuato l'accesso.Se l'utente sta utilizzando i cookie, non è molto probabile che la sessione si perda e che richieda l'accesso di nuovo. Senza i cookie, c'è la possibilità che l'utente debba accedere di nuovo per ottenere un nuovo cookie se l'ID di sessione viene perso tra le pagine di navigazione. (Ad esempio, il visitatore visita Google e quindi torna al tuo sito. Con un cookie, la sessione potrebbe essere letta dal cookie. Senza un cookie la sessione viene persa poiché Google non inoltrerà gli ID sessione in avanti.

Ricorda che il passaggio degli ID di sessione tra domini diversi è un rischio per la sicurezza.L'ID di sessione può essere dirottato, rendendo così possibile che qualcun altro impersonifichi il tuo visitatore, pertanto gli ID di sessione dovrebbero essere di breve durata e offuscati. Ma anche se un hacker ottiene l'accesso a un ID di sessione, non avrà ancora pieno accesso all'account stesso, non sarà in grado di intercettare le comunicazioni da server a server in modo che non possa accedere al database con il tuo informazioni utente, a meno che non vada direttamente alla pagina di login

Answer 2

Si sta utilizzando ASP.NET? Se è così, potresti voler dare un'occhiata alla proprietà enableCrossAppRedirects.

Answer 3

AFAIK, Google utilizza solo un cookie per il dominio "Google.com". Ma Google utilizza anche OpenID che consente un meccanismo di accesso generico. Fondamentalmente, questo funziona reindirizzandoti a una pagina di accesso speciale. Questa pagina di login rileverà se sei loggato o meno e se non sei loggato ti chiederà di accedere. In caso contrario, ti reindirizzerà direttamente alla pagina successiva.

Quindi, nel tuo caso, un utente aprire page.example.com e la sessione per questa applicazione non ha ID di accesso. Quindi reindirizza l'utente a logon.example.biz dove l'utente effettuerà l'accesso. Dietro questa pagina sarebbe anche una sessione e quella sessione direbbe che l'utente è già loggato. (O no, nel qual caso l'utente deve prima accedi.) Quindi reindirizza l'utente somepage.example.com?sessionid=qualcosa in cui questo sessionid verrà archiviato nella sessione di somepage.example.com. Quindi questa sessione saprà anche che l'utente ha effettuato l'accesso e per l'utente sembrerebbe quasi trasparente.

In realtà, l'utente viene reindirizzato due volte.

Answer 4

Se tutte le applicazioni si trovano in un dominio, non è troppo difficile perché è possibile utilizzare un cookie a livello di dominio per gestire il controllo di sessione. (La gestione delle sessioni senza cookie è difficile, ma può essere eseguita, ma è difficile.)

Tuttavia, hai indicato alcuni siti nel dominio esempio.com e alcuni nel dominio example.org.

Giocando un po 'con il mio go-go google, e altri siti del loro orkut.com, sembra che quando si preme una pagina che ha bisogno di credenziali, ti reindirizza a un sito comune per l'accesso all'account, che poi ti reindirizza torna al sito originale, presumibilmente passando una sorta di token di sessione nell'URL. Da questo, presumibilmente i server orkut.com conferiscono direttamente con i server google.com per verificare il token e ottenere qualunque altra informazione dell'utente sia necessaria.

più informazioni level domain cookie come Reqeusted

Se si dispone di due siti, per esempio foo.example.com e bar.example.com, è possibile impostare un cookie specifico per l'host, ma è anche possibile impostare un cookie per il dominio che verrà essere visto da tutti gli host del dominio.

Quindi, foo.example.com possibile impostare un cookie per foo.example.com specifico, e si vedrà solo per se stesso, ma può anche impostare un cookie per il dominio example.com, e quando l'utente va a bar.example.com Essi potranno anche vedere questo secondo biscotto.

Tuttavia, se avete anche un sito, snafu.example.org, non può vedere questo cookie livello di dominio che foo insieme, perché example.org e example.com sono due domini completamente diversi.

È possibile utilizzare il cookie a livello di dominio per mantenere le informazioni di sessione tra siti nello stesso dominio.

Come si impostano i cookie a livello di dominio dipende dal proprio ambiente di sviluppo (non ho esperienza con le guide, scusa).

Answer 5

Per questa soluzione non è necessario passare t server.

Signin

1. Accesso
2. Creare token con criptato id di sessione e altre informazioni
3. Visualizza img con gettone da tutti voi i domini per impostare i cookie sul suo.

Autorizzazione da biscotto

1. Hai già cookie su tutti i domini.

Esci

1. Cancella cookie di
2. Destroy sessione
3. Cancella user id relazione con l'ultimo ID di sessione nel DB (credo si salva ID di sessione nella tabella utente per aumento fino sessione cookie di)

Non riesco a provare questa soluzione. Ma ora ho lo stesso problema di te (SSO) e ci provo domani.

Answer 6

Ho usato shibboleth, per entrambi gli scenari SSO e Federated Identity, ma presumo che siano necessarie soluzioni più semplici a quelle sopra menzionate.

Answer 7

Un plug-in con funzionalità di rotaia con dominio incrociato per farlo sarebbe fantastico.

Mi piacerebbe farlo, l'unico modo in cui potevo pensare era forzare l'utente a scaricare una barra degli strumenti, o qualche piccola app per l'aria che gestisse automaticamente il login per me.

Mi piacerebbe sapere un altro modo per causare quel colpo