PERL 和PHP 分別采用不同域名的sever 單點登陸SSO 簡易實現(xiàn)思路

kevin_w_sh

單點登陸SSO 有一些成熟的解決方案,但對于我的項目,僅有兩個sever的系統(tǒng),感覺投入應(yīng)用還是比較復(fù)雜,代碼改動量較多

于是,我自己擬定了如下網(wǎng)頁重定向來保存session的方案并已實施成功,請各位多多指教,有沒有不安全的因素,或者更好的方法來實現(xiàn)

網(wǎng)址1: a.com,全部perl 代碼,A 服務(wù)器,存儲注冊用戶資料
網(wǎng)址2: b.com,全部php 代碼,B 服務(wù)器

用戶可以在a.com 登錄,也可以再b.com 登錄

登錄流程如下:

1 登陸a.com , Perl按照正常的登陸驗證成功之后,生成一個網(wǎng)頁重定向URL 到b.com,這個url,包含user=kevin&timestamp=590404668a4fa55dbbfe533dc9e28cd5

期中timestamp已MD5 加密,同時把未加密的時間戳寫到mysql數(shù)據(jù)庫中

2 用戶的瀏覽器跳轉(zhuǎn)到b.com 之后,通過API 訪問A 服務(wù)器的mysql,根據(jù)傳來的用戶名和時間戳,驗證用戶的合法性,如果時間戳和用戶名都符合,顯示在b.com 登陸成功,保存session

3 網(wǎng)頁重定向,返回 a.com登陸之后的狀態(tài)


如果用戶先登陸b.com ,則相反的流程,但時間戳都是寫在A 數(shù)據(jù)庫


公司CTO 認(rèn)為還不夠安全,讓我再找好的解決方案,我現(xiàn)在迷惑中


求指點

蘭花仙子

a.com與b.com如何能共享cookie? 協(xié)議上就不允許吧。
gmail.com之所以改成mail.google.com，就是共用google.com這個域的cookie。
考慮下第三方認(rèn)證服務(wù)，例如OAuth.

kevin_w_sh

謝版主

1 cookie 并沒有共享

而是在網(wǎng)頁重定向的時候,傳過去一個ticket(user=kevin&timestamp=590404668a4fa55dbbfe533dc9e28cd5)

瀏覽器轉(zhuǎn)到b.com 之后,發(fā)現(xiàn)有這個ticket,會自動校驗這個ticket的合法性(通過api 訪問mysql 看這個唯一的時間戳是否存在)

如果合法,立即寫入b.com的 session,cookie 當(dāng)然也就生效了

2 通過網(wǎng)頁重定向二次(俗稱網(wǎng)頁跳轉(zhuǎn)),連個域名下面分別都單獨生成了成功登陸的cookie 標(biāo)記和session

蘭花仙子

考慮統(tǒng)一認(rèn)證機制比較好。避免a.com搞一套用戶系統(tǒng)，b.com搞一套用戶系統(tǒng)。
用user@domain.com這樣來區(qū)別唯一用戶。
例如user@a.com是唯一用戶，user@b.com也是唯一用戶，由用戶中心來統(tǒng)一認(rèn)證和授權(quán)。
網(wǎng)易的多個域就是這么做的。

kevin_w_sh

蘭花仙子 發(fā)表于 2012-05-31 21:44
考慮統(tǒng)一認(rèn)證機制比較好。避免a.com搞一套用戶系統(tǒng)，b.com搞一套用戶系統(tǒng)。
用這樣來區(qū)別唯一用戶。
例如 ...

en
現(xiàn)在數(shù)據(jù)庫是統(tǒng)一的,都在A sever 上

B sever 沒有用戶資料庫

用戶名由于歷史原因,不是emal 方式,這就很難去改了

py

樓主還是應(yīng)該用成熟的方案。
你所做的最多是個workaround的辦法，這就是為什么你公司CTO認(rèn)為不安全。
我第一個想到的也是OAuth，但OAuth主要還是授權(quán)，如果你的目的是授權(quán)，那用OAuth是很合適的。但如果你這是想單點登錄，用LDAP就好了。
這些辦法是成熟的標(biāo)準(zhǔn)化的，而且有更好的擴展性。

蘭花仙子

kevin_w_sh 發(fā)表于 2012-05-31 23:42
en
現(xiàn)在數(shù)據(jù)庫是統(tǒng)一的,都在A sever 上

如果非得說安全，你這個方案是有安全問題，而且問題很大。
比如有張三、李四兩個人坐一起，張三看到旁邊的李四登陸了a.com，然后他趕緊構(gòu)造一個請求，用李四的ID去登陸b.com，按照你的邏輯，也是可以成功的。

kevin_w_sh

蘭花仙子 發(fā)表于 2012-06-01 09:25
如果非得說安全，你這個方案是有安全問題，而且問題很大。
比如有張三、李四兩個人坐一起，張三看到旁 ...

這個理論上有,但概率非常的低,可以忽略不計,可能CTO 考慮的是其它原因?



1 生成的時間戳ticket經(jīng)過MD5加密了,字符串32位太長,坐在身邊的人無法肉眼來去構(gòu)造,而且網(wǎng)頁跳轉(zhuǎn)很快,即使想復(fù)制也麻煩




2 坐在身邊的一般是同事或朋友,除非電腦被黑,電腦操作權(quán)給了別人,那什么加密方式都一樣的

qinyudd

我鎖定一個用戶名，不停以某用戶的身份遞交一個包含當(dāng)前timestamp的MD5加密的請求，那么只要這期間這個用戶跳轉(zhuǎn)一次，我就可以順利的偽造成功了。。這可不是一點點的不安全

yakczh_cu

點擊登陸后象某個中心（ldap或者memcache)檢驗一下用戶名和密碼的正確性，如果正確就寫個cookie輸出P3P的頭　比如　P3P: CP=" OTI DSP COR IVA OUR IND COM "