Java--實現單點登入
1 什麼是單點登陸
單點登入(Single Sign On),簡稱為 SSO,是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中,使用者只需要登入一次就可以訪問所有相互信任的應用系統。
較大的企業內部,一般都有很多的業務支援系統為其提供相應的管理和IT服務。例如財務系統為財務人員提供財務的管理、計算和報表格服務;人事系統為人事部門提供全公司人員的維護服務;各種業務系統為公司內部不同的業務提供不同的服務等等。這些系統的目的都是讓電腦來進行複雜繁瑣的計算工作,來替代人力的手工勞動,提高工作效率和品質。這些不同的系統往往是在不同的時期建設起來的,運行在不同的平台上;也許是由不同廠商開發,使用了各種不同的技術和標準。如果舉例說國內一著名的IT公司(名字隱去),內部共有60多個業務系統,這些系統包括兩個不同版本的SAP的ERP系統,12個不同類型和版本的資料庫系統,8個不同類型和版本的作業系統,以及使用了3種不同的防火牆技術,還有數十種互相不能相容的協議和標準,你相信嗎。不要懷疑,這種情況其實非常普遍。每一個應用系統在運行了數年以後,都會成為不可替換的企業IT架構的一部分,如下圖所示。
隨著企業的發展,業務系統的數量在不斷的增加,老的系統卻不能輕易的替換,這會帶來很多的開銷。其一是管理上的開銷,需要維護的系統越來越多。很多系統的資料是相互冗餘和重複的,資料的不一致性會給管理工作帶來很大的壓力。業務和業務之間的相關性也越來越大,例如公司的計費系統和財務系統,財務系統和人事系統之間都不可避免的有著密切的關係。
為了降低管理的消耗,最大限度的重用已有投資的系統,很多企業都在進行著公司專屬應用程式整合(EAI)。公司專屬應用程式整合可以在不同層面上進行:例如在資料存放區層面上的“資料大集中”,在傳輸層面上的“通用資料交換平台”,在應用程式層面上的“商務程序整合”,和使用者介面上的“通用企業門戶”等等。事實上,還用一個層面上的整合變得越來越重要,那就是“身份認證”的整合,也就是“單點登入”。
通常來說,每個單獨的系統都會有自己的安全體系和身份認證系統。整合以前,進入每個系統都需要進行登入,這樣的局面不僅給管理上帶來了很大的困難,在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計資料:
1.使用者每天平均 16 分鐘花在身分識別驗證任務上 - 資料來源: IDS
2.頻繁的 IT 使用者平均有 21 個密碼 - 資料來源: NTA Monitor Password Survey
3.49% 的人寫下了其密碼,而 67% 的人很少改變它們
4.每 79 秒出現一起身份被竊事件 - 資料來源:National Small Business Travel Assoc
5.全球欺騙損失每年約 12B - 資料來源:Comm Fraud Control Assoc
6.到 2007 年,身份管理市場將成倍增長至 $4.5B - 資料來源:IDS
使用“單點登入”整合後,只需要登入一次就可以進入多個系統,而不需要重新登入,這不僅僅帶來了更好的使用者體驗,更重要的是降低了安全的風險和管理的消耗。請看下面的統計資料:
1.提高 IT 效率:對於每 1000 個受管使用者,每使用者可節省$70K
2.協助台呼叫減少至少1/3,對於 10K 員工的公司,每年可以節省每使用者 $75,或者合計 $648K
3.生產力提高:每個新員工可節省 $1K,每個老員工可節省 $350 �資料來源:Giga
4.ROI 回報:7.5 到 13 個月 �資料來源:Gartner
另外,使用“單點登入”還是SOA時代的需求之一。在面向服務的架構中,服務和服務之間,程式和程式之間的通訊大量存在,服務之間的安全認證是SOA應用的痛點之一,應此建立“單點登入”的系統體系能夠大大簡化SOA的安全問題,提高服務之間的合作效率。
2 單點登陸的技術實現機制
隨著SSO技術的流行,SSO的產品也是滿天飛揚。所有著名的軟體廠商都提供了相應的解決方案。在這裡我並不想介紹自己公司(Sun Microsystems)的產品,而是對SSO技術本身進行解析,並且提供自己開發這一類產品的方法和簡單示範。頤和園是北京著名的旅遊景點,也是我常去的地方。在頤和園內部有許多獨立的景點,例如“蘇州街”、“佛香閣”和“德和園”,都可以在各個景點門口單獨買票。很多遊客需要遊玩所有德景點,這種買票方式很不方便,需要在每個景點門口排隊買票,錢包拿進拿出的,容易丟失,很不安全。於是絕大多數遊客選擇在大門口買一張通票(也叫套票),就可以玩遍所有的景點而不需要重新再買票。他們只需要在每個景點門口出示一下剛才買的套票就能夠被允許進入每個獨立的景點。
單點登入的機制也一樣,如下圖所示,當使用者第一次訪問應用系統1的時候,因為還沒有登入,會被引導到認證系統中進行登入(1);根據使用者提供的登入資訊,認證系統進行身份效驗,如果通過效驗,應該返回給使用者一個認證的憑據--ticket(2);使用者再訪問別的應用的時候(3,5)就會將這個ticket帶上,作為自己認證的憑據,應用系統接受到請求之後會把ticket送到認證系統進行效驗,檢查ticket的合法性(4,6)。如果通過效驗,使用者就可以在不用再次登入的情況下訪問應用系統2和應用系統3了。
從上面的視圖可以看出,要實現SSO,需要以下主要的功能:
1.所有應用系統共用一個身份認證系統。
統一的認證系統是SSO的前提之一。認證系統的主要功能是將使用者的登入資訊和使用者資訊庫相比較,對使用者進行登入認證;認證成功後,認證系統應該產生統一的認證標誌(ticket),返還給使用者。另外,認證系統還應該對ticket進行效驗,判斷其有效性。
2.所有應用系統能夠識別和提取ticket資訊
要實現SSO的功能,讓使用者只登入一次,就必須讓應用系統能夠識別已經登入過的使用者。應用系統應該能對ticket進行識別和提取,通過與認證系統的通訊,能自動判斷目前使用者是否登入過,從而完成單點登入的功能。
上面的功能只是一個非常簡單的SSO架構,在現實情況下的SSO有著更加複雜的結構。有兩點需要指出的是:
1.單一的使用者資訊資料庫並不是必須的,有許多系統不能將所有的使用者資訊都集中儲存,應該允許使用者資訊放置在不同的儲存中,如下圖所示。事實上,只要統一認證系統,統一ticket的產生和效驗,無論使用者資訊儲存在什麼地方,都能實現單點登入。
2.統一的認證系統並不是說只有單個的證明伺服器,如下圖所示,整個系統可以存在兩個以上的證明伺服器,這些伺服器甚至可以是不同的產品。證明伺服器之間要通過標準的通訊協議,互相交換認證資訊,就能完成更進階別的單點登入。如下圖,當使用者在訪問應用系統1時,由第一個證明伺服器進行認證後,得到由此伺服器產生的ticket。當他訪問應用系統4的時候,證明伺服器2能夠識別此ticket是由第一個伺服器產生的,通過證明伺服器之間標準的通訊協議(例如SAML)來交換認證資訊,仍然能夠完成SSO的功能。
3 WEB-SSO的實現
隨著互連網的高速發展,WEB應用幾乎統治了絕大部分的軟體應用系統,因此WEB-SSO是SSO應用當中最為流行。WEB-SSO有其自身的特點和優勢,實現起來比較簡單易用。很多商業軟體和開源軟體都有對WEB-SSO的實現。其中值得一提的是OpenSSO (https://opensso.dev.java.net),為用Java實現WEB-SSO提供架構指南和服務指南,為使用者自己來實現WEB-SSO提供了理論的依據和實現的方法。
為什麼說WEB-SSO比較容易實現呢。這是有WEB應用自身的特點決定的。
眾所周知,Web協議(也就是HTTP)是一個無狀態的協議。一個Web應用由很多個Web頁面組成,每個頁面都有唯一的URL來定義。使用者在瀏覽器的地址欄輸入頁面的URL,瀏覽器就會向Web Server去發送請求。如下圖,瀏覽器向Web伺服器發送了兩個請求,申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP串連。所謂無狀態的協議也就是表現在這裡,瀏覽器和Web伺服器會在第一個請求完成以後關閉串連通道,在第二個請求的時候重建立立串連。Web伺服器並不區分哪個請求來自哪個用戶端,對所有的請求都一視同仁,都是單獨的串連。這樣的方式大大區別於傳統的(Client/Server)C/S結構,在那樣的應用中,用戶端和伺服器端會建立一個長時間的專用的串連通道。正是因為有了無狀態的特性,每個串連資源能夠很快被其他用戶端所重用,一台Web伺服器才能夠同時服務於成千上萬的用戶端。
但是我們通常的應用是有狀態的。先不用提不同應用之間的SSO,在同一個應用中也需要儲存使用者的登入身份資訊。例如使用者在訪問頁面1的時候進行了登入,但是剛才也提到,用戶端的每個請求都是單獨的串連,當客戶再次訪問頁面2的時候,如何才能告訴Web伺服器,客戶剛才已經登入過了呢。瀏覽器和伺服器之間有約定:通過使用cookie技術來維護應用的狀態。Cookie是可以被Web伺服器設定的字串,並且可以儲存在瀏覽器中。如下圖所示,當瀏覽器訪問了頁面1時,web伺服器設定了一個cookie,並將這個cookie和頁面1一起返回給瀏覽器,瀏覽器接到cookie之後,就會儲存起來,在它訪問頁面2的時候會把這個cookie也帶上,Web伺服器接到請求時也能讀出cookie的值,根據cookie值的內容就可以判斷和恢複一些使用者的資訊狀態。
Web-SSO完全可以利用Cookie結束來完成使用者登入資訊的儲存,將瀏覽器中的Cookie和上文中的Ticket結合起來,完成SSO的功能。
為了完成一個簡單的SSO的功能,需要兩個部分的合作:
統一的身份認證服務。
修改Web應用,使得每個應用都通過這個統一的認證服務來進行身份效驗。
web.xml部署於/App/WEB-INF下
應用部分
1.在你的登入驗證時,調用SessionListener.isAlreadyEnter(session, "admin ")
既可以判斷該使用者名稱的使用者是否登入過,又可以使上次登入的使用者掉線
2.其他頁面調用SessionListener.isOnline(session),可以判斷該使用者是否線上.
轉自:http://blog.csdn.net/java_freshman01/article/details/7202776
採用SSH架構加以說明:
1. 建立一個登入管理類LoginManager
2. 在LoginManager中定義一個集合,管理登入的使用者。
3. 在Spring中將LoginManager配置成單例
4. 如果使用自訂的使用者管理類,則為了說明方便,將此類命名為UserContext(表示使用者授權的上下文)
5. 如果未使用自訂的使用者管理類,則直接使用Session。
6. 在登入授權對象中,檢查使用者是否是合法使用者,如果是合法使用者,則在LoginManager的集合中尋找使用者是否已經線上,如果不線上,則將使用者加入集合。
7. 處理策略一:如果使用者已經線上,則取新登入使用者的Session,將它失效,則能阻止新登入使用者登入。
8. 處理策略二:如果使用者已經線上,則取出線上使用者的Session,將它失效,再把新登入使用者加入LoginManager的集合。則先登入使用者不能執行有許可權的操作,只能重新登入。
1. applicationContext.xml
2. LoginManager.java
3. LoginAction.java
4. 如果自訂了UserContext,則可將集合改成Collection<UserContext> users;
5. UserContext.java