Java--實現單點登陸

什麼是單點登錄java

單點登陸(Single Sign On),簡稱爲 SSO,是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中,用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。
較大的企業內部,通常都有不少的業務支持系統爲其提供相應的管理和IT服務。例如財務系統爲財務人員提供財務的管理、計算和報表服務;人事系統爲人事部門提供全公司人員的維護服務;各類業務系統爲公司內部不一樣的業務提供不一樣的服務等等。這些系統的目的都是讓計算機來進行復雜繁瑣的計算工做,來替代人力的手工勞動,提升工做效率和質量。這些不一樣的系統每每是在不一樣的時期建設起來的,運行在不一樣的平臺上;也許是由不一樣廠商開發,使用了各類不一樣的技術和標準。若是舉例說國內一著名的IT公司(名字隱去),內部共有60多個業務系統,這些系統包括兩個不一樣版本的SAP的ERP系統,12個不一樣類型和版本的數據庫系統,8個不一樣類型和版本的操做系統,以及使用了3種不一樣的防火牆技術,還有數十種互相不能兼容的協議和標準,你相信嗎?不要懷疑,這種狀況其實很是廣泛。每個應用系統在運行了數年之後,都會成爲不可替換的企業IT架構的一部分,以下圖所示。
隨着企業的發展,業務系統的數量在不斷的增長,老的系統卻不能輕易的替換,這會帶來不少的開銷。其一是管理上的開銷,須要維護的系統愈來愈多。不少系統的數據是相互冗餘和重複的,數據的不一致性會給管理工做帶來很大的壓力。業務和業務之間的相關性也愈來愈大,例如公司的計費系統和財務系統,財務系統和人事系統之間都不可避免的有着密切的關係。
爲了下降管理的消耗,最大限度的重用已有投資的系統,不少企業都在進行着企業應用集成(EAI)。企業應用集成能夠在不一樣層面上進行:例如在數據存儲層面上的「數據大集中」,在傳輸層面上的「通用數據交換平臺」,在應用層面上的「業務流程整合」,和用戶界面上的「通用企業門戶」等等。事實上,還用一個層面上的集成變得愈來愈重要,那就是「身份認證」的整合,也就是「單點登陸」。
一般來講,每一個單獨的系統都會有本身的安全體系和身份認證系統。整合之前,進入每一個系統都須要進行登陸,這樣的局面不只給管理上帶來了很大的困難,在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計數據:
  • 用戶天天平均 16 分鐘花在身份驗證任務上 資料來源: IDS
  • 頻繁的 IT 用戶平均有 21 個密碼 資料來源: NTA Monitor Password Survey
  • 49% 的人寫下了其密碼,而 67% 的人不多改變它們
  • 每 79 秒出現一塊兒身份被竊事件 資料來源:National Small Business Travel Assoc
  • 全球欺騙損失每一年約 12B - 資料來源:Comm Fraud Control Assoc
  • 到 2007 年,身份管理市場將成倍增加至 $4.5B - 資料來源:IDS
 
使用「單點登陸」整合後,只須要登陸一次就能夠進入多個系統,而不須要從新登陸,這不只僅帶來了更好的用戶體驗,更重要的是下降了安全的風險和管理的消耗。請看下面的統計數據:
  • 提升 IT 效率:對於每 1000 個受管用戶,每用戶可節省$70K
  • 幫助臺呼叫減小至少1/3,對於 10K 員工的公司,每一年能夠節省每用戶 $75,或者合計 $648K
  • 生產力提升:每一個新員工可節省 $1K,每一個老員工可節省 $350 資料來源:Giga
  • ROI 回報:7.5 到 13 個月 �資料來源:Gartner
 
另外,使用「單點登陸」仍是SOA時代的需求之一。在面向服務的架構中,服務和服務之間,程序和程序之間的通信大量存在,服務之間的安全認證是SOA應用的難點之一,應此創建「單點登陸」的系統體系可以大大簡化SOA的安全問題,提升服務之間的合做效率。
單點登錄的技術實現機制
隨着SSO技術的流行,SSO的產品也是滿天飛揚。全部著名的軟件廠商都提供了相應的解決方案。在這裏我並不想介紹本身公司(Sun Microsystems)的產品,而是對SSO技術自己進行解析,而且提供本身開發這一類產品的方法和簡單演示。頤和園是北京著名的旅遊景點,也是我常去的地方。在頤和園內部有許多獨立的景點,例如「蘇州街」、「佛香閣」和「德和園」,均可以在各個景點門口單獨買票。不少遊客須要遊玩全部德景點,這種買票方式很不方便,須要在每一個景點門口排隊買票,錢包拿進拿出的,容易丟失,很不安全。因而絕大多數遊客選擇在大門口買一張通票(也叫套票),就能夠玩遍全部的景點而不須要從新再買票。他們只須要在每一個景點門口出示一下剛纔買的套票就可以被容許進入每一個獨立的景點。
單點登陸的機制也同樣,以下圖所示,當用戶第一次訪問應用系統1的時候,由於尚未登陸,會被引導到認證系統中進行登陸(1);根據用戶提供的登陸信息,認證系統進行身份效驗,若是經過效驗,應該返回給用戶一個認證的憑據--ticket(2);用戶再訪問別的應用的時候(3,5)就會將這個ticket帶上,做爲本身認證的憑據,應用系統接受到請求以後會把ticket送到認證系統進行效驗,檢查ticket的合法性(4,6)。若是經過效驗,用戶就能夠在不用再次登陸的狀況下訪問應用系統2和應用系統3了。
從上面的視圖能夠看出,要實現SSO,須要如下主要的功能:
  • 全部應用系統共享一個身份認證系統。
    統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登陸信息和用戶信息庫相比較,對用戶進行登陸認證;認證成功後,認證系統應該生成統一的認證標誌(ticket),返還給用戶。另外,認證系統還應該對ticket進行效驗,判斷其有效性。
  • 全部應用系統可以識別和提取ticket信息
    要實現SSO的功能,讓用戶只登陸一次,就必須讓應用系統可以識別已經登陸過的用戶。應用系統應該能對ticket進行識別和提取,經過與認證系統的通信,能自動判斷當前用戶是否登陸過,從而完成單點登陸的功能。
 
上面的功能只是一個很是簡單的SSO架構,在現實狀況下的SSO有着更加複雜的結構。有兩點須要指出的是:
  • 單一的用戶信息數據庫並非必須的,有許多系統不能將全部的用戶信息都集中存儲,應該容許用戶信息放置在不一樣的存儲中,以下圖所示。事實上,只要統一認證系統,統一ticket的產生和效驗,不管用戶信息存儲在什麼地方,都能實現單點登陸。
 
  • 統一的認證系統並非說只有單個的認證服務器,以下圖所示,整個系統能夠存在兩個以上的認證服務器,這些服務器甚至能夠是不一樣的產品。認證服務器之間要經過標準的通信協議,互相交換認證信息,就能完成更高級別的單點登陸。以下圖,當用戶在訪問應用系統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的功能,須要兩個部分的合做:
    1. 統一的身份認證服務。
    2. 修改Web應用,使得每一個應用都經過這個統一的認證服務來進行身份效驗。

 

 

複製代碼
package com.ll.singlelogin;  
  
  
import javax.servlet.http.*;  
import java.util.*;  
  
  
public class SingleLogin implements HttpSessionListener {  
  
  
    // 保存sessionID和username的映射  
    private static HashMap hUserName = new HashMap();  
  
  
    /** 如下是實現HttpSessionListener中的方法* */  
    public void sessionCreated(HttpSessionEvent se) {  
    }  
  
  
    public void sessionDestroyed(HttpSessionEvent se) {  
        hUserName.remove(se.getSession().getId());  
    }  
  
  
    /** 
     * isAlreadyEnter-用於判斷用戶是否已經登陸以及相應的處理方法 
     *  
     * @param sUserName 
     *            String-登陸的用戶名稱 
     * @return boolean-該用戶是否已經登陸過的標誌 
     */  
    public static boolean isAlreadyEnter(HttpSession session, String sUserName) {  
        boolean flag = false;  
        // 若是該用戶已經登陸過,則使上次登陸的用戶掉線(依據使用戶名是否在hUserName中)  
        if (hUserName.containsValue(sUserName)) {  
            flag = true;  
            // 遍歷原來的hUserName,刪除原用戶名對應的sessionID(即刪除原來的sessionID和username)  
            Iterator iter = hUserName.entrySet().iterator();  
            while (iter.hasNext()) {  
                Map.Entry entry = (Map.Entry) iter.next();  
                Object key = entry.getKey();  
                Object val = entry.getValue();  
                if (((String) val).equals(sUserName)) {  
                    hUserName.remove(key);  
                }  
            }  
            // 添加如今的sessionID和username  
            hUserName.put(session.getId(), sUserName);  
            System.out.println("hUserName   =   " + hUserName);  
        } else {// 若是該用戶沒登陸過,直接添加如今的sessionID和username  
            flag = false;  
            hUserName.put(session.getId(), sUserName);  
            System.out.println("hUserName   =   " + hUserName);  
        }  
        return flag;  
    }  
  
  
    /** 
     * isOnline-用於判斷用戶是否在線 
     *  
     * @param session 
     *            HttpSession-登陸的用戶名稱 
     * @return boolean-該用戶是否在線的標誌 
     */  
    public static boolean isOnline(HttpSession session) {  
        boolean flag = true;  
        if (hUserName.containsKey(session.getId())) {  
            flag = true;  
        } else {  
            flag = false;  
        }  
        return flag;  
    }  
} 
複製代碼

 

web.xml部署於/App/WEB-INF下 web

 

複製代碼
<?xml   version= "1.0 "   encoding= "ISO-8859-1 "?>   
  
<!DOCTYPE   web-app   
PUBLIC   "-//Sun   Microsystems,   Inc.//DTD   Web   Application   2.3//EN "   
"http://java.sun.com/j2ee/dtds/web-app_2.3.dtd ">   
  
<web-app>   
  
<listener>   
<listener-class>   
com.inspirer.dbmp.SessionListener   
</listener-class>   
</listener>   
  
</web-app> 
複製代碼


應用部分 
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
<bean id="loginManager" class="LoginManager" scope="singleton" />
<bean id="action" class="LoginAction" scopt="prototype" >
    <property name="laginManager" ref="loginManager" />
</bean>

2. LoginManager.java服務器

複製代碼
Collection<Session> sessions;

public Session login(Session session) {
    for (Session s : sessions) {
        if (s 與 session 是同一用戶)
            策略一: return session
            策略二:{
                sessions.add(session); // 這兩行在循環中操做集合類會拋出異常
                sessions.remove(s);    // 此處僅爲簡單示範代碼,實際代碼中應該在循環外處理
                return s;
            }
    }
    sessions.add(session);

    return null;
}
複製代碼

3. LoginAction.javacookie

複製代碼
LoginManager loginManager;

public String execute() throws Exception {
    取session
    檢查用戶名,密碼
    if (是合法用戶) {
        session = loginManager.login(session);
        if (null!=session) session.invalidate();
    }
}
複製代碼

4. 若是自定義了UserContext,則可將集合改爲Collection<UserContext> users;session

5. UserContext.java架構

複製代碼
Session session;
Session getSession() {
    return this.session;
}

boolean login(String userName, String password) {
    訪問數據庫,檢查用戶名密碼
    return 是否合法;
}

boolean sameUser(UserContext uc) {
    return uc.userName.equals(this.userName);
}
複製代碼

6. 修改LoginManager.javaapp

複製代碼
Collection<UserContext> users;

public UserContext login(UserContext user) {
    for (UserContext uc : users) {
        if (uc.sameUser(user))
            策略一: return user
            策略二:{
            users.add(user);  // 這兩行在循環中操做集合類會拋出異常
            users.remove(uc); // 此處僅爲簡單示範代碼,實際代碼中應該在循環外處理
            return uc;
            }
    }
    users.add(user);

    return null;
}
複製代碼

7. 修改LoginAction.java

複製代碼
public String execute() throws Exception {
    取session // 也能夠在UserContext內部取session。
    UserContext user = new UserContext();
    user.setSession(session);
    if (user.login(userName, password)) {
        UserContext uc = loginManager.login(user);
        if (null!=uc) uc.getSession().invalidate();
    }
}
複製代碼
 
說明:引用自

HalfWater的博客

相關文章
相關標籤/搜索