ilife's 部落格
sso（single sign-on）直譯為一次登入，使用者只使用乙個使用者名稱和口令，就可以訪問所有的資源，這對系統管理和維護來說是非常重要的。單點登入有效地解決了使用者使用網路時的多帳號、多密碼、多次登入問題，方便了使用者。
sso理論基礎
sso並不是j2ee（或.net）中的標準實現，而是各家中介軟體提供商在提供j2ee（或.net）應用伺服器時提供的一種認證資訊共享的機制，所以各家廠商提供的實現方式不一樣, 在這些系統中，其實現方法方向分為兩種: 一種是建立在pki，kerbose和使用者名稱/口令儲存的基礎上,一種是建立在cookie或session的基礎上。ibm的websphere是通過cookies記錄認證資訊，bea的weblogic通過session共享技術實現認證資訊的共享，國內深圳金蝶的apusic採用的和bea的技術基本一致。在這兩種方式中，各有不足，前者需要安裝專門的客戶端，因而面向的使用者物件是有限的，而後者授權方式只能方便地支援本產品系列的應用，而對第三方的認證和許可權系統不能很方便的整合。
sso的前提條件
1、所有應用系統共享乙個身份認證系統
所有伺服器必須共享使用者登錄檔（使用者資料庫），使用者登錄檔可以是ldap資料庫，也可以採用使用者自己實現的使用者登錄檔。要注意的是在某些情況下是不能使用自己實現的使用者登錄檔的，例如，domino不支援使用者自己實現的使用者登錄檔，所以websphere和domino之間實現sso時只能採用ldap資料庫作為公有的使用者登錄檔。
統一的認證系統是sso的前提之一。認證系統的主要功能是將使用者的登入資訊和使用者資訊庫相比較，對使用者進行登入認證；認證成功後，認證系統應該生成統一的認證標誌（token），返還給使用者。另外，認證系統還應該對token進行效驗，判斷其有效性。
2、所有應用系統能夠識別和提取token資訊
要實現sso的功能，讓使用者只登入一次，就必須讓應用系統能夠識別已經登入過的使用者。應用系統應該能對token進行識別和提取，通過與認證系統的通訊，能自動判斷當前使用者是否登入過，從而完成單點登入的功能。
3、單一的使用者資訊資料庫並不是必須的
有許多系統不能將所有的使用者資訊都集中儲存，應該允許使用者資訊放置在不同的儲存中。事實上，只要統一認證系統，統一token的產生和效驗，無論使用者資訊儲存在什麼地方，都能實現單點登入。
4、統一的認證系統並不是說只有單個的認證伺服器
認證伺服器之間要通過標準的通訊協議，互相交換認證資訊，就能完成更高階別的單點登入。如：當使用者在訪問應用系統1時，由第乙個認證伺服器進行認證後，得到由此伺服器產生的token。當他訪問應用系統2的時候，認證伺服器2能夠識別此token是由第乙個伺服器產生的，通過認證伺服器之間標準的通訊協議（例如saml）來交換認證資訊，仍然能夠完成sso的功能。
5、對應用系統的修改不可避免
並不是任何系統都能夠使用sso，只有那些符合sso規範，使用sso api的應用系統才具有sso的功能。簡單地說就是要修改已有的應用系統（在本專案中，已有的業務系統要實現單點登入，如果步具備相應的條件，則必須進行修改），遮蔽已有的應用系統的使用者認證模組，使用系統提供的sso api來驗證使用者，以及對使用者的操作進行授權。
實現單點登入的兩種方式
sso都要有乙個單一的登入點，由此登入點將建立的會話（認證標誌）token傳遞給應用系統。sso需要建立乙個統一的認證、許可權資訊庫。根據認證、授權實現的位置可以分為兩種實現方式：
1、agent的方式
即在後端為每個web應用系統（或者其他系統）都安裝乙個agent，由agent來接管該系統的身份驗證和訪問控制，目錄伺服器中會存放自己的使用者資訊，以及這些使用者與其他系統的使用者對應資訊。這些agent能夠通過配置，輕鬆的接管了後面的系統的身份驗證和訪問控制。
對於不同的系統，agent不同，這些agent能夠通過配置，輕鬆的接管後面系統的身份驗證和訪問控制。可以通過乙個統一的ldap，存放企業內部的使用者資訊，然後通過策略伺服器，控制後端所有系統的url訪問許可權，這樣也實現了單點登入。
使用這種方式，其安全性較高，使用者資訊都儲存在各系統中，但是這種方式需要在各個系統中都安裝agent，降低了系統的靈活性。
2、proxy的方式
即具有乙個proxy server，由它來接管對於後端系統的訪問，提交請求和讀取資料，然後再返回給呼叫者。同時呼叫者可以存放使用者資訊以及使用者的對應關係。proxy server會通過儲存的使用者對應關係和使用者名稱和密碼，自動完成後端系統的登入，然後就象乙個瀏覽器一樣，提取資料，返回資料給後端系統。後台系統不用做任何修改，身份認證和訪問控制仍然由各個系統自己管理。
該方法的優點是：後端系統不用做任何改動。即便是沒有portal，其他系統還可以照常使用。缺點是：需要在策略伺服器中儲存使用者名稱和密碼，密碼會多處存放，同步困難；使用者可以繞開portal，直接訪問後端系統。proxy server可能是單點故障。缺點解決：目前有密碼同步產品；proxy server也大多支援集群。
由以上兩種方式可以看出，哪種方式的程式設計量都不是很大，大多可以通過配置來實現，而且功能也很強大，可以根據系統實際情況進行選擇。
基於agent方式的單點登入實現流程
在每個web應用系統都安裝乙個agent，由agent來接管該系統的身份驗證和訪問控制的方式實現,如下圖所示.
圖 基於agent方式的單點登入實現過程
1、使用者訪問應用系統。由登入點將sso token（針對不同的c/s，b/s應用可能還需要傳遞使用者名稱，口令）傳遞給應用系統，應用系統利用sso token來進行使用者已認證的驗證。
2、當使用者試圖通過瀏覽器訪問受保護的應用資源時，系統提供安裝在不同應用上的sso agent來擷取使用者對資源的請求，並檢查請求是否存在會話識別符號，即token。如果token不存在，即使用者沒有在自己的伺服器登入，請求就被重定向，傳遞給單點登入伺服器（使用重定向就可以處理各伺服器跨域的情況）。在單點登入伺服器上會話服務負責建立會話token，然後認證服務將提供登陸頁面以驗證使用者。
在使用者身份驗證之前，會話服務建立了會話token。token為隨機產生的會話識別符號，該識別符號代表了乙個確定使用者的特定會話。建立會話token後，認證服務把token插入cookie中，在使用者的瀏覽器中設定cookie。在token被設定的同時，該使用者將會看到乙個登陸頁面。
cookie是由web伺服器建立的資訊包，並傳遞給瀏覽器。cookie 儲存類似使用者習慣等web伺服器產生的資訊。它本身並不表明使用者通過了認證。cookie是特定於某個域的。在身份伺服器的實現中，cookie由會話服務產生，並由認證服務設定。而且，身份伺服器的cookie是會話cookie，儲存在記憶體中。會話token由會話服務建立並插入cookie。會話token利用安全隨機數發生器產生，幷包含系統伺服器特有的會話資訊。在訪問受保護的資源之前，使用者由認證服務驗證，並建立sso token。
3、單點登入伺服器檢查到使用者已經單點登入（如果使用者沒有單點登入則要求使用者登入，登入標誌儲存為客戶端瀏覽器的cookie），找到該使用者在相應應用系統上繫結的賬號。這些認證資訊就被發給認證提供者（authentication provider）（ldap伺服器，radius伺服器等）進行驗證。
4、一旦認證提供者成功驗證了認證資訊，使用者就被認為是通過了認證。身份伺服器會從使用者的token中取出會話資訊並將會話狀態設為有效。單點登入伺服器根據生成的使用者token，重定向回應用系統。此後，使用者就可以訪問這些受保護的資源。
5、應用系統接收統一格式的使用者token，取得使用者在本系統上的登入賬號，將使用者在本系統上狀態置為登入，返回使用者請求訪問的頁面。
如果使用者在訪問應用系統之前已經在單點登入伺服器上登入過，第二步到第四布對使用者來說就是透明的，使用者感覺只是向應用系統發出了訪問請求，然後得到了頁面反饋。
基於proxy方式的單點登入實現流程
基於proxy的實現方案如novel ichain的實現。這種方案需要通過dns將多個系統的網域名稱配置在乙個承擔sso的proxy上。當使用者輸入系統位址開啟頁面時，會首先鏈結到這個proxy，再由proxy**到實際系統。原有系統因為使用者沒有登入，那麼會返回登入頁面，這時候ichain會截獲這個登入頁面，用自己的登入頁面代替。使用者在ichain提供的頁面中輸入使用者名稱和密碼，隨後ichain根據ldap（novel的ldap可以說是這行的老大了）中的資訊查詢出原有系統的使用者名稱和密碼，通過一次http post將使用者賬號傳送給原有系統。
如果使用者開啟新系統頁面，那麼基本不驟不變，只是ichain返回自己登入頁面時，因為在同乙個域中，可以發現該使用者已經登入過，然後就直接http post到新系統而不出現登入頁面。
其實sso只是最簡單的乙個步驟，如何做好多系統之間的賬號同步和授權才是大難題。
單點登入和技術實現機制
單點登入 single sign on 簡稱為 sso，是目前比較流行的企業業務整合的解決方案之一。color red sso的定義是在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。color 技術實現機制 當使用者第一次訪問應用系統1的時候，因為還沒有登入，會被引導到認證系...
NC整合CAS統一認證 單點登入原理
原理及步驟 1 瀏覽器中輸入應用位址 進入nc 伺服器 1處理 如果 uri是 index.jsp 且ticket null 且assertion null 則跳轉到 cas認證頁面。2 cas 登入成功，跳轉回業務系統 index.jsp 頁面。進入nc 伺服器 1處理 此時 ticket nul...
CAS單點登入三 客戶端獲取登入資訊
通過上篇的配置，登入是從資料庫中進行驗證了。那麼現在要解決的問題是，客戶端怎麼知道登入者是誰呢？如何獲取登入者的資訊。首先還是開啟deployerconfigcontext.xml這個配置檔案 找到id為attributerepository的bean。預設這個bean配置的應該是org.jasig...