Aynı etki alanında yaşayan iki sitemiz için tek oturum açma özelliğini ayarladım: a.domain.com ve b.domain.com
Bunu çerezlerle yaptım, ancak alan adına bağımlılar. Ve - Büyük Kitap'ta yazıldığı gibi - şimdi farklı alanlarda tek oturum açma ihtiyacı çirkin başını kaldırdı :)% 99 OpenId kullanmayı unutabileceğime eminim (dış hizmetleri sevmiyorlar) burada, kabul etmelerini bile sağlayamadım reCaptcha )
Birini farklı web sitelerinde (a.domain.com, b.anotherdomain.com vb.) Tanımlamak istiyorum. Birden çok alanda tek oturum açma özelliğini kurmanın/yönetmenin önerilen yolları nelerdir? Bir teklif hazırlamadan önce bilmem gereken özel güvenlik endişeleri var mı?
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:
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.