在稅務行業信息化發展的關鍵階段，應用整合已經非常重要，而應用整合的表現層首先要實現的就是單點登陸（SSO，Single sign-on的縮寫），以下是筆者結合南京地稅進行應用整合中SSO的技術實現
。
南京地稅目前有多種企業應用，包括征管系統、行政系統、輔助決策系統、公文系統、人事系統、電子地圖、郵件系統等等，這些應用主要是采用三層體系結構（IE6.0+weblogic portal7.0 +weblogic server7.0 +oracle9i）來構架。所有的用戶登陸需要通過weblogic portal進行。
我們在系統中使用SSO來實現用戶通過一次認證（authenticate）來存取多個受保護的資源，也就是說，用戶隨后對受保護資源的存取，將不會導致每一次都要用戶提供認證的信息，只需要一次認證即可。
一、SSO實現原理
1、概念：SSO的一種偏向技術的說法：用戶只需登陸一次，就可使用多個SSO enable的應用系統。
（1）、單一的登陸點。理想的情況是用戶通過任何應用系統都能進行SSO，這對于基于Web的系統是可行的。這種單一的登陸點在整個系統的設計中是唯一認證用戶的地方，由登陸點將SSO token（針對不同的C/S，B/S應用可能還需要傳遞用戶名，口令）傳遞給應用系統，應用系統利用SSO token來進行用戶已認證的驗證。我們將這個單一的登陸點稱為SSO Entry。
（2）、SSO enable意味著對應用系統的修改不可避免。并不是任何系統都能夠使用SSO，只有那些符合SSO規范，使用SSO API的應用系統才具有SSO的功能。簡單地說就是要修改已有的應用系統，屏蔽已有的應用系統的用戶認證模塊，使用系統提供的SSO API來驗證用戶，以及對用戶的操作進行授權。
（3）、需要統一的認證，權限信息庫。通常，認證與授權管理模塊以一種應用專有的方式實現，系統的授權模型、認證，授權信息存貯結構與訪問控制邏輯與應用的業務邏輯之間耦合緊密。這種設計與實現方式的缺點是顯而易見的：由于認證、授權模塊與應用邏輯之間的緊耦合使得認證、授權模塊很難進行擴展與維護；認證、授權模塊的設計與編碼需要很大的工作量，而且很難在不同的應用系統之間共享與重用。這也是越來越多企業應用需要SSO的原因之一。
SSO要求有統一的認證，權限存放庫。但現實中，有的系統無法使用外部的認證，授權信息庫，所以就需要在應用系統和Portal Server之間進行認證，同時進行授權信息的數據同步。
2、實現描述：在用戶成功登錄 weblogic Portal之后，系統提供的Login Delegate機制來為用戶登錄到其有權可以使用的應用系統。系統提供Logout Delegate機制實現用戶的注銷功能（即SSO logout）。
用戶存取由Portal SSO保護的若干資源，SSO會話服務（Session/SSO Service）提供了授權的證明，這樣就不再需要用戶重新進行身份驗證了。在這種方式下，即使用戶要訪問不同的域（weblogic domain）的應用，我們提供的Portal 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即被視作無效，因此這種情況下也是安全的。