it-swarm.dev

Come impostare un unico accesso per più domini?

Ho impostato un Single Sign-On per due dei nostri siti che vivono nello 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% che posso dimenticare di usare OpenId (a loro non piacciono i servizi esterni qui, non sono riuscito nemmeno a farli 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 l'accesso Single Sign-On su più domini? Eventuali specifici problemi di sicurezza di cui dovrei essere a conoscenza prima di redigere una proposta?

21
samy

Il modo in cui il single sign-on è stato implementato 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 consultare il post sul blog di stackoverflow Accesso automatico alla rete globale per maggiori dettagli.

16
Mark Davidson

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

PS: OpenId può essere utilizzato per avere un'identità univoca utilizzata da molti siti ma è comunque necessario accedere "manualmente" su ciascun dominio.

5
Olivier Lalonde

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

5
nealmcb

Forse ADFSv2 (un download gratuito per Windows 2008R2) ti aiuterà con il cookie di dominio comune. Ecco un estratto del web.config che si trova 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="" />
2

Molte buone risposte qui.
Queste sono alcune buone soluzioni:

  • OpenID
  • OAuth
  • SAML
  • ADFS
  • Memoria locale

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

Meglio ancora sarebbe implementare un prodotto Web-SSO adeguato, 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 alcuni prodotti Web-SSO usano anche questo trucco (nota 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 POST richiesta al dominio di autenticazione, che ovviamente includerà il cookie dell'utente per quel dominio La risposta restituita direbbe sostanzialmente 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 nel dominio di autenticazione per inviare la password ecc.

Mentre questo è abbastanza semplice da configurare, nota che ci sono alcune sfide nel 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.
Naturalmente, il modo più semplice per risolvere questi problemi è - hai indovinato - SAML/OpenId/etc.

1
AviD

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.

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

In tal caso, hai già ottenuto il codice su ogni URL che richiede l'autenticazione per verificare se la sessione è stata autenticata e quindi intraprendere l'azione appropriata, eseguendo la richiesta o reindirizzando a una pagina di accesso. Tutto quello che devi fare è gestire lo scenario in cui non esiste una sessione autenticata e c'è una variabile crittografata passata nell'URL (ovvero come GET). Decifrare il valore, verificarne la validità e creare una sessione a questo punto. 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 esempio, vuoi condividere gli stessi dati di sessione su tutti i siti, vuoi ricollegare la sessione per sessioni diverse per assicurarti che non scada sul lato server) e devi anche pensare a come prevenire gli attacchi replay (ad esempio includendo un TTL nel payload crittografato, inclusa una sfida generata casualmente, ma fai attenzione all'uso dell'indirizzo IP del client).

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

0
symcbean