來源：http://blog.chinaunix.net/u1/52224/showart_412714.html

?

在http://blog.chinaunix.net/u1/52224/showart_410119.html 中講到系統的權限控制模型，當時按照最小依賴和最大重用把web 系 統權限控制劃分成了業務邏輯、權限管理、權限驗證、登陸代理、登陸服務、用戶管理、業務邏輯數據庫、業務權限數據庫和用戶數據庫幾個部分，現在開始逐一實 現以上除業務邏輯的部分，今天發布的是單點登陸系統，也就是登陸代理和登陸服務。

基于COOKIE 的單點登陸

????? 單點登陸就是只需要在 訪問第一個業務邏輯時輸入用戶驗證信息，以后訪問其他業務邏輯不需要再次輸入用戶驗證信息，而不管業務邏輯的部署方式。 ????? 要實現單點登陸，其實 就是要讓系統有記憶功能，能記住用戶以前登陸過，下次登陸時就不再需要用戶輸入身份驗證信息，就像有的論壇會讓用戶選擇記住用戶登陸狀態，并且可以選擇一 個過期時間，這樣在過期時間之內用戶訪問這個論壇，論壇會標記用戶為已登陸狀態。 ????? COOKIE 是實現系 統記憶功能的很好的工具，COOKIE 有兩種，一種成為內存COOKIE ，這種COOKIE 在 用戶關閉瀏覽器時失效，另外一種為文件COOKIE ，可以保存在用戶的電腦系 統中，并且可以設置一個過期時間，在過期時間內該COOKIE 都有效。COOKIE 的另一個特性是域，概念等同于JAVA 的包，當瀏覽器訪問某個鏈接時，會把這個鏈接的域跟所有存在的COOKIE 的域進行對比，域匹配的COOKIE 將 被自動發送到WEB 服務器。 ????? 根據COOKIE 的生存周期和域特性，可以在登陸服務里面設置一個COOKIE ，這個COOKIE 用 來標志用戶是否已經登陸，COOKIE 可以選擇內存COOKIE 或者文件COOKIE ， 因為COOKIE 是域相關的，所以只有登陸服務可以看到這個COOKIE 。由于用戶訪問業務邏輯時，如果登陸代理找不到用戶憑證，就會去登陸服務那里 登陸，這時登陸服務的策略為如果找不到這個COOKIE ，那么提示用戶輸入用 戶驗證信息驗證，如果找到這個COOKIE ，那么直接告訴登陸代理已經登陸。 ????? 流程圖如下： ????? 用戶訪問某業務邏輯， 業務邏輯向登陸代理獲取用戶憑證。 登陸代理首先在SESSION 中查 找用戶憑證，如果用戶憑證存在，表明用戶已經登陸過，返回用戶憑證給業務邏輯，如果用戶憑證不存在，則向登陸服務請求登陸。 登陸服務首先COOKIE 中查找用 戶憑證，如果用戶憑證存在，表明用戶已經登陸過，返回用戶憑證給登陸代理，如果不存在，則轉向登陸頁面要求用戶輸入用戶驗證信息，然后驗證用戶登陸信息， 驗證通過后設置COOKIE 以備下次登陸請求使用。 登陸代理接收到登陸服務的返回后，解析出用戶憑證，保存該用戶憑證到SESSION 以備以后使用，然后返回該用戶憑證給業務邏輯。 業務邏輯接收到登陸代理的用戶憑證后，驗證權限，驗證通過處理業務邏輯相關功能。 ????? 上面的文字解釋可能有 點暈，看流程圖應該比較清楚，文字解釋可能只是畫蛇添足。 ????? 如果把業務邏輯和登陸 代理等中間過程透明化，只保留用戶和登陸服務，那么登陸過程就非常清晰，其實就是用戶訪問登陸服務的過程，因為登陸服務只有一個，所以對指定的用戶來說， 一旦用戶登陸過，那么COOKIE 就存在，所以用戶下次再訪問登陸服務，那么 就不再需要輸入用戶名密碼等用戶驗證信息了。 ????? 這里可能有一個疑惑， 就是登陸代理為什么要把用戶憑證保存到SESSION ？這是為了提高效率，如 果登陸代理不保存用戶憑證，那么每次業務邏輯要查詢用戶憑證時，登陸代理都要轉向登陸服務去查詢，因為業務邏輯可能和登陸服務不是部署在一個地方，那么登 陸代理向登陸服務查詢用戶憑證的過程需要很長的等待時間，用戶感覺就是系統反應遲鈍。當然，也可以把用戶憑證保存在業務邏輯里，但是這樣業務邏輯就做了本 來不屬于他的事情，所以保存在登陸代理里比較合理。因為登陸代理和業務邏輯是部署在一個WEB 應 用程序里，所以使用登陸代理的SESSION 保存用戶憑證，可以保證在業務邏 輯的生存期內，用戶憑證一直有效。

COOKIE 安全性

????? COOKIE 在登陸服 務中用來保存用戶憑證，在登陸代理中用來保存SESSION 。 ????? 假設用戶A 是正常用戶，通過登陸服務進行了登陸，用戶憑證被COOKIE 記錄下來，假設這時黑客B 截 獲了A 的用戶憑證，那么當B 連接到登陸服務驗證時，B 可以把截獲的用戶憑 證附加到COOKIE 中，因為登陸服務通過COOKIE 來判斷登陸狀態，所以登陸服務會認為B 以前登陸過，并且告訴登陸代理B 的用 戶憑證，這樣B 就欺騙了登陸服務而擁有了用戶A 的操作權限。 ????? 首先應該避免用戶憑證 的COOKIE 泄露，在用戶端，因為內存COOKIE 比文件COOKIE 更難 被截取，特別是經過特殊處理的瀏覽器，要截取內存COOKIE 幾乎不可能，而 且當瀏覽器關閉時，內存COOKIE 失效，所以應該使用內存COOKIE 而非文件COOKIE ， 這也是很多使用文件COOKIE 的論壇帳號經常被盜的原因。 ????? 其次，為進一步減少風 險，不應該在COOKIE 中直接保存用戶憑證，而是使用一個無意義的標識符如UUID 來表示，而登陸服務可以通過這個UUID 查找到真正的用戶憑證，這個標志符隨機生成，即使同一用戶登陸，得到的UUID 也不一樣，所以不能重復使用，這樣即使偶爾泄露一次，也不會造成長期影響。為了提高COOKIE 的截取難度，可以設置一個有效時間，只有在有效期內的COOKIE 是合法的，超過有效期的COOKIE 將被忽略，使用超過有效期的用戶依然需要重新輸入驗證信息。這樣也帶來一個不便的地方，就是用戶如果兩次業務邏 輯之間的切換時間超過了COOKIE 的有效期，那么用戶還得重新輸入驗證信 息，達不到單點登陸的效果，所以如何取舍，要根據業務邏輯而定。 其次因為http 使用明文傳輸，通 過網絡偵聽的方式很容易獲取COOKIE ，所以用戶到登陸服務間的連接應該采 用https 。 ????? 然后考察登陸代理中使 用COOKIE 來保存SESSION 的情況，這是大多數Web 應用服 務器采用的方法。這種情況類似登陸服務使用COOKIE 來保存用戶憑證，典型 的欺騙是黑客B 截獲了正常用戶A 的SESSION COOKIE ，然后B 訪問業務邏輯時附帶這個COOKIE ，Web 應用服務器會認為B 就 是A ，于是A 能 得到的用戶憑證，B 也能得到，B 就成了A 的影子，與A 具有相同的操作權限。所以關鍵問題還是如何避免SESSION COOKIE 的泄露，因為這個COOKIE 由Web 應用服務器控制，所以除了在網絡傳輸時使用https ，基本上沒有其他辦法可以降低風險。除了使用COOKIE 作 為SESSION 標記，很多Web 應用服務器也支持隱式域的方式，就是Web 應 用服務器在頁面自動創建一個隱藏的表單項作為SESSION 標記，頁面提交時 該表單自動被提交，Web 應用服務器通過這個表單項來確定用戶SESSION 。這個是更不安全的做法，因為很多很簡單的方法就可以獲取頁面表單項的數 據，比獲取內存COOKIE 容易很多。

消息傳遞安全性

????? 業務邏輯、登陸代理、 登陸服務間存在消息傳遞，業務邏輯和登陸代理部署在一個Web 應用服務器中， 消息傳遞比較安全。登陸代理和登陸服務通常處在不同的Web 應用服務器中，并 且通常在地域上也不一致，登陸代理和登陸服務間的安全隱患除了消息泄露，還有相互信任的問題。 ????? 首先是消息泄露，使用https 可以避免消息泄露。 ????? 其次是登陸代理和登陸 服務間如何相互信任，這就需要安全證書。關于證書的更多信息參考 http://en.wikipedia.org/wiki/Certificate_authority ，也可以去google 搜索。證書的原理是基于非對稱加 密和數字摘要，非對稱加密由一對密鑰(p, s) 組成，使用p 加密的數據只能使用s 解 密，使用s 加密的數據只能使用p 解密，著名的非對稱加密算法是RSA ，數字摘 要通過一個不可逆運算可以把數據a 變成數據b ，b 通常數 據長度固定并且很小，而且不能用過b 反運算得到a ，常用的數字摘要算法有MD5 和SHA1 。 ????? 制作證書時，首先將證 書信息i 使用數字摘要算法如SHA1 進行運算得到s ，s = SHA1(i) ，然后把i 和s 使用非對稱加密算法如RSA 的s 加 密得到證書c ，c = RSA(s, i+s) 。獲取證書信息剛好是一個逆過程，i+s = RSA(p, c) ，然后把i 和s 分離，并且比較s 和SHA1(i) 是否一致，如果一致，則這個證書信息是可信賴的。 ????? 證書通常由權威機構制 作，這個機構妥善保管s ，公布p ，那么互不相識的A 和B 通信，A 要 核對B 的身份，A 要 求B 的證書，然后核對解密后的證書信息就可以了。 ????? 同樣登陸代理和登陸服 務在傳遞信息時也要核對身份，否則黑客可以將登陸代理引導到假冒的登陸服務，或者傳遞給登陸代理預先設定的用戶憑證，進行認證欺騙。使用證書后，登陸代理 請求登陸服務進行登陸時，首先核對登陸服務的證書，登陸代理處理登陸服務返回的用戶憑證時，也核對登陸服務的證書，雙方信息傳遞在https 中進行，所以存在消息篡改和泄漏，保證登陸服務是可信賴的。登陸服務的證書必須 妥善保管，并且定期更換。 ????? 也可以根據證書原理自 定義處理過程，登陸代理和登陸服務各自掌握p 和s ，證書代理發送消息使用p 加 密，接收消息使用p 解密，登陸服務接收消息使用s 解密，發送消息使用s 加 密，消息附帶SHA1 數字摘要，這樣登陸代理和登陸服務也可相互信任。這種方 案下，可以不使用https ，因為消息已經被加密。但是這樣有一個漏洞，就是 會被重播，比如黑客可以截獲登陸服務發送給登陸代理的整個加密的消息，然后完整地發送給登陸代理，這樣登陸代理不能識別究竟真偽而被欺騙。可以在消息里面 附加隨機數據來解決這個漏洞，登陸代理發送消息前，先隨機產生一段數據，并附加到消息中，然后加密發送給登陸服務，登陸服務發送消息給登陸代理時也附帶這 個數據，登陸代理核對這個數據來確定有效性，每次登陸代理和登陸服務傳輸的數據都不一樣，重播不再有效。

安裝部署

我用的版本是Tomcat5523+MySQL5037+jre1.5.0_12 ， 沒在其他版本下測試過。 1. 下載cglib 最新版本 http://cglib.sourceforge.net/ ，拷貝asm.jar 和cglib-2.1.3.jar 到Tomcat/shared/lib 。 2. 下載c3p0 最新版本 http://sourceforge.net/projects/c3p0 ，拷貝c3p0-0.9.1.1.jar 到Tomcat/shared/lib 。 3. 下載mysql-connector 最新版本 http://sourceforge.net/projects/mmmysql/ ，拷貝mysql-connector-java-5.0.4-bin.jar 到Tomcat/shared/lib 。 4. 下載profile.v1.MySQL5.sql.rar解壓縮為 profile.v1.MySQL5.sql ，導入到MySQL 數 據庫中。 ? 創建用戶，用戶名root，密碼1

insert into T_PROFILE( USER_NAME, USER_PASSWORD) values ( 'root' , sha1( '1' ) ) ;

5. 下載sso.rar解壓縮為sso.war ，這個是登陸服務，復制到Tomcat/webapps ，下載ssoagent.rar解壓縮為ssoagent.war ，這個是登陸代理，里面附帶簡單的業務邏輯，復制到Tomcat/webapps ，啟動tomcat ，這時Tomcat/webapps 下 面生成sso 和ssoagent 兩 個目錄，分別對應登陸服務和登陸代理，停止tomcat 。 6. 找到Tomcat/webapps/sso/WEB-INF/classes/sso_passport.properties ????? # 修改為你的實際的/sso/passport/authen.jsp 的路徑。 ????? sso.passport.authenUrl =http://bsmith-cn:8080/sso/passport/authen.jsp ????? # 修改為你的實際的profile 數據庫的url ????? sso.passport.db.ds.c3p0.url =jdbc:mysql://localhost/profile ????? # 修改為你的實際的profile 數據庫用戶名 ????? sso.passport.db.ds.c3p0.user =root ????? # 修改為你的實際的profile 數據庫密碼 ????? sso.passport.db.ds.c3p0.password =1 7.? 找到Tomcat/webapps/ssoagent/WEB-INF/classes/sso_agent.properties ????? # 修改為你的實際的/sso/passport/login.srv 路徑 ????? sso.passport.login =http://bsmith-cn:8080/sso/passport/login.srv ????? # 修改為你的實際的/sso/passport/logout.srv 路徑 ????? sso.passport.logout =http://bsmith-cn:8080/sso/passport/logout.srv 8. 啟動Tomcat ，輸入 http://yourhost:yourport/ssoagent/logic/index.jsp 測試，如果配置成功，將看到測試頁面的幾個業務邏輯，業務邏輯本身什么也不干，只是驗證登陸有效性，有的業務邏輯需要登陸才能訪問， 有的不需要登陸就能訪問。

文件: sso.rar 大小: 30KB 下載: 下 載

文件: ssoagent.rar 大小: 21KB 下載: 下 載

文件: profile.v1.MySQL5.sql.rar 大小: 0KB 下載: 下 載

文件: sso.passport.src.v1.jar.rar 大小: 56KB 下載: 下 載

文件: ssoagent.src.v1.jar.rar 大小: 36KB 下載: 下 載

總結

以上是生活随笔為你收集整理的J2EE-单点登陆的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。