Come impostare un Single Sign-On per più domini?

Il modo in cui il Single Sign-On è stato implementato per la Stack Exchange Network è molto interessante. Fa uso di Storage locale HTML 5 . A seconda del supporto del browser richiesto, è possibile utilizzare un metodo simile.

Puoi controllare il post del blog StackOverflow Accesso automatico alla rete globale per ulteriori dettagli.

Non è necessario utilizzare un servizio esterno per OpenId. È possibile ospitare internamente un server OpenId e utilizzarlo per il proprio SSO. Questo ti permetterebbe di sfruttare il codice open source e tutto il lavoro che è stato fatto per rendere OpenId sicuro.

PS: OpenId può essere utilizzato per avere un'identità univoca utilizzata da molti siti, ma devi comunque effettuare il login "manualmente" su ciascun dominio.

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

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

  <!--
    Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers 
    (also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security 
    Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by 
    including the <commonDomainCookie> element in the web.config file.

      1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer 
      service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
      This address should be a valid URL.
      2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
      service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
      Providers that it should present to the user. This address should be a valid URL.

      The following configuration enables the use of common domain cookies and specifies writer and reader 
      services as described previously. 

      A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
      Space delimited URI encoded

      RULES:
      Must be secure
      Must have path = /
      Must be leading period as in .domain.com 
      Can be session or persistant
      All providers should be configured similarly
      TODO-->
    <commonDomainCookie writer="" reader="" />

Molte buone risposte qui.
Queste sono alcune buone soluzioni:

• OpenID
• OAuth
• SAML
• ADFS
• Archiviazione locale

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

Sarebbe ancora meglio implementare un vero prodotto web-SSO, anche se dalla tua domanda sembra che questa non sia un'opzione (anche se ti esorto a riconsiderare, e cerco di convincere i tuoi superiori).

Una soluzione piuttosto semplicistica che ho visto, e in effetti alcuni web-SSO utilizzano anche questo trucco (si noti che non consiglio necessariamente questo approccio in tutte le situazioni, vedi sotto):
Avere un terzo dominio di "autenticazione" che emette 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 includerà ovviamente il cookie dell'utente per quel dominio . La risposta restituita fondamentalmente dovrebbe dire al dominio originale, se l'utente è autenticato e, se necessario, quale sia la sua identità.
Se l'utente non è ancora autenticato, verrebbe reindirizzato a una pagina del dominio di autenticazione per inviare la sua password, ecc.

Anche se è abbastanza semplice da configurare, tieni presente che esistono alcune sfide per renderlo effettivamente sicuro.
Ad esempio, come definito, il sito web qualsiasi può recuperare la tua identità. Inoltre, il sito Web relying può essere "ingannato" modificando la risposta restituita.
Naturalmente, il modo più diretto per risolvere questi problemi è - avete indovinato - SAML / OpenId / etc.

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

Non hai fornito alcun dettaglio su come viene implementata l'autenticazione per il tuo sito corrente né sugli strumenti disponibili per la programmazione dei siti. Ma suppongo che il meccanismo di autenticazione sia scritto in un linguaggio che gira sul server web e usa un cookie per tenere traccia della sessione.

In questo caso, hai già ricevuto il codice su ogni URL che richiede l'autenticazione per verificare se la sessione è stata autenticata e quindi eseguire l'azione appropriata: l'esecuzione della richiesta o il reindirizzamento a una pagina di accesso. Tutto ciò che devi fare è gestire lo scenario in cui non esiste una sessione autenticata e c'è una variabile crittografata passata nell'URL (cioè come GET). Decifrare il valore, verificarne la validità e creare una sessione a questo punto. Quindi, nella tua pagina di accesso, dopo aver effettuato correttamente l'accesso, reindirizza, aggiungendo la coppia chiave / valore appropriata all'URL.

Questa è una breve panoramica: ci sono alcune modifiche a cui devi pensare (ad esempio vuoi condividere gli stessi dati di sessione su tutti i siti, vuoi ricollegare la sessione per diverse sessioni per assicurarti che non scada il server? -side) e devi anche pensare a come prevedi gli attacchi di replay (ad esempio includendo un TTL nel payload crittografato, inclusa una sfida generata casualmente, ma attenzione all'utilizzo dell'indirizzo IP del client).

Dato che stai solo crittografando / decrittando il lato server, la crittografia simmetrica è adeguata.