Birden çok alan için tek bir oturum açma nasıl ayarlanır?

OpenId için harici bir hizmet kullanmak zorunda değilsiniz. Dahili olarak bir OpenId sunucusu barındırabilir ve TOA'nız için kullanabilirsiniz. Bu, açık kaynak kodundan ve OpenId'i güvenli hale getirmeye yönelik tüm çalışmalardan yararlanmanıza olanak tanır.

Not: OpenId, birçok site tarafından kullanılan benzersiz bir kimliğe sahip olmak için kullanılabilir, ancak yine de her etki alanında "manuel olarak" oturum açmanız gerekir.

Bunun için iki iyi protokol OAuth (http://en.wikipedia.org/wiki/OAuth) ve SAML'dir. OpenID veya başka bir kimlik doğrulama kullanarak kendi "kimlik sağlayıcınız" sitenizi çalıştırabilirsiniz yaklaşımlar.

Belki de ADFSv2 (Windows 2008R2 için ücretsiz bir indirme), ortak etki alanı çerezi konusunda size yardımcı olacaktır. C:\inetpub\adfs\ls İçinde bulunan web.config dosyasının istenen efekti elde etmek için yapılandırmanız gereken bir alıntısı.

  <!--
    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="" />

Burada çok iyi cevaplar var.
Bunlar iyi çözümler:

• OpenId
• OAuth
• SAML
• ADFS'de
• Yerel depolama

Bunların hiçbirini, onlar hakkında biraz daha fazla bilgi edinmeden uygulamak için gerçekten önemsiz olduğunu düşünmüyorum.

Daha da iyisi, uygun bir web-SSO ürünü uygulamak olurdu - sorunuzdan bu bir seçenek değil gibi görünse de (yine de sizi yeniden düşünmenizi ve daha yüksek seviyelerinizi ikna etmeye çalışmanızı isterim).

Gördüğüm oldukça basit bir çözüm ve aslında bazı web-SSO ürünleri bu numarayı da kullanıyor (her durumda bu yaklaşımı mutlaka önermediğimi unutmayın, aşağıya bakın):
"Kimlik çerezi" yayınlayan üçüncü bir "kimlik doğrulama" alan adınız olsun (kullanıcının kimliğini doğruladıktan sonra). Diğer alanlardaki web siteleri, kimlik doğrulama alanına basit bir POST istek gönderebilir; bu, elbette kullanıcının çerezi bu alan adı için içerir. Döndürülen yanıt temel olarak orijinal etki alanına, kullanıcının kimliğinin doğrulanıp doğrulanmadığını ve gerekirse kimliğinin ne olduğunu söyler.
Kullanıcının kimliği henüz doğrulanmadıysa, şifresini göndermek için kimlik doğrulama alanındaki bir sayfaya yönlendirilir.

Bu kurulumu oldukça basit olsa da, aslında güvenli hale getirme konusunda bazı zorluklar olduğunu unutmayın.
Örneğin, tanımlandığı gibi, herhangi web sitesi kimliğinizi alabilir. Ayrıca, güvenen web sitesi, döndürülen yanıtı değiştirerek "kandırılabilir".
Tabii ki, bu sorunları çözmenin en kolay yolu - tahmin ettiniz - SAML/OpenId/vb.

Yeni kaydoldum, ancak başka bir yerde bir cevap bulamadığınızı şaşırtıcı buluyorum. Daha önce öğrendiğiniz gibi, vekil kullanarak vekil kimlik doğrulama jetonlarını geçiremezsiniz.

Mevcut siteniz için kimlik doğrulamanın nasıl uygulandığı veya siteleri programlamak için kullanabileceğiniz araçlar hakkında herhangi bir ayrıntı sağlamadınız. Ancak, kimlik doğrulama mekanizmasının web sunucusunda çalışan ve oturumu izlemek için bir çerez kullanan bir dilde yazıldığını varsayacağım.

Bu durumda, oturumun kimliğinin doğrulanıp onaylanmadığını kontrol etmek için kimlik doğrulaması gerektiren her URL'de zaten bir kodunuz vardır ve ardından uygun eylemi gerçekleştirin - isteği işleme veya bir giriş sayfasına yönlendirme. Tek yapmanız gereken, kimliği doğrulanmış bir oturumun olmadığı ve URL'ye iletilen şifreli bir değişkenin (yani bir GET olarak) bulunduğu senaryo ile ilgilidir. Değerin şifresini çözer, geçerli olup olmadığını kontrol edersiniz ve bu noktada bir oturum oluşturursunuz. Ardından, giriş sayfanızda, başarılı bir giriş yaptıktan sonra, URL'ye uygun anahtar/değer çiftini ekleyerek yeniden yönlendirirsiniz.

Bu kısa bir genel bakış - düşünmeniz gereken bazı ince ayarlar var (örneğin, aynı oturum verilerinin tüm siteler arasında paylaşılmasını istiyor musunuz, sunucu tarafının süresinin dolmamasını sağlamak için oturumu farklı oturumlar için yeniden hatırlatmak istiyor musunuz) ayrıca tekrar saldırılarını nasıl önlediğinizi de düşünmeniz gerekir (örneğin, rastgele oluşturulan bir sorun da dahil olmak üzere şifrelenmiş yükte bir TTL dahil), ancak istemci IP adresini kullanmaya dikkat edin).

Yalnızca sunucu tarafında şifreleme/şifre çözme yaptığınız için simetrik şifreleme yeterlidir.