Domanda:
Come impostare un Single Sign-On per più domini?
samy
2010-11-26 15:45:20 UTC
view on stackexchange narkive permalink

Ho impostato un Single Sign-On per due dei nostri siti che risiedono sullo stesso dominio: a.domain.com e b.domain.com

L'ho fatto tramite i cookie, ma sono dipendenti dal dominio. E - come è scritto nel Great Book - ora la necessità di single-sign-on su diversi domini ha sollevato la sua brutta testa :) Sono sicuro al 99% di poter dimenticare di usare OpenId (a loro non piacciono i servizi esterni qui, non sono nemmeno riuscito a convincerli ad accettare reCaptcha)

Mi piacerebbe essere in grado di identificare qualcuno su diversi siti web (a.domain.com, b.anotherdomain .com, ecc.). Quali sono i modi consigliati per configurare / gestire il Single Sign-On su più domini? Qualche problema di sicurezza specifico di cui dovrei essere a conoscenza prima di redigere una proposta?

Sei risposte:
Mark Davidson
2010-11-26 16:02:40 UTC
view on stackexchange narkive permalink

Il modo in cui è stato implementato il Single Sign-On per Stack Exchange Network è molto interessante. Utilizza HTML 5 Local Storage. A seconda del supporto del browser richiesto, potresti essere in grado di utilizzare un metodo simile.

Puoi controllare il post del blog di stackoverflow Accesso automatico alla rete globale per maggiori dettagli.

Olivier Lalonde
2010-11-26 22:37:26 UTC
view on stackexchange narkive permalink

Non è necessario utilizzare un servizio esterno per OpenId. Potresti ospitare un server OpenId internamente e usarlo per il tuo SSO. Ciò ti consentirebbe di sfruttare il codice open source e tutto il lavoro svolto per rendere OpenId sicuro.

PS: OpenId può essere utilizzato per avere un'identità univoca utilizzata da molti siti ma devi comunque "farlo manualmente "accedi a ogni dominio.

Dover accedere manualmente a ciascun dominio (anche se non implica altro che un reindirizzamento da e verso il sito Web OAuth) non è ciò che significa "single sign-on" perché concettualmente il browser dell'utente viene connesso separatamente per ogni sito web.
nealmcb
2010-11-26 23:24:31 UTC
view on stackexchange narkive permalink

Due buoni protocolli per questo sono OAuth (http://en.wikipedia.org/wiki/OAuth) e SAML. Puoi eseguire il tuo sito "provider di identità", utilizzando OpenID o altri approcci di autenticazione.

Ciò richiede un po 'di sforzo, ma penso che sia sicuramente l'approccio migliore.
OAuth (e OAuth2 e OpenID Connect) non specifica come può essere implementato SSO, infatti non si preoccupano affatto dell'autenticazione.Un'implementazione stock di OIDC su più nomi di dominio richiede che l'utente venga reindirizzato nuovamente all'endpoint di autenticazione OIDC ogni volta che visita un nuovo sito Web "in rete": non si tratta di un'esperienza utente SSO.
goodguys_activate
2010-11-26 23:23:56 UTC
view on stackexchange narkive permalink

Forse ADFSv2 (un download gratuito per Windows 2008R2) ti aiuterà con il cookie di dominio comune. Ecco un estratto del web.config situato in C: \ inetpub \ adfs \ ls che dovrai configurare per ottenere l'effetto desiderato.

  <! - Cookie di dominio comune. Un cookie di dominio comune memorizza un elenco di provider di attestazioni visitati di recente (chiamati anche provider di identità), come descritto nella Sezione 4.3.1 di Profili per SAML (Security Assertion Markup Language) V2.0 di OASIS. Si consiglia di abilitare i cookie di dominio comuni includendo l'elemento <commonDomainCookie> nel file web.config. 1. L'attributo writer dell'elemento <commonDomainCookie> specifica l'indirizzo del servizio writer utilizzato da un provider di attestazioni per impostare il cookie di dominio comune dopo aver autenticato un utente. Questo indirizzo dovrebbe essere un URL valido. 2.L'attributo di lettura dell'elemento <commonDomainCookie> specifica l'indirizzo del servizio di lettura che un servizio in grado di riconoscere attestazioni (chiamato anche fornitore di servizi) utilizza per ottenere l'elenco dei fornitori di attestazioni che dovrebbe presentare all'utente. Questo indirizzo dovrebbe essere un URL valido. La seguente configurazione abilita l'uso di cookie di dominio comuni e specifica i servizi di scrittura e lettura come descritto in precedenza. Un cookie di dominio comune è denominato "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf URI delimitato da spazi con codifica REGOLE: devono essere secure Deve avere path = / Deve essere il periodo iniziale come in .domain.com Può essere di sessione o persistente Tutti i provider devono essere configurati in modo simile TODO - > <commonDomainCookie writer = "" reader = "" / >  
AviD
2010-11-28 19:49:10 UTC
view on stackexchange narkive permalink

Molte buone risposte qui.
Queste sono alcune buone soluzioni:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Archiviazione locale

Anche se non penso che nessuno di questi sia davvero banale da implementare, senza saperne un po 'di più su di loro.

Ancora meglio sarebbe implementare un prodotto Web-SSO appropriato, anche se dalla tua domanda sembra che questa non sia un'opzione (anche se ti esorto a riconsiderare e provare a convincere i tuoi superiori).

Una soluzione piuttosto semplicistica che ho visto, e in effetti anche alcuni prodotti Web-SSO usano questo trucco (nota che non consiglio necessariamente questo approccio in tutte le situazioni, vedi sotto):
Avere un terzo dominio di "autenticazione" che emetta un "cookie di identità" (dopo aver autenticato l'utente). I siti web su altri domini possono inviare una semplice richiesta POST al dominio di autenticazione, che ovviamente includerà il cookie dell'utente per quel dominio . La risposta restituita in pratica direbbe al dominio originale se l'utente è autenticato e, se necessario, qual è la sua identità.
Se l'utente non è ancora autenticato, verrebbe reindirizzato a una pagina del dominio di autenticazione per inviare il suo password ecc.

Anche se è piuttosto semplice da configurare, tieni presente che ci sono alcune sfide per renderlo effettivamente sicuro.
Ad esempio, come definito, qualsiasi sito web può recuperare la tua identità. Inoltre, il sito Web affidabile può essere "ingannato" modificando la risposta restituita.
Ovviamente, il modo più semplice per risolvere questi problemi è - hai indovinato - SAML / OpenId / ecc.

symcbean
2010-11-30 18:59:24 UTC
view on stackexchange narkive permalink

Mi sono appena registrato, ma trovo sorprendente che tu non abbia trovato una risposta altrove. Come hai già scoperto, non puoi passare token di autenticazione surrogati utilizzando i cookie.

Tu non hai fornito dettagli su come è implementata l'autenticazione per il tuo sito corrente né gli strumenti che hai a disposizione per programmare i siti. Ma presumo che il meccanismo di autenticazione sia scritto in una lingua che viene eseguita sul server web e utilizza un cookie per tenere traccia della sessione.

In tal caso, hai già il codice su ogni URL che richiede l'autenticazione per verificare se la sessione è stata autenticata, quindi intraprendere l'azione appropriata: eseguire la richiesta o reindirizzare a una pagina di accesso. Tutto quello che devi fare è affrontare lo scenario in cui non c'è una sessione autenticata e c'è una variabile crittografata passata nell'URL (cioè come GET). A questo punto decifrate il valore, verificate che sia valido e create una sessione. Quindi sulla tua pagina di accesso, dopo un accesso riuscito, reindirizzi, aggiungendo la coppia chiave / valore appropriata all'URL.

Questa è una breve panoramica: ci sono alcune modifiche a cui devi pensare (ad es. vuoi che gli stessi dati di sessione siano condivisi su tutti i siti, vuoi riassociare la sessione per sessioni diverse per assicurarti che non scada lato server) e devi anche pensare a come prevenire attacchi di replay (ad esempio includendo un TTL in payload crittografato, inclusa una sfida generata casualmente, ma attenzione a non utilizzare l'indirizzo IP del client).

Poiché stai crittografando / decrittografando solo lato server, la crittografia simmetrica è adeguata.

Ti stai perdendo diversi punti, come il fatto che potrebbero essere server * diversi *, nel qual caso la tua soluzione vola fuori dalla finestra. Inoltre, passare questo "token segreto" nell'URL è una ** cattiva idea **.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...