畢業(yè)設計-web單點登錄系統(tǒng)的研究與設計

1、<p><b>　　摘要</b></p><p>　　隨著計算機網(wǎng)絡與信息技術的發(fā)展，企業(yè)網(wǎng)中應用系統(tǒng)越來越多。通常這些系統(tǒng)各自有一套認證系統(tǒng)，用戶需要使用各種系統(tǒng)時，就必須逐一以輸入口令等方式通過各種系統(tǒng)的身份認證。然而這強制需要用戶記住不同系統(tǒng)的認證口令，繁瑣的認證也增加了服務器的負荷。因此，需要一種獨立的身份認證系統(tǒng)來統(tǒng)一管理各個應用系統(tǒng)的身份認證。</p>&

2、lt;p>　　本文在分析了主流web單點登錄系統(tǒng)相關技術和規(guī)范上，總結出一個單點登錄系統(tǒng)的基本模型結構，以身份認證服務中心和身份認證服務客戶端系統(tǒng)構成。并通過Java平臺實現(xiàn)了一個具備基本認證功能的web單點登錄系統(tǒng)。該系統(tǒng)采用模塊化方式開發(fā)，各層次相對獨立，減少了已有系統(tǒng)集成到單點登錄系統(tǒng)的開發(fā)量。</p><p>　　關鍵詞：單點登錄，統(tǒng)一認證，信息系統(tǒng)，網(wǎng)站設計</p><p>

3、;<b>　　Abstract</b></p><p>　　With the development of computer network and Information Technology, the number of applications is increasing in enterprise network. However, each application system h

4、as its own identity authentication system. The user who wants to access these applications must be identified seriatim, like enter different password. But it compels user to remember each application’s password, also, it

5、 makes application servers tend to be overburdened. Consequently, an unaided identity authentication system is ne</p><p>　　Base on the mainstream technique and criterion of web single sign-on system, this pa

6、per sums up a simple single sign-on system model which is composed identity authentication service center and identity authentication service client system. Base on the java platform, a simple web single sign-on system i

7、s carried out. This system adopts modularization development manner, the layers in system keep independence from each other, and it cut down integration workload.</p><p>　　Keywords: SSO, unite attestation, i

8、nformation system, web site design目 錄</p><p><b>　　第一章 緒論1</b></p><p>　　1.1 研究目的與意義1</p><p>　　1.2 國內外研究概述2</p><p>　　1.3 本文研究內容及組織結構3</p><p

9、>　　第二章 單點登錄系統(tǒng)相關技術與規(guī)范5</p><p>　　2.1 單點登錄系統(tǒng)概念5</p><p>　　2.2 通用的標準解決方案7</p><p>　　2.2.1 通用安全服務應用程序接口（GSS-API）7</p><p>　　2.2.2開放軟件基金會(OSF)-分布式計算環(huán)境(DCE)8</p>

10、<p>　　2.2.3 嵌入式認證模塊(PAM)9</p><p>　　2.3 現(xiàn)實解決方案10</p><p>　　2.3.1 Broker-Based（基于經紀人） SSO方案10</p><p>　　2.3.2 Agent-Based （基于代理人） SSO方案10</p><p>　　2.3.3 Token-Base

11、d（基于令牌） SSO方案11</p><p>　　2.3.4 Agent and Broker-Based SSO方案12</p><p>　　2.3.5 Gateway-Based（基于網(wǎng)關） SSO 方案12</p><p>　　2.3.6 SAML-Based(基于安全斷言標記語言)方案13</p><p>　　第三章 w

12、eb單點登錄系統(tǒng)模型結構15</p><p>　　3.1 系統(tǒng)模型15</p><p>　　3.1.1 總體結構15</p><p>　　3.1.2 詳細結構16</p><p>　　3.2 身份認證服務中心18</p><p>　　3.2.1 功能18</p><p>　　3.2.

13、2 結構19</p><p>　　3.3 身份認證服務客戶端20</p><p>　　3.3.1 功能20</p><p>　　3.3.2 結構21</p><p>　　3.4 系統(tǒng)運作流程22</p><p>　　第四章 系統(tǒng)實現(xiàn)27</p><p>　　4.1 需求分析27&

14、lt;/p><p>　　4.1.1 功能需求27</p><p>　　4.1.2 性能需求27</p><p>　　4.1.3 運行需求27</p><p>　　4.2 開發(fā)平臺及工具28</p><p>　　4.3 數(shù)據(jù)庫設計30</p><p>　　4.4 系統(tǒng)關鍵模塊代碼實現(xiàn)32&

15、lt;/p><p>　　4.3.1 數(shù)據(jù)庫連接類32</p><p>　　4.3.2 認證中心票據(jù)的生成36</p><p>　　4.3.3 認證中心對用戶身份的認證36</p><p>　　4.3.4 認證客戶端對用戶身份的認證37</p><p>　　第五章 總結與展望41</p><p

16、>　　5.1 本文總結41</p><p>　　5.2 進一步研究方向41</p><p><b>　　致謝43</b></p><p><b>　　參考文獻45</b></p><p><b>　　第一章 緒論</b></p><p>

17、　　1.1 研究目的與意義</p><p>　　隨著信息技術和網(wǎng)絡技術的發(fā)展，各種應用服務的不斷普及，用戶每天需要登錄到許多不同的信息系統(tǒng)，如網(wǎng)絡、郵件、數(shù)據(jù)庫、各種應用服務器等。每個系統(tǒng)都要求用戶遵循一定的安全策略，比如要求輸入用戶ID和口令。隨著用戶需要登錄系統(tǒng)的增多，出錯的可能性就會增加，受到非法截獲和破壞的可能性也會增大，安全性就會相應降低。而如果用戶忘記了口令，不能執(zhí)行任務，就需要請求管理員的幫助，并只

18、能在重新獲得口令之前等待，造成了系統(tǒng)和安全管理資源的開銷，降低了生產效率。為避免這種尷尬，牢記登錄信息，用戶一般會簡化密碼，或者在多個系統(tǒng)中使用相同的口令，或者創(chuàng)建一個口令"列表"——這些都是會危及公司信息保密性的幾種習慣性做法。</p><p>　　當這些安全風險逐步反映出來，管理員增加一些新的安全措施的時候，這些措施卻在減少系統(tǒng)的可用性，并且會增大系統(tǒng)管理的復雜度。</p>

19、<p>　　另一方面，較大的企業(yè)內部，一般都有很多的業(yè)務支持系統(tǒng)為其提供相應的管理和IT服務。例如財務系統(tǒng)為財務人員提供財務的管理、計算和報表服務；人事系統(tǒng)為人事部門提供全公司人員的維護服務；各種業(yè)務系統(tǒng)為公司內部不同的業(yè)務提供不同的服務等等。這些系統(tǒng)的目的都是讓計算機來進行復雜繁瑣的計算工作，來替代人力的手工勞動，提高工作效率和質量。這些不同的系統(tǒng)往往是在不同的時期建設起來的，運行在不同的平臺上；也許是由不同廠商開發(fā)，使用了

20、各種不同的技術和標準。每一個應用系統(tǒng)在運行了數(shù)年以后，都會成為不可替換的企業(yè)IT架構的一部分。隨著企業(yè)的發(fā)展，業(yè)務系統(tǒng)的數(shù)量在不斷的增加，老的系統(tǒng)卻不能輕易的替換，這會帶來很多的開銷。其一是管理上的開銷，需要維護的系統(tǒng)越來越多。很多系統(tǒng)的數(shù)據(jù)是相互冗余和重復的，數(shù)據(jù)的不一致性會給管理工作帶來很大的壓力。業(yè)務和業(yè)務之間的相關性也越來越大，例如公司的計費系統(tǒng)和財務系統(tǒng)，財務系統(tǒng)和人事系統(tǒng)之間都不可避免的有著密切的關系。</p>

21、<p>　　為了降低管理的消耗，最大限度的重用已有投資的系統(tǒng)，很多企業(yè)都在進行著企業(yè)應用集成（EAI）。企業(yè)應用集成可以在不同層面上進行：例如在數(shù)據(jù)存儲層面上的“數(shù)據(jù)大集中”，在傳輸層面上的“通用數(shù)據(jù)交換平臺”，在應用層面上的“業(yè)務流程整合”，和用戶界面上的“通用企業(yè)門戶”等等。事實上，還用一個層面上的集成變得越來越重要，那就是“身份認證”的整合，也就是“單點登錄”。</p><p>　　另外，使用“

22、單點登錄”還是SOA時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通訊大量存在，服務之間的安全認證是SOA應用的難點之一，應此建立“單點登錄”的系統(tǒng)體系能夠大大簡化SOA的安全問題，提高服務之間的合作效率。</p><p>　　因此，在市場上提出了這樣的需求：網(wǎng)絡用戶可以基于最初訪問網(wǎng)絡時的一次身份驗證，對所有被授權的網(wǎng)絡資源進行無縫的訪問。從而提高網(wǎng)絡用戶的工作效率，降低網(wǎng)絡操作的費用，并

23、提高網(wǎng)絡的安全性。</p><p>　　正是基于這種市場需求，本文力圖通過對web單點登錄系統(tǒng)的研究，了解相關系統(tǒng)架構和技術，并嘗試開發(fā)出一套解決類似市場需求的web單點登錄系統(tǒng)。</p><p>　　1.2 國內外研究概述</p><p>　　在國內，較早使用SSO系統(tǒng)主要是一些大型企業(yè)，比如中國移動。隨著網(wǎng)絡的普及與發(fā)展，企業(yè)內應用系統(tǒng)的增加，越來越多的企業(yè)開始

24、使用SSO來整合企業(yè)的應用系統(tǒng)。而國內提供解決方案的企業(yè)也蓬勃發(fā)展，出現(xiàn)了較多的SSO產品。</p><p>　　在國外，對于SSO的研究較國內要早的多而且深入的多。成熟的大型商業(yè)系統(tǒng)或技術規(guī)范已經非常多了：微軟的.NET Passport（已整合到Windows Live ID）[1]、Sun Microsystems等建立的自由聯(lián)盟計劃(Liberty Identity Web Services Framew

25、ork)[2]、Microsoft和IBM聯(lián)合開發(fā)的Web服務聯(lián)邦語言(WS．Federation)以及結構化信息標準促進組織(OASIS)的安全服務委員會(SSTC)提出的安全斷言標記語言(Security Assertion Markup Language，SAML)[3]。．NET Passport技術是通過其Passport來實現(xiàn)單點登錄的，只要用戶通過微軟的Passport服務器的驗證，就可以訪問所有 與Passpor

26、t服務器合作的站點。但由于微軟在Passport驗證技術方面不公開，使得在安全性方面有一定的隱患。自由聯(lián)盟計劃和Web服務聯(lián)邦語言都是通過建立聯(lián)盟身份，來訪問聯(lián)盟中的其它系統(tǒng)的。但由于Web服務是松耦合的，所以建立聯(lián)盟身份并不是每個Web服務場景所必須的。S</p><p>　　除了大型的商業(yè)系統(tǒng)，國外還有很多成熟的開源SSO系統(tǒng)。比如SourceID.NET，OpenSSO，CAS。</p>&l

27、t;p>　　1.3 本文研究內容及組織結構</p><p>　　本文的研究內容主要是基于現(xiàn)有web單點登錄系統(tǒng)和技術，分析研究各種系統(tǒng)的結構和技術，并嘗試開發(fā)出一套實現(xiàn)基本功能的web單點登錄系統(tǒng)。</p><p><b>　　主要內容如下：</b></p><p>　　1.介紹單點登錄系統(tǒng)的相關技術及規(guī)范，并分別從技術，可實施性等方面進

28、行比較。</p><p>　　2.結合上一點的分析，概括出一種web單點登錄系統(tǒng)的簡易模型結構。</p><p>　　3.在第2點的基礎上，模擬一種需求環(huán)境，開發(fā)出一套web單點登錄系統(tǒng)。</p><p>　　組織結構如圖1-1所示：</p><p>　　第二章 單點登錄系統(tǒng)相關技術與規(guī)范</p><p>　　2.1

29、 單點登錄系統(tǒng)概念</p><p>　　Single Sign-On（SSO），中文名稱為單點登錄。指在多個應用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統(tǒng)。它包括可以將這次主要的登錄映射到其他應用中用于同一個用戶的登錄的機制。</p><p>　　用一種生活中的例子來對比介紹。西安是一個旅游勝地，有很多著名的景點。通常人們在進入景點之前都需要購買該景點的門票，才能進入欣賞風

30、景。當你游覽各個景點時就顯得很不方便，每個景點都需要重新購買單獨的門票，既費時又費力。于是西安旅游局發(fā)行了一種旅游年票，只需購買該年票，就可以隨時進入西安市多個景點，并不需要在各個景點單獨購票。</p><p>　　單點登錄機制與上述情況類似。當用戶第一次訪問應用系統(tǒng)1的時候，因為還沒有登錄，會被引導到認證系統(tǒng)中進行登錄（1）；根據(jù)用戶提供的登錄信息，認證系統(tǒng)進行身份效驗，如果通過效驗，應該返回給用戶一個認證的憑

31、據(jù)－－ticket（2）；用戶再訪問別的應用的時候（3，5）就會將這個ticket帶上，作為自己認證的憑據(jù)，應用系統(tǒng)接受到請求之后會把ticket送到認證系統(tǒng)進行效驗，檢查ticket的合法性（4，6）。如果通過效驗，用戶就可以在不用再次登錄的情況下訪問應用系統(tǒng)2和應用系統(tǒng)3了。如圖2-1所示： </p><p>　　從上面的視圖可以看出，要實現(xiàn)SSO，需要以下主要的功能：</p><p&g

32、t;　　1. 所有應用系統(tǒng)共享一個身份認證系統(tǒng)。</p><p>　　統(tǒng)一的認證系統(tǒng)是SSO的前提之一。認證系統(tǒng)的主要功能是將用戶的登錄信息和用戶信息庫相比較，對用戶進行登錄認證；認證成功后，認證系統(tǒng)應該生成統(tǒng)一的認證標志（ticket），返還給用戶。另外，認證系統(tǒng)還應該對ticket進行效驗，判斷其有效性。 </p><p>　　2. 所有應用系統(tǒng)能夠識別和提取ticket信息</

33、p><p>　　要實現(xiàn)SSO的功能，讓用戶只登錄一次，就必須讓應用系統(tǒng)能夠識別已經登錄過的用戶。應用系統(tǒng)應該能對ticket進行識別和提取，通過與認證系統(tǒng)的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。</p><p>　　上述是對單點登錄系統(tǒng)的概述，對于本文所研究的web單點登錄系統(tǒng)而言，眾所周知，Web協(xié)議（也就是HTTP）是一個無狀態(tài)的協(xié)議。一個Web應用由很多個Web頁面

34、組成，每個頁面都有唯一的URL來定義。用戶在瀏覽器的地址欄輸入頁面的URL，瀏覽器就會向Web Server去發(fā)送請求。瀏覽器向Web服務器發(fā)送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP連接。所謂無狀態(tài)的協(xié)議也就是表現(xiàn)在這里，瀏覽器和Web服務器會在第一個請求完成以后關閉連接通道，在第二個請求的時候重新建立連接。Web服務器并不區(qū)分哪個請求來自哪個客戶端，對所有的請求都一視同仁，都是單獨的連接。這樣的方式

35、大大區(qū)別于傳統(tǒng)的（Client/Server）C/S結構,在那樣的應用中，客戶端和服務器端會建立一個長時間的專用的連接通道。正是因為有了無狀態(tài)的特性，每個連接資源能夠很快被其他客戶端所重用，一臺Web服務器才能夠同時服務于成千上萬的客戶端。</p><p>　　但是我們通常的應用是有狀態(tài)的。先不用提不同應用之間的SSO，在同一個應用中也需要保存用戶的登錄身份信息。例如用戶在訪問頁面1的時候進行了登錄，但是剛才也提

36、到，客戶端的每個請求都是單獨的連接，當客戶再次訪問頁面2的時候，如何才能告訴Web服務器，客戶剛才已經登錄過了呢？瀏覽器和服務器之間有約定：通過使用cookie技術來維護應用的狀態(tài)。Cookie是可以被Web服務器設置的字符串，并且可以保存在瀏覽器中。當瀏覽器訪問了頁面1時，web服務器設置了一個cookie，并將這個cookie和頁面1一起返回給瀏覽器，瀏覽器接到cookie之后，就會保存起來，在它訪問頁面2的時候會把這個cookie

37、也帶上，Web服務器接到請求時也能讀出cookie的值，根據(jù)cookie值的內容就可以判斷和恢復一些用戶的信息狀態(tài)。</p><p>　　Web-SSO完全可以利用Cookie結束來完成用戶登錄信息的保存，將瀏覽器中的Cookie和上文中的Ticket結合起來，完成SSO的功能。</p><p>　　2.2 通用的標準解決方案</p><p>　　2.2.1 通用安

38、全服務應用程序接口（GSS-API）</p><p>　　"Generic Security Service Application Program Interface"簡寫GSS-API[4]，譯為通用安全服務應用程序接口，一個典型的GSS-API調用者是通訊協(xié)議本身，調用GSS-API，用可信性、完整性和機密性的安全服務來保護他的通訊。例如Kerberos。這就是GSS-API可以在不同的

39、安全服務和應用程序被使用的原因，包括SSO。GSS-API 的目的是提供隱蔽特定的內在安全機制的一個接口。這可以幫助不同應用程序之間有更好的互操作性。一個典型的GSS-API調用者是通訊協(xié)議本身，調用GSS-API，用可信性、完整性和機密性的安全服務來保護他的通訊。調用者接受一個本地GSS-API實現(xiàn)提供的一個令牌，并且把令牌傳送給遠程系統(tǒng)的對應方；對方接收令牌并把其傳送給他的GSS-API本地實現(xiàn)處理。通過GSS-API這種方式實現(xiàn)的

40、可用的安全服務在基于公鑰和私鑰的底層加密技術的多種機制上可實現(xiàn)的。</p><p>　　關于認證和密鑰分配系統(tǒng)的一個經常遇到的問題是，由于它要求對應用系統(tǒng)本身做出改動，所以經常受到的冷遇?？紤]到這一點, 對一個認證和密鑰分配系統(tǒng)來說, 提供一個標準化的安全API就顯得格外重要。能做到這一點, 開發(fā)人員就不必再為增加很少的安全功能而對整個應用程序動大手術了。因此, 認證系統(tǒng)設計領域內最主要的進展之一就是制定了標準化

41、的安全API, 即通用安全服務API(GSS-API)。德州Austin大學的研究者們開發(fā)的安全網(wǎng)絡編程(SNP), 對GSS-API接口進行了進一步的封裝, 使同網(wǎng)絡安全性有關的編程更加方便。</p><p>　　GSS-API的設計假定和強調以下幾個基本目標：</p><p>　　1. 機制獨立：GSS-API定義了一個接口來使用密碼技術實現(xiàn)強壯的認證和其他安全服務--在獨立于特定的底

42、層機制的通用層上。例如，GSS-API提供的服務可以用密鑰技術實現(xiàn)（例如，Kerberos）或者使用公鑰技術實現(xiàn)（例如 X.509）。</p><p>　　2. 協(xié)議環(huán)境獨立：GSS-API獨立于使用它的通訊協(xié)議組，允許在多種協(xié)議環(huán)境中使用。在進行調用的協(xié)議和GSS-API的應用中間，加入一個面向特定的通訊協(xié)議（如RPC）的中介，可以保持GSS-API功能的起用和協(xié)議通訊的起用之間的同步。</p>

43、<p>　　3. 協(xié)議聯(lián)合的獨立：GSS-API安全上下文構造是獨立于通訊協(xié)議相關的構造的。這個特點允許單獨的GSS-API實現(xiàn)可以被多種協(xié)議模塊使用，以利于調用這些模塊的應用程序。同時GSS-API服務也可以被應用程序直接調用，完全獨立于協(xié)議關聯(lián)。</p><p>　　4. 適應多種實現(xiàn)：GSS-API客戶不是被限制存在于實現(xiàn)GSS-API的系統(tǒng)定義的TCB（Trusted Computing Bas

44、e）范圍內；安全服務被以一種既適應intra-TCB調用，又適用extra-TCB調用的方式說明。</p><p>　　2.2.2開放軟件基金會(OSF)-分布式計算環(huán)境(DCE)</p><p>　　開放軟件基金會（OSF）的分布式計算環(huán)境[5]。DCE是一個被廣泛接受的解決方案，用于開發(fā)和部署安全的、企業(yè)級的分布式計算應用，提供網(wǎng)絡安全、透明的服務分配和跨平臺通信的能力，允許在一個異構

45、的環(huán)境中快速設計基于"主/從"或"對等"結構的應用。它能方便地對網(wǎng)絡提供最佳的性能和可靠的保護。因為DCE是由主流操作系統(tǒng)廠商的行業(yè)協(xié)會所支持的，所以這個標準在很多計算平臺上都得到了廣泛的支持。DCE核心功能現(xiàn)在已經被幾乎所有的UNIX系統(tǒng)及其變種所支持，并且，在PC操作系統(tǒng)日益普及的今天，DCE核心服務也在PC機上變得越來越普遍。 </p><p>　　DCE的認證管理服

46、務是集成了基于DES私人密鑰加密技術和MIT開發(fā)的Kerberos技術的身份驗證。這是一種企業(yè)級的安全解決方案，它使企業(yè)能為網(wǎng)絡資源的使用提供安全。保管理護和通過企業(yè)Intranet的用戶和通過Internet的遠程用戶都可以有控制地訪問這些資源。</p><p>　　DCE對于安全涉及到4個方面：</p><p>　　1.認證（authentication）， </p>&

47、lt;p>　　2.安全通訊（secure communications）， </p><p>　　3.授權（authorization）， </p><p>　　4.和審計（auditing）。</p><p>　　2.2.3 嵌入式認證模塊(PAM)</p><p>　　PAM（Pluggable Authentication Mod

48、ules ）[6]是由Sun提出的一種用于實現(xiàn)應用程序的認證機制。其核心是一套共享庫，目的是提供一個框架和一套編程接口，將認證工作由程序員交給管理員，PAM允許管理員在多種認證方法之間作出選擇，它能夠改變本地認證方法而不需要重新編譯與認證相關的應用程序，同時也便于向系統(tǒng)中添加新的認證手段。 </p><p>　　PAM最初是集成在Solaris中，目前已移植到其它系統(tǒng)中，如Linux、SunOS、HP-UX 9.

49、0等，并在Linux中得到廣泛的應用。</p><p>　　PAM的設計目標是：</p><p>　　1.管理員可以選擇認證方式，從簡單的密碼到智能卡系統(tǒng)。 </p><p>　　2.可以為不同的程序配置不同的認證機制。如 使telnet使用 S/Key認證。而本機的 login 缺省使用一般的 UNIX password。 </p><p>

50、;　　3.支持程序的顯示方式的需求。如login 需要基于終端的顯示，而dtlogin需要X顯示， 而`ftp' 和 `telnet'需要透過網(wǎng)絡來認證。 </p><p>　　4.支持為一個程序配置同時使用多種認證機制。 </p><p>　　5.可是用戶在使用多種認證機制時,不必為同一個密碼敲入多次。 </p><p>　　6.可是用戶在認真時需

51、要輸入多個密碼。 </p><p>　　7.當?shù)讓拥恼J證機制改變時上層軟件不需要修改。 </p><p>　　8.結構為system authentication提供一個pluggable_ model。 </p><p>　　9.必須能滿足現(xiàn)有的服務需要。 </p><p><b>　　PAM的功能包括：</b><

52、;/p><p>　　1.加密口令（包括DES以外的算法）； </p><p>　　2.對用戶進行資源限制，防止Dos攻擊； </p><p>　　3.允許隨意Shadow口令； </p><p>　　4.限制特定用戶在指定時間從指定地點登錄； </p><p>　　5.引入概念"client plug-in ag

53、ents"，使PAM支持C/S應用中的機器--機器認證成為可能。 </p><p>　　PAM為更有效的認證方法的開發(fā)提供了便利，在此基礎上可以很容易地開發(fā)出替代常規(guī)的用戶名加口令的認證方法，如智能卡、指紋識別等認證方法。</p><p>　　2.3 現(xiàn)實解決方案</p><p>　　2.3.1 Broker-Based（基于經紀人） SSO方案</

54、p><p>　　這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人[7]給被用于進一步請求的電子的身份存取。中央數(shù)據(jù)庫的使用減少了管理的代價，并為認證提供一個公共和獨立的"第三方"。例如Kerberos（如圖2-2所示）、Sesame、IBM KryptoKnight（憑證庫思想）等。</p><p>　　圖2-2 Kerberos圖例</p>

55、<p>　　該方案采用一個中央數(shù)據(jù)庫來管理用戶數(shù)據(jù)，可能遇到的問題是如果中央數(shù)據(jù)庫當機，會導致所有應用系統(tǒng)無法認證使用。并且對于舊系統(tǒng)的改造也是使用該方案的一個挑戰(zhàn)。</p><p>　　2.3.2 Agent-Based （基于代理人） SSO方案</p><p>　　在一個基于代理人的解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同

56、的功能。比如, 它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人能也被放在服務器上面，在服務器的認證系統(tǒng)和客戶端認證方法之間充當一個"翻譯"。 一個基于代理人的解決方案的一個例子是SSH。</p><p>　　SSH的英文全稱是Secure Shell。通過使用SSH，你可以把所有傳輸?shù)臄?shù)據(jù)進行加密，這樣就能夠防止DNS和IP欺騙。這是一個為在網(wǎng)上進行安全連接的客戶/服務器類型

57、加密軟件，實現(xiàn)了一個密鑰交換協(xié)議，以及主機及客戶端認證協(xié)議。SSH的用戶可以使用包括RSA算法的不同認證方法。當使用RSA認證時，代理程序可以被用于單點登錄。代理程序可以在PC，便攜機，或終端上運行，當被認證身份加入到代理程序中，如果該代理程序有新的子連結產生，則繼承原有連結的認證。遠程系統(tǒng)往往需要一個SSH服務器，用以與代理程序通信。</p><p>　　利用個性化的安全代理來實現(xiàn)時，每個運行SSH 的主機（不

58、管是服務器還是客戶端）必須有一個安全代理程序在上面運行。例如，要獲得主機密碼和服務器密碼，個性化代理參與如下的兩部分：</p><p>　　1.密鑰生成和存儲：當服務器需要生成主機密碼和服務器密碼時，它會要求本地的安全代理來完成這一工作。本地安全代理或是自己生成密鑰對，或是要求另一個安全代理來生成。SSH協(xié)議并不區(qū)分這兩種情況。生成的密鑰由安全代理保管，在需要時使用。 </p><p>　

59、　2.身份認證：當客戶端得到主機密碼或服務器密碼，它要傳給自己的安全代理，由安全代理負責對密碼進行認證。作為認證結果，安全代理會返回"成功"或"失敗"。SSH協(xié)議本身不關心有關密碼的細節(jié)。稍后，如果有新的公鑰算法引入SSH，只需要替換安全代理的部分。</p><p>　　2.3.3 Token-Based（基于令牌） SSO方案 </p><p>　

60、　現(xiàn)在被廣泛使用的口令認證，比如FTP，郵件服務器的登陸認證，都可被稱為"single-factor "口令的認證。這是一種簡單易用的方式，同時也是一種會帶來很多安全隱患的方式。比如：易于猜測，很少進行更換，一個口令在多種應用當中使用等等一會危及安全的習慣。再如，在明文傳輸?shù)木W(wǎng)絡環(huán)境里，經常使用并很少更換的口令，更易于被竊取和造成危害。</p><p>　　RSA公司提出的一種稱為SecurI

61、D的解決方案。與"single-factor "不同是是它被稱之為"two-factor"雙因素的認證。構成認證的第一個因素是Personnel Identification Number (PIN)，即用戶身份識別碼，這是一串保密的數(shù)字，可由系統(tǒng)管理員訂制。第二個要素是SecurID token，一個小型的數(shù)字發(fā)生器，這個發(fā)生器的時鐘將與網(wǎng)絡環(huán)境中提供身份鑒別的服務器（ACE）保持同步，并且與A

62、CE上的用戶數(shù)據(jù)庫保持映射。數(shù)字發(fā)生器每隔一段時間（比如一分鐘）產生新的數(shù)字，PIN + 同步時鐘數(shù)字就是用戶的登錄代碼。</p><p>　　解決方案中也有種被稱為WebID的模塊。在Web服務器上安裝一個ACE服務器的代理程序，用來接受SecurID。當訪問第一個需要認證的URL時，WebID會軟件產生并加密一個標識，這個標識將在訪問其他資源的時候被用到。</p><p>　　2.3.

63、4 Agent and Broker-Based SSO方案</p><p>　　通過字面我們知道這是Agent 與 Broker的結合方案。當Agent-Base的解決方案和Broker-Base的解決方案被相結合時，就結合前者的靈活性和后者的中央式管理兩方面的優(yōu)勢。Agent-Base的好處還在于是減少了改變網(wǎng)絡應用程序的的代價。這樣，與Kerberos相比，就不需要"kerberize"

64、;化的應用程序。</p><p>　　2.3.5 Gateway-Based（基于網(wǎng)關） SSO 方案</p><p>　　在Broker-Based的方案中，會在網(wǎng)絡中放置一個"看門狗"的模型。而Gateway-Based則是另一種單點登錄的方法，具體的做法是提供類似象"門"一樣的網(wǎng)關用以安全的接入到可信的網(wǎng)絡服務。網(wǎng)關可以是防火墻, 或者是專門用

65、于通訊加密的服務器。在這種方案，所有的響應服務都需要放在被網(wǎng)關隔離的受信網(wǎng)段里。Client通過網(wǎng)關進行認證后獲得接受服務的受權。如果在網(wǎng)關后的服務能夠通過IP地址進行識別，并在網(wǎng)關上建立一個基于IP的規(guī)則，而這個規(guī)則如果與在網(wǎng)關上的用戶數(shù)據(jù)庫相結合，網(wǎng)關就可以被用于單點登錄。網(wǎng)關將記錄Client的身份不再需要冗余的認證請求，便可授權所要求的服務。由于網(wǎng)關可以監(jiān)視并改變應用服務的數(shù)據(jù)流，所以在不修改應用服務的同時，改變認證信息，并能提

66、供合適的訪問控制。</p><p>　　2.3.6 SAML-Based(基于安全斷言標記語言)方案</p><p>　　SAML[8]是結構化信息標準促進組織 (OASIS)推薦的安全服務標準,主要用于相互信任的合作者之間交換安全信息。SAML是一種基于 XML的框架 ,集成了 XML Signature、 XML Encryption和SOAP等其他產業(yè)標準協(xié)議和通信技術。SAML是聯(lián)

67、合身份認證的主要協(xié)議 ,允許企業(yè)發(fā)布在整個企業(yè)范圍有效的用戶身份認證和授權證書。SAML并沒有設置中央化、 分散化或聯(lián)合的基礎結構或解決方案 ,相反 ,它用于實現(xiàn)身份認證信息、 授權信息和屬性信息的交換。SAML并未推出任何新的身份認證模式或方法 ,也不是其他安全性標準 (如 WS - Security)的替換方案 ,它可以被添加到以前的應用程序或 Web瀏覽器應用程序中 ,不受任何限制。</p><p>　　S

68、AML在解決安全的 Web服務互操作性整個問題的過程中起重要作用。除了專用網(wǎng)橋以外 ,互操作性的另一個必要條件是具備一個不同層和安全模型都可以解釋的標準憑據(jù)。SAML為安全信息定義了一種標準化格式和一種在不同的應用程序之間傳輸安全數(shù)據(jù)的標準化方式。S AML規(guī)范由斷言、 請求/響應協(xié)議、 綁定和配置文件這 4個部分組成。</p><p>　　第三章 web單點登錄系統(tǒng)模型結構</p><p&

69、gt;<b>　　3.1 系統(tǒng)模型</b></p><p>　　3.1.1 總體結構</p><p>　　傳統(tǒng)的web應用系統(tǒng)和認證系統(tǒng)通常都是集成在一起的。用戶在使用某個需要身份認證的web應用系統(tǒng)時，系統(tǒng)都會要求用戶進行諸如輸入用戶名和密碼之類的驗證操作，并且各個web系統(tǒng)的認證模塊都是孤立的。當用戶在web系統(tǒng)1里通過認證并使用了相關服務后，轉向web系統(tǒng)2時，

70、即便他同時是web系統(tǒng)1和web系統(tǒng)2的合法用戶，他也必須重新在web系統(tǒng)2進行身份認證。如圖3-1所示：</p><p>　　在圖3-1中，web系統(tǒng)1和web系統(tǒng)2擁有同樣的用戶信息數(shù)據(jù)（比如企業(yè)內部各個應用系統(tǒng)，使用者都是相同的企業(yè)員工），但是因為各自擁有獨立的認證系統(tǒng)，導致用戶在使用各個系統(tǒng)時必須各自輸入認證信息。</p><p>　　而在單點登錄環(huán)境下，用戶和應用系統(tǒng)之間的認證方

71、式[9]就有很大的不同了。如圖3-2所示：</p><p>　　對比圖3-1，可以清楚的發(fā)現(xiàn)，在圖3-2中兩個應用系統(tǒng)各自的認證系統(tǒng)被剔除了，取而代之的是一個公用的認證系統(tǒng)。不管用戶訪問應用系統(tǒng)1還是應用系統(tǒng)2，他都將先通過公有的認證系統(tǒng)的認證，而在通過認證系統(tǒng)的認證后，無論用戶是在系統(tǒng)1還是系統(tǒng)2之間跳轉，甚至更多的應用系統(tǒng)，都不需要再進行身份認證。</p><p>　　3.1.2 詳細

72、結構</p><p>　　在對web單點登錄系統(tǒng)有了整體認識后，下面對系統(tǒng)進行詳細的分析。假定我們稱身份認證服務中心為SSO，身份認證服務客戶端為PSO。如圖3-3所示。</p><p>　　首先用戶訪問某一個應用程序服務，系統(tǒng)檢查用戶是否登錄或者持有SSO票據(jù)，如果用戶沒有登錄，PSO則調用轉發(fā)服務，將用戶重定向到SSO登錄頁面。</p><p>　　用戶輸入授權

73、的合法認證信息，SSO認證服務通過查詢數(shù)據(jù)庫的用戶相關信息驗證用戶，驗證無誤后，SSO將調用SSO票據(jù)生成服務來為該用戶生成SSO票據(jù)，然后將該票據(jù)附在之前PSO應用程序的URL后，并且調用重定向服務，將瀏覽器重定向到該PSO應用程序。</p><p>　　此時PSO應用程序再次被用戶訪問，與之前不同的是訪問URL增加了SSO生成的登錄票據(jù)。PSO解析該URL，從中截獲SSO票據(jù)，并進行驗證。同過驗證后，PSO將

74、調用PSO生成服務來生成該用戶對該PSO應用程序的訪問票據(jù)。此后只要用戶持有該PSO票據(jù)，無需到SSO驗證即可使用該應用程序提供的相關服務。</p><p>　　假定用戶訪問并通過某一個應用程序身份認證后繼續(xù)訪問另一個處于相同認證系統(tǒng)保護下的應用程序。傳統(tǒng)的認證方式必然需要用戶重新輸入認證信息進行身份認證。而在單點登錄環(huán)境下，用戶則省略了這些繁瑣操作。</p><p>　　用戶同某一應用程

75、序認證后，訪問另一個應用程序時。應用程序同用戶訪問第一個應用程序時一樣對用戶進行身份認證，此時用戶并沒有該應用程序的PSO票據(jù)，換言之就是用戶沒有在該應用程序登陸過。此時應用程序將用戶重定向到SSO進行認證。SSO在接收到該應用程序送來的認證請求消息后，發(fā)現(xiàn)該用戶已經合法登錄過其他應用程序并持有SSO票據(jù)，于是SSO將用戶的SSO票據(jù)附在請求認證的應用程序URL后面，并重定向到URL。</p><p>　　應用程

76、序截取到URL后附加的SSO票據(jù)并進行驗證，驗證通過后調用PSO票據(jù)生成服務生成用戶的PSO票據(jù)。此時用戶就可以訪問該應用程序的相關服務了。</p><p>　　3.2 身份認證服務中心</p><p><b>　　3.2.1 功能</b></p><p>　　通過上面的介紹，實際上本文介紹的web單點登錄模型一個基于Ticket的認證方式[1

77、0]。User想要獲取PSO端所提供的服務資源，先得通過PSO端的認證；而認證的先決條件是User向PSO端提供從SSO端獲得的一個SSO票據(jù)?？梢赃@么說，SSO票據(jù)是User進入某個PSO端應用服務的一張門票。而這張門票必須從一個合法的票據(jù)頒發(fā)機構獲得，這個頒發(fā)機構就是所有PSO端所認同的身份認證服務中心（SSO）， 同時這張票據(jù)具有超強的防偽標識：它是被SSO加密的。對User來說， 獲得SSO票據(jù)是整個認證過程中最為關鍵的部分。如

78、圖3-4。 </p><p>　　身份認證服務中心無疑是單點登錄系統(tǒng)中最重要的模塊之一。它承擔著對用戶身份的合法性驗證和分發(fā)合法身份消息的任務。從功能上說主要有一下幾點：</p><p>　　1.負責對用戶進行身份認證。這一點同傳統(tǒng)的應用系統(tǒng)中的身份認證是相同的。身份認證服務中心連接著存放用戶信息的數(shù)據(jù)庫。當用戶提交認證信息（通常是用戶名和密碼）后，身份認證中心通過查詢數(shù)據(jù)庫中存放的用戶信

79、息，并進行比對來驗證用戶的身份是否合法。</p><p>　　2.負責SSO票據(jù)的生成。這是身份認證服務中心一個較傳統(tǒng)應用系統(tǒng)中的身份認證不同的地方之一。當身份認證服務中心驗證了用戶的身份合法后，將調用SSO票據(jù)生成服務來生成用戶通過身份認證服務客戶端（PSO）認證所必需的SSO票據(jù)。通常SSO票據(jù)具備PSO確認用戶合法的相關信息，但出于安全因素不直接包含用戶的身份認證信息，并且經過一定的加密來防止被非法獲取。&

80、lt;/p><p>　　3.負責處理用戶在不同應用系統(tǒng)間切換時的身份認證。單點登錄的特點就是用戶在通過身份認證侯，訪問另一應用系統(tǒng)時不需要再次輸入身份認證信息。當用戶訪問某一個應用系統(tǒng)并通過認證中心認證后，繼續(xù)訪問另一個應用系統(tǒng)時，該應用系統(tǒng)端的PSO將用戶重定向到SSO端進行用戶身份認證，此時身份認證服務中心檢測到該用戶已經通過身份認證。然后身份認證服務中心將該用戶之前產生的SSO票據(jù)重新發(fā)送給該應用系統(tǒng)，應用系統(tǒng)

81、接收到SSO票據(jù)后即確認了用戶的合法身份。此功能就實現(xiàn)了單點登錄系統(tǒng)環(huán)境下，用戶在多個應用系統(tǒng)進行切換時不需要多次輸入認證信息進行身份認證的繁瑣步驟。</p><p><b>　　3.2.2 結構</b></p><p>　　通過前面的分析，對單點登錄系統(tǒng)中的身份認證服務中心有一定的認識。下面通過分析其結構來進一步了解身份認證服務中心的內部。如圖3-5。</p&

82、gt;<p>　　分析上面的結構圖，用戶訪問身份認證服務中心有兩種情況：</p><p>　　1.有SSO票據(jù)狀態(tài)訪問。即用戶之前在訪問某個應用系統(tǒng)時已經通過身份認證服務中心的認證，再訪問另一個應用系統(tǒng)時，該應用系統(tǒng)需要對用戶身份進行驗證。此時第二個應用系統(tǒng)將用戶重定向到身份認證服務中心進行驗證，SSO檢查該用戶時發(fā)現(xiàn)該用戶已經登陸過，并持有SSO票據(jù)，于是不再需要用戶輸入用戶名和密碼等相關身份信息

83、，而直接將SSO票據(jù)附加到請求驗證的第二個應用系統(tǒng)的URL，然后重定向到該URL交由PSO端進行后續(xù)操作。</p><p>　　2.無SSO票據(jù)狀態(tài)訪問。即用戶是第一次訪問身份認證服務中心。此時身份認證服務中心要求用戶輸入用戶名和密碼等之類的身份認證信息，然后SSO通過查詢數(shù)據(jù)庫對該信息進行比對認證。如果用戶信息通過校驗，則身份認證服務中心調用SSO票據(jù)生成服務為用戶生成SSO票據(jù)。然后將該SSO票據(jù)附加到請求驗

84、證的PSO端URL上，并重定向到該URL，繼而交給PSO進行后續(xù)操作。</p><p>　　3.3 身份認證服務客戶端</p><p><b>　　3.3.1 功能</b></p><p>　　與身份認證服務中心配套的是身份認證服務客戶端（PSO），它也是整個單點登錄系統(tǒng)中非常重要的部分。通常來講，身份認證服務客戶端是嵌入應用系統(tǒng)中的一個模塊。

85、它與應用系統(tǒng)的權限系統(tǒng)相配合來達到對用戶訪問服務資源的控制。實際上，身份認證服務客戶端在應用系統(tǒng)和身份認證服務中心扮演中間人的角色。</p><p>　　一方面，用戶訪問應用系統(tǒng)提供的需要認證的服務或資源時，應用系統(tǒng)首先檢查用戶是否登錄，如未登錄，則調用身份認證服務客戶端模塊準備進行認證操作。此時，身份認證服務客戶端模塊記錄下當前用戶訪問URL，并將用戶瀏覽器重定向到身份認證服務中心的登錄頁面，進行登錄操作。&l

86、t;/p><p>　　另一方面，當身份認證服務中心驗證了用戶身份，生成了SSO票據(jù)，并且將用戶瀏覽器重定向到附加了SSO票據(jù)的原請求認證URL后，此時身份認證服務客戶端截獲到URL中有SSO票據(jù)，然后攜帶該票據(jù)到身份認證服務中心進行SSO票據(jù)合法性驗證。驗證通過后，身份認證服務客戶端即授權用戶（或者通知應用系統(tǒng)的權限系統(tǒng)進行授權）訪問相應服務資源。</p><p><b>　　3.3

87、.2 結構</b></p><p>　　下面結合圖例對身份認證服務客戶端進行結構分析。如圖3-6所示： </p><p>　　通過前面的分析，對單點登錄系統(tǒng)中的身份認證服務客戶端有一定的認識。下面通過分析其結構來進一步了解身份認證服務中心的內部。如圖3-6。</p><p>　　分析上面的身份認證服務客戶端結構圖，可以體現(xiàn)出身份認證服務客戶端的中間人特點

88、。同樣，訪問（系統(tǒng)內部模塊間的調用）身份認證服務客戶端也有兩種情況：</p><p>　　1.請求URL不包含SSO票據(jù)?？赡芮闆r是用戶第一次訪問應用系統(tǒng)或者PSO票據(jù)失效，需要重新認證。此時身份認證服務客戶端的工作比較簡單，只需要簡單的將用戶瀏覽器重定向到身份認證服務中心的登錄頁，讓用戶進行登錄即可。</p><p>　　2.請求URL包含SSO票據(jù)。這表明用戶已經（正常情況下）在身份認

89、證服務中心進行了登錄操作，該URL是身份認證服務中心重定向而來。此時身份認證服務客戶端分析并截獲URL中的SSO票據(jù)。然后調用相關模塊服務到身份認證服務中心驗證該SSO票據(jù)是否合法。如果是非法SSO票據(jù)，則將用戶瀏覽器重定向到身份認證服務中心登錄頁面要求用戶重新進行登錄操作；如果是合法票據(jù)，通過驗證后，身份認證服務客戶端立即調用PSO票據(jù)生成模塊來生成用戶訪問該應用系統(tǒng)的服務和資源所需要的憑證，即PSO票據(jù)。最后身份認證服務客戶端返回用

90、戶之前所請求的服務或資源。</p><p>　　3.4 系統(tǒng)運作流程</p><p>　　在對單點登錄系統(tǒng)模型結構進行了簡單分析后，下面通過一個模擬情景總結一下單點登錄系統(tǒng)的運作流程。該情景模擬企業(yè)人事管理系統(tǒng)[11]。在這之前先來看一看傳統(tǒng)的用戶認證流程，如圖3-7所示：</p><p>　　傳統(tǒng)的認證方式符合人們的常規(guī)思考。分為以下幾個步驟：</p>

91、<p>　　1.用戶打開人事管理系統(tǒng)登錄頁（或者系統(tǒng)主頁登錄處）。</p><p>　　2.用戶輸入用戶名和密碼，并提交登錄請求。</p><p>　　3.人事系統(tǒng)登錄驗證模塊接收到用戶填寫的賬號信息后，查詢數(shù)據(jù)庫，比對用戶名和密碼是否合法。</p><p>　　4.如果用戶帳戶正確，則系統(tǒng)返回系統(tǒng)主界面，此時用戶已具有相應授權。如果用戶帳戶錯

92、誤，則重新返回登錄頁面。</p><p>　　接下來是使用單點登錄系統(tǒng)后的認證流程。如圖3-8所示：</p><p>　　使用了單點登錄認證方式的系統(tǒng)運作流行相比較未使用單點登錄的系統(tǒng)來說要復雜一些：</p><p>　　1.用戶打開人事管理系統(tǒng)主頁，準備進入系統(tǒng)。</p><p>　　2.嵌入到系統(tǒng)的單點登錄PSO模塊檢測到用戶沒有登錄過，

93、即未持有PSO票據(jù)或者SSO票據(jù)。</p><p>　　3.PSO模塊將用戶瀏覽器重定向到身份認證服務中心的登錄頁面。</p><p>　　4.用戶輸入用戶名和密碼等認證信息并提交。</p><p>　　5.身份認證服務中心連接數(shù)據(jù)庫對用戶輸入的認證信息進行比對，如果通過驗證，則調用身份認證服務中心的SSO票據(jù)生成模塊生成該用戶的SSO票，并附加到請求認證服務的UR

94、L后，然后重定向該URL；否則返回登錄頁面要求用戶重新輸入認證信息。</p><p>　　6.身份認證服務客戶端接受到URL后面附加的SSO票據(jù)后，將攜帶該票據(jù)到身份認證服務中心進行驗證。</p><p>　　7.如果通過驗證，身份認證服務客戶端調用PSO票據(jù)生成模塊來生成該用戶的PSO票據(jù)授權用戶訪問權限，并返回到系統(tǒng)主頁面；否則重新返回身份認證服務中心登錄頁面。</p>

95、<p><b>　　第四章 系統(tǒng)實現(xiàn)</b></p><p>　　基于前面對單點登錄系統(tǒng)理論的學習研究和分析，接下來本章將進行程序設計，開發(fā)一個單點登錄系統(tǒng)。該系統(tǒng)將具備基本的單點認證功能。</p><p><b>　　4.1 需求分析</b></p><p>　　4.1.1 功能需求</p>&

96、lt;p>　　本系統(tǒng)將實現(xiàn)如下功能：</p><p>　　1.用戶注冊功能：允許用戶注冊統(tǒng)一的通行證，可以在系統(tǒng)提供的兩個示例網(wǎng)站中使用。</p><p>　　2.單點登錄功能：即用戶在本系統(tǒng)提供的兩個示例中的任意一個示例網(wǎng)站中登錄成功后，無需再另一個示例網(wǎng)站中進行登錄操作即可訪問示例網(wǎng)站的內容。</p><p>　　3.用戶修改資料功能：允許用戶修改注冊資料

97、及密碼。</p><p>　　4.后臺管理用戶功能：管理員可以查看、修改和刪除注冊用戶。</p><p>　　4.1.2 性能需求</p><p>　　1.用戶角度：盡可能提高系統(tǒng)響應時間；避免系統(tǒng)的代碼級錯誤；友好的錯誤提示。</p><p>　　2.系統(tǒng)角度：由于多個應用系統(tǒng)的身份認證集中到一起進行處理，所以模擬高訪問量情況下，web服務

98、器需要承受高強度的負荷，在web服務器操作系統(tǒng)、數(shù)據(jù)庫和網(wǎng)站開發(fā)平臺的選擇上要綜合考慮。本系統(tǒng)選擇了java平臺作為網(wǎng)站開發(fā)語言，數(shù)據(jù)庫選擇了開源數(shù)據(jù)庫MYSQL。</p><p>　　3.開發(fā)角度：代碼應盡量符合規(guī)范；選擇最優(yōu)算法；數(shù)據(jù)庫設計要合理；數(shù)據(jù)庫查詢要盡量優(yōu)化。</p><p>　　4.1.3 運行需求</p><p>　　1.硬件需求：一般PC機，筆記

99、本</p><p><b>　　2.軟件需求：</b></p><p>　　a. UNIX或WINDOWS服務器操作系統(tǒng)</p><p>　　b. TOMCAT6.0+MYSQL5.0+JDK6</p><p>　　c. IE或FIREFOX等瀏覽器支持</p><p>　　4.2 開發(fā)平臺及工具

100、</p><p>　　JSP[12]，全稱為Java Server Pages / Servlet ，JSP和Servlet要放在一起講，是因為它們都是Sun公司的J2EE（Java 2 platform Enterprise Edition）應用體系中的一部分。Servlet的形式和前面講的CGI差不多，它是HTML代碼和后臺程序分開的。它們的啟動原理也差不多，都是服務器接到客戶端的請求后，進行應答。不同的是，

101、CGI對每個客戶請求都打開一個進程（Process），而Servlet卻在響應第一個請求的時候被載入，一旦Servlet被載入，便處于已執(zhí)行狀態(tài)。對于以后其他用戶的請求，它并不打開進程，而是打開一個線程（Thread），將結果發(fā)送給客戶。由于線程與線程之間可以通過生成自己的父線程（Parent Thread）來實現(xiàn)資源共享，這樣就減輕了服務器的負擔，所以，Java Servlet可以用來做大規(guī)模的應用服務。 </p>&l

102、t;p>　　雖然在形式上JSP和ASP或PHP看上去很相似——都可以被內嵌在HTML代碼中。但是，它的執(zhí)行方式和ASP或PHP完全不同。在JSP被執(zhí)行的時候，JSP文件被JSP解釋器（JSP Parser）轉換成Servlet代碼，然后Servlet代碼被Java編譯器編譯成 .class 字節(jié)文件，這樣就由生成的Servlet來對客戶端應答。所以，JSP可以看做是Servlet的腳本語言（Script Language）版。 &

103、lt;/p><p>　　由于JSP/Servlet都是基于Java的，所以它們也有Java語言的最大優(yōu)點——平臺無關性，也就是所謂的“一次編寫，隨處運行（WORA – Write Once, Run Anywhere）”。除了這個優(yōu)點，JSP/Servlet的效率以及安全性也是相當驚人的。因此，JSP/Servlet雖然在國內目前的應用并不廣泛，但是其前途不可限量。 </p><p>　　在調

104、試JSP代碼時，如果程序出錯，JSP服務器會返回出錯信息，并在瀏覽器中顯示。這時，由于JSP是先被轉換成Servlet后再運行的，所以，瀏覽器中所顯示的代碼出錯的行數(shù)并不是JSP源代碼的行數(shù)，而是指轉換后的Servlet程序代碼的行數(shù)。這給調試代碼帶來一定困難。所以，在排除錯誤時，可以采取分段排除的方法（在可能出錯的代碼前后輸出一些字符串，用字符串是否被輸出來確定代碼段從哪里開始出錯），逐步縮小出錯代碼段的范圍，最終確定錯誤代碼的位置。

105、</p><p>　　MySQL是一個小型關系型數(shù)據(jù)庫管理系統(tǒng)，開發(fā)者為瑞典MySQL AB公司。在2008年1月16號被Sun公司收購。目前MySQL被廣泛地應用在Internet上的中小型網(wǎng)站中。由于其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，許多中小型網(wǎng)站為了降低網(wǎng)站總體擁有成本而選擇了MySQL作為網(wǎng)站數(shù)據(jù)庫。MySQL的官方網(wǎng)站的網(wǎng)址是：www.mysql.com。</p>

106、<p>　　MyEclipse企業(yè)級工作平臺（MyEclipse Enterprise Workbench ，簡稱MyEclipse）是對Eclipse IDE的擴展，利用它我們可以在數(shù)據(jù)庫和J2EE的開發(fā)、發(fā)布，以及應用程序服務器的整合方面極大的提高工作效率。它是功能豐富的J2EE集成開發(fā)環(huán)境，包括了完備的編碼、調試、測試和發(fā)布功能，完整支持HTML, Struts, JSF, CSS, JavaScript, SQL, H

107、ibernate。</p><p>　　在結構上，MyEclipse的特征可以被分為7類：</p><p><b>　　1. J2EE模型</b></p><p>　　2. WEB開發(fā)工具</p><p>　　3. EJB開發(fā)工具</p><p>　　4. 應用程序服務器的連接器</p>