一、SSO實現原理

1、概念：SSO的一種偏向技術的說法：使用者只需登陸一次，就可使用多個SSO enable的應用系統。

（1）、單一的登陸點。理想的情況是使用者通過任何應用系統都能進行SSO，這對於基於Web的系統是可行的。這種單一的登陸點在整個系統的設計中是唯一認證使用者的地方，由登陸點將SSO token（針對不同的C/S，B/S應用可能還需要傳遞使用者名稱，口令）傳遞給應用系統，應用系統利用

（2）、SSO enable意味著對應用系統的修改不可避免。並不是任何系統都能夠使用SSO，只有那些符合SSO規範，使用SSO API的應用系統才具有SSO的功能。簡單地說就是要修改已有的應用系統，遮蔽已有的應用系統的使用者認證模組，使用系統提供的SSO API來驗證使用者，以及對使用者的操作進行授權。

（3）、需要統一的認證，許可權資訊庫。通常，認證與授權管理模組以一種應用專有的方式實現，系統的授權模型、認證，授權資訊存貯結構與訪問控制邏輯與應用的業務邏輯之間耦合緊密。這種設計與實現方式的缺點是顯而易見的：由於認證、授權模組與應用邏輯之間的緊耦合使得認證、授權模組很難進行擴充套件與維護；認證、授權模組的設計與編碼需要很大的工作量，而且很難在不同的應用系統之間共享與重用。這也是越來越多企業應用需要

SSO要求有統一的認證，許可權存放庫。但現實中，有的系統無法使用外部的認證，授權資訊庫，所以就需要在應用系統和Portal Server之間進行認證，同時進行授權資訊的資料同步。

2、實現描述：在使用者成功登入 weblogic Portal之後，系統提供的Login Delegate機制來為使用者登入到其有權可以使用的應用系統。系統提供Logout Delegate機制實現使用者的登出功能（即SSO logout）。

使用者存取由Portal SSO保護的若干資源，SSO會話服務（Session/SSO Service）提供了授權的證明，這樣就不再需要使用者重新進行身份驗證了。在這種方式下，即使使用者要訪問不同的域（

同時，SSO還包括的與登入恰恰相反的，統一的登出點，即使用者一旦從Portal登出，則亦當從所有參與Portal SSO的應用登出。此處有一個例外，就是當用戶從Portal登入並轉向一個應用後，經過一段時間後可能會出現使用者的該應用的會話還有效時使用者的Portal會話過期時，此時使用者將只能使用該應用，直到該使用者再次登入Portal。

3、通過SSO Agent：當用戶試圖通過瀏覽器存取受保護的應用資源時，系統提供安裝在不同應用上的SSO Agent來擷取使用者對資源的請求，並檢查請求是否存在會話識別符號，即token。如果token不存在，請求就被傳遞給Portal SSO，在Portal SSO上會話服務負責建立會話token，然後認證服務將提供登陸頁面以驗證使用者。

4、建立會話Token：在使用者身份驗證之前，會話服務就建立了會話token。token為隨機產生的Portal  Server 會話識別符號，該識別符號代表了一個確定使用者的特定會話。建立會話token後，認證服務把token插入cookie中在使用者的瀏覽器中設定cookie。在token被設定的同時，該使用者將會看到一個登陸頁面。

5、使用者認證：使用者收到登陸頁面和會話token後，填入合適的認證資訊。當用戶提交登陸頁面後，這些認證資訊就被髮給認證提供者（authentication provider）（LDAP伺服器，RADIUS伺服器等）進行驗證。一旦認證提供者成功驗證了認證資訊，使用者就被認為是通過了認證。Identity Server會從使用者的token中取出會話資訊並將會話狀態設為有效。此後，使用者就可以訪問這些受保護的資源。

6、cookie和會話token：Cookie是由Web伺服器建立的資訊包，並傳遞給瀏覽器。Cookie 儲存類似使用者習慣等Web伺服器產生的資訊。它本身並不表明使用者通過了認證。Cookie是特定於某個域的。在Identity Server的實現中，cookie由會話服務產生，並由認證服務設定。而且，Identity Server的cookie是會話cookie，儲存在記憶體中。會話token由會話服務建立並插入Cookie。會話token利用安全隨機數發生器產生，幷包含Portal Server特有的會話資訊。在存取受保護的資源之前，使用者由認證服務驗證，並建立SSO token。

二、SSO技術實現

1、SSO entry

SSO entry 作為系統唯一的登陸點將完成如下的功能：

（1）提供使用者身份認證的登陸頁面；（2）根據使用者的許可權，顯示可供使用者使用的應用系統；（3）呼叫使用者選擇的應用系統（B/S或C/S均可）；（4）為應用系統傳遞SSO Token（針對不同的C/S，B/S應用可能還需要傳遞使用者名稱，口令）；（5）關閉SSO；（6）SSO token失效後，關閉SSO entry。

注意SSO entry 並不提供通知應用系統SSO token已失效的功能，這一問題並不大，因為SSO token失效後，SSO entry 已被關閉。使用者只有重新認證，才能獲取新的SSO token。

2、SSO 部署

上面是整個系統的部署的示意圖。白色的立方體表示應用系統。淺藍色的立方體表示Portal SSO平臺。從上圖可以看出：各個應用系統各個應用系統與SSO entry發生聯絡。SSO entry 需要嚮應用系統傳遞SSO Token，使用者名稱，口令；啟動應用系統。

3、SSO實現方式

SSO 的實現方式按照應用系統與Portal Server的互動程度分為三種。需要指出這些SSO的實現方式並沒有優略之分，不同的實現方式適應不同的應用環境。解決現實中遇到的不同問題。真單點登陸：通過SSO entry認證後，應用系統利用SSO API同Portal Server通訊，驗證使用者是否經過認證。新開發的應用系統大多使用這種SSO的實現方式。這種方式需要對應用系統的認證模組進行修改。偽單點登陸：通過SSO entry認證後，應用系統還要自己進行使用者的認證。這種方式適用於那些無法修改認證模組的應用系統。我們應用系統的整合採用該方式進行。整合第三方軟體的單點登陸：Tarantella和Citrix都是將C/S應用系統轉化為Web應用的第三方軟體系統。在某些應用環境下，這類軟體將發揮其作用。這種SSO實現方式在實施中並不使用，列出這種使用方式主要用來展現Identity Server的擴充套件性。

4、SSO的實現

（1）使用者從Portal登入

說明：以上藍色區域為Portal Server上的服務，白色為需要與Portal進行SSO的應用，綠色為每個應用的SSO Entry。代理登入的具體過程：使用者首先登入Portal，Portal處理完登入後，啟動代理登入，為使用者登入應用系統，Portal把使用者轉向到應用系統，應用系統再把使用者在徵管系統的sessionID轉發給Portal，登入代理（Login Delegate）把使用者在徵管系統中的sessionID和使用者id發到徵管系統的SSO Service進行登記，Portal把使用者訪問轉向徵管系統SSOEntry，徵管系統SSOEntry通過使用者的sessionID得到SSOService中記錄的使用者在Portal的使用者userID，並把當前使用者認可為此Portal userID對應的在徵管系統中的使用者，徵管系統把使用者訪問轉回Portal。接著登入代理再對SSO應用列表中的其它應用進行代理登入。代理登入完成，使用者被重定向到Portal的相關頁面。

使用者訪問應用系統：之後，當用戶訪問徵管的某個應用時，徵管系統發現該使用者還未經認證，則將其sessionID與SSOService中登記的uid/sessionID比較，如果存在匹配，則認證通過，將使用者id與session相關聯。之後使用者就可以直接訪問徵管系統了。

（2）SSO單點登出

說明：

（1）使用者登出總是從Portal開始；（2）登出代理（Logout Delegate）將登出訊息發到各應用的SSO Logout Entry；（3）應用的SSO Logout Entry登出本地的使用者會話記錄；（4）登出Portal上的使用者會話記錄。

三、安全性分析

Portal SSO的安全性需要從幾個方面理解：

1.客戶登入Portal Server之後SSO到應用的安全性，即SSOToken的安全性；
2.客戶無SSOToken時，首先訪問應用的安全性；
3.客戶有SSOToken時想通過仿冒別人的有效SSOToken來進行非法的訪問。

Portal Server生成的SSO token 因為需要在應用程式間傳遞，所以SSOToken比較容易被竊取，但Portal Server保證了SSOToken的唯一性，那些盜用合法SSOToken的人無法通過SSOToken的驗證。因為SSOToken的生成收集了使用者端和伺服器端的很多資訊，當非法使用者持有效的SSOToken試圖訪問某應用時，該應用將通過Portal Server的SSOService進行SSOToken驗證時，SSOToken的這些資訊以及Portal Server的安全演算法確保了盜用者即使拿到合法使用者的SSOToken也無法通過SSOToken的有效性驗證。所以SSOToken的安全性也得到了保證。

使用者沒有SSOToken的時候，如果客戶要訪問某應用，如果使用者沒有該應用的會話資訊也沒有Portal的SSOToken，則該使用者必須先通過Portal的認證並SSO到該應用；如果使用者已經在應用登入成功（可能是該應用保留了原有的認證入口，使用者通過該入口訪問此應用，也有可能是使用者從Portal 登入後，通過SSO訪問該應用，經過一段時間後，使用者的Portal SSOToken已經過期，但是使用者在該應用中的會話仍然保持有效），則使用者可以繼續使用該應用系統而無需重新認證。但是如果使用者想訪問Portal或者與Portal進行SSO的其它應用的話，則使用者須經過Portal的認證並拿到SSOToken。所以在這種情況下SSOToken也是安全的。

每個使用者的SSOToken只在其當次會話過程中有效，離開其當次會話，SSOToken即被視作無效，因此這種情況下也是安全的。