一.簡介

現在越來越多的企業應用建置在J2EE平臺上，這得益于J2EE為企業應用的開發提供了良好的框架和服務的支持。J2EE為企業應用提供了多方面的服務(Security、Transaction、Naming等)。本文將介紹J2EE提供的安全服務 。作者首先介紹J2EE中的安全概念和J2EE的安全架構，然后結合具體的案例向讀者展示如何在自己的程序中應用J2EE提供的安全特性。本文所介紹的內容是基于J2EE1.3版本的。

二.J2EE中的安全概念

主體（Principal）︰主體（Principal）是被在企業安全服務驗證了的實體。主體（Principal）用主體名作為它的識別數據，透過與主體相關的驗證數據進行驗證。通常主體名就是使用者的 登入名，驗證數據就是登入的密碼。J2EE規范中并沒有限定J2EE 產品提供商使用怎樣的認證方法，因此主體名和驗證數據的內容和格式依不同的認證協議而不同。
安全原則網域（Security Policy Domain）︰也稱安全網域（security domain）或 realm，它是一個邏輯范圍或字段，在這一范圍或字段中安全服務的管理員定義和實施通用的安全原則。它是從安全原則的角度來劃分的字段。比如可以將企業應用系統劃分為企業員工、供貨商、合作伙伴等不同的安全網域，對這些安全字段采用不同的安全原則。
安全技術網域（Security Technology Domain）︰它是從安全技術的角度來劃分的字段，在一個安全技術網域中使用同樣的安全機制來執行安全原則。一個安全技術網域可以包括多個安全原則網域。
安全屬性（Security Attributes）︰每個主體（Principal）都有一系列與之相關的安全屬性。安全屬性可用來存取被保護的資源，檢查使用者的身份和完成其它一些安全相關的用途。J2EE產品提供商或具體的驗證服務的實作來決定怎樣將安全屬性與一個主體連絡起來。J2EE規范并沒有限定什么樣的安全屬性將與主體相連絡。
憑證（Credential）︰憑證包括或參照為J2EE 系統驗證一個主體的驗證訊息（安全屬性）。如果成功的透過了驗證，主體將獲得一個包括安全屬性的憑證。如果被容許的話，一個主體也可能獲取另一個主體的憑證。在這種情況下兩個主體在同一安全網域中具有相同的安全屬性。

三.J2EE的安全架構 1． 基于容器 ( container ) 的安全

在J2EE的環境中，組件的安全是由他們各自的容器來負責的，組件的開發人員幾乎可以不用或者很少在組件中加入有關安全的代碼。這種安全邏輯和商業邏輯相對獨立的架構，使得企業級應用系統有更好的靈活性和擴充性。J2EE規范要求J2EE 產品必須為應用程序開發者提供兩種形式的基于容器的安全性－說明性的安全性和可程序化的安全性。
a. 說明性的安全性
說明性的安全性透過安全結構描述的方式來代表應用程序的安全需求，安全結構一般包括安全角色，存取控制和驗證要求等。在J2EE平臺中布署描述子作為說明的安全性的主要工具。 布署描述子是組件開發者和應用程序布署者或應用程序組裝者之間的交流工具。應用程序的開發者用它來表示應用中的安全需求，應用程序布署者或應用程序組裝者將安全 角色與布署環境中的使用者和群組映射起來。
在程序執行時容器從布署描述子中提取出相應的安全原則，然后容器根據安全原則執行安全驗證。說明的安全性不需要工作人員編寫任何安全相關的 程序代碼，一切都是透過設定布署描述子來完成的。
b. 可程序化的安全性
可程序化的安全性在說明性的安全性的基礎上，使安全敏感的應用可以透過呼叫被容器提供的API來對安全作出決斷。這在說明性的安全性不足以滿足企業的安全模型的情況是非常有用的。J2EE在EJB EjbConext interface和servlet HttpServletRequest interface中各提供兩個方法︰

isCallerInRole (EJBContext) getCallerPrincipal (EJBContext) isUserInRole (HttpServletRequest) getUserPrincipal (HttpServletRequest)

這些方法容許組件根據呼叫者或遠程使用者的安全角色來作出商業判斷。在文章的后面部分將有這些方法的詳細介紹和范例，以便讀者更好的理解可程序化的安全性的用途。

2．J2EE的驗證模型

身份驗證是使用者或組件呼叫者向系統證明其身份的過程。使用者透過某種方式向系統提交驗證訊息（通常是使用者名稱和密碼或者是使用者的數字簽章），系統用使用者提供的驗證訊息和系統的安全原則來驗證使用者的身份。
圖一 初始驗證過程

圖二 驗證URL

圖三 驗證EJB方法呼叫

使用者的驗證
使用者的驗證根據其客戶端類型不同分為兩種︰Web 客戶端的驗證和Application客戶端的驗證
a. Web 客戶端的驗證
Web客戶端通常透過http協議來請求web服務器端的資源，這些web資源通常包括html網頁、jsp（java server page）檔案、java servlet和其它一些二進制或多媒體檔案。在企業環境中，企業的某些資源往往要求只容許某些人存取，有些資源甚至是機密的或安全敏感的。因此對企業中各種web資源進行存取控制是十分必要的。為了滿足企業中的不同安全層級和客戶化的需求，J2EE提供了三種基于web客戶端的驗證方式︰
HTTP基本驗證（HTTP Basic Authentication）
HTTP基本驗證 是HTTP協議所支持的驗證機制。這種驗證機制使用使用者的使用者名稱和密碼作為驗證訊息。Web客戶端從使用者獲取使用者名稱和密碼，然后傳遞他們給web服務器，web服務器在指定的字段（realm）中驗證使用者。但需要注意的是，這種驗證方法是不夠安全的。因為這種驗證方法并不對使用者密碼進行加密，而祇是對密碼進行基本的base64的編碼。而且目標web服務器對使用者來說也是非驗證過的。不能保證使用者存取到的web服務器就是使用者希望存取的。可以采用一些安全措施來克服這個弱點。例如在傳輸層上應用SSL或者在網絡層上使用IPSEC或×××技術。
基于窗體的驗證（Form-Based Authentication）
基于窗體的驗證 使系統開發者可以訂做使用者的登入頁面和錯誤頁面(error pages)。這種驗證方法與基本HTTP的驗證方法的唯一區別就在于它可以根據使用者的要求制定登入和 錯誤頁面。基于窗體的驗證方法同樣具有與基本HTTP驗證類似的不安全的弱點。使用者在窗體中填寫使用者名稱和密碼，而后密碼以明文形式在網絡中傳遞，如果在網絡的某一節點將此驗證請求截獲，在經過反編碼很容易就可以獲取使用者的密碼。因此在使用基本HTTP的驗證方式和基于窗體的驗證方法時，一定確定這兩種方式的弱點對你的應用是可接受的。
基于客戶端證書的驗證（Client-Certificate Authentication）
基于客戶端證書的驗證方式要比上面兩種方式更安全。它透過HTTPS（HTTP over SSL）來保證驗證的安全性。SSL 為驗證過程提供了數據加密，服務器端認證，訊息真實性等方面的安全保證。在此驗證方式中，客戶端必須提供一個公鑰證書，你可以把這個公鑰證書看作是你的 數位護照。公鑰證書也稱數位簽章，它是被稱作證書授權機構（CA）－一個被信任的組織頒發的。這個數字簽章必須符合X509公鑰體系結構（PKI）的標準。如果你指定了這種驗證方式，Web服務器將使用客戶端提供的 數字簽章來驗證使用者的身份。
b. 應用程序客戶端的驗證（Application Client User Authentication）
java客戶端程序是執行在使用者本地java虛擬機器上的java程序，它擁有main方法，通常由使用者可透過java.exe或javaw.exe直接啟動執行。J2EE應用程序客戶端與java客戶端程序相似，也擁有main方法，但他們在執行時存在一定的差別。J2EE應用程序客戶端和其它J2EE組件一樣執行在自己的容器中。使用者透過容器來執行J2EE應用程序客戶端。這樣J2EE應用程序客戶端容器就有機會在J2EE應用程序客戶端被執行之前完成使用者身份的驗證。J2EE提供了一種可訂做的方式來獲取使用者的驗證訊息。可以選擇使用容器提供的 預設的方式來獲取J2EE應用客戶端程序的使用者的驗證訊息，也可以選擇訂做的方式來獲取使用者的驗證訊息。當選擇訂做方式時，應用程序開發者必須提供一個實作了javax.security.auth.callback.CallbackHandler interfce的類別，并且在J2EE布署描述檔application-client.xml中的元素callback-handler中加入這個類別的 類別名。這樣，當系統需要驗證使用者身份時，客戶端程序的容器將布署描述檔中的CallbackHandler實作類別的類別名傳遞給系統的 登入模塊（驗證模塊），登入模塊再案例化這個實作類別。這個類別的案例負責收集使用者驗證訊息，并將收集到的使用者驗證訊息傳遞給登入模塊，登入模塊用這些驗證訊息來驗證使用者。這個實作 類別可以是具有使用者界面的，或是透過要求使用者輸入來收集使用者驗證訊息，也可以是透過指令行來獲取使用者驗證訊息，還可能是透過讀取本地或在線的使用者證書庫來獲取使用者的電子證書。選取哪種方式取決于驗證訊息的儲存方式。
有些J2EE產品廠商把容器的驗證服務和本地系統的驗證服務或其它應用系統產品的驗證服務整合起來，從而在一定的應用系統的范圍內實作單一登入的能力。
單一登入 （Single Sign-On）
單一登入從使用者的角度來看，是指使用者在特定的邏輯安全字段中，只需進行一次登入即可在存取在此邏輯安全字段中不同應用系統中的被授權的資源，祇有超越了安全字段邊緣時 才要求再次 登入。這種能力對多種IT應用系統共存的企業顯得更有價值。隨著企業訊息化建設程度的不斷提高，企業中的應用系統也越來越多。在傳統的應用系統中，各系統各自維護自己的安全原則，這些安全原則典型的包括組織結構定義，安全 角色定義，使用者身份驗證，資源存取控制等。由于各系統互相獨立，一個使用者在使用每一應用系統之前，都必須按照相應的系統身份進行系統 登入。這對于使用者來說必須記住每一個系統的使用者名稱和密碼，給使用者帶來了不小的麻煩。針對于這種情況，單一登入的概念隨之產生，并不斷的應用到企業的應用系統的整合當中。J2EE1.3也在規范中建議J2EE產品應為應用系統提供單 一登入的能力。但J2EE1.3規范并沒有規定J2EE產品應遵循何種標準，因此不同的廠商的產品在單一登入上的實作和應用各不相同。有的J2EE產品實作了在本產品環境范圍內的單 一登入，有的實作了特定系統環境之間的單一登入（如IBM WebSphere Application 4.0 AE 實作了WebSphere Application Server與WebSphere Application Server、WebSphere Application Server與Lotus Domino server 之間的單一登入能力）。在J2EE中單一登入是透過傳遞憑證（Credential）來實作的。當使用者進行系統登入時，客戶端容器（包括WEB客戶端和應用程序客戶端）根據使用者的憑證（Credential）為使用者建立一個安全 性內容（security Context），安全性內容包括用于驗證使用者的安全信息，系統用這個安全性內容和安全原則來判斷使用者是否有存取系統資源的權限。遺憾的是J2EE規范并沒有規定安全 性內容的格式，因此不能在不同廠商的J2EE產品之間傳遞安全性內容。到目前為止還很少有在不同的J2EE產品間互相共享安全性內容，因此在不同J2EE產品間實作單 一登入只能透過第三方產品（如LDAP server等）整合的方式。
惰性驗證（Lazy Authentication）
身份驗證是有代價的。例如，一次驗證過程也許包括多次透過網絡訊息交換。因此惰性驗證就非常有用了。惰性驗證 是當使用者存取受保護的資源時才執行驗證過程，而不是在使用者第一次發起請求時就執行驗證過程。

3. J2EE的授權模型

程序代碼授權（Code Authorization）
J2EE產品透過java 2 安全模型來限制特定J2SE的類別和方法的執行，以保護和確保操作系統的安全。詳細描述請參閱《J2SE規范文件》。
呼叫者授權（Caller Authorization）
安全角色︰安全角色是具有相同安全屬性的邏輯組。它是由應用程序的組裝者（Application Assembler）或應用程序的布署者（Application Deployer）指派的。
安全角色參照
安全角色參照是應用程序提供者（Application Provider）用來參照安全角色的識別數據。應用程序提供者（Application Provider）可以用安全角色參照來為安全角色指派資源存取的權限。也在安全相關的程序代碼中參照安全角色。
使用者和群組
使用者和群組是在實際系統環境下的使用者和使用者的集合。它們對應者現實當中的人和群體
存取控制
存取控制可以確保安全角色只能存取已授予它安全權限的授權對象。授權對象包括EJB的遠程方法、web資源（html網頁，jsp/servlet和多媒體或二進制 檔案）等。在J2EE中存取控制在應用程序描述文件中與安全角色關聯起來。
映射
透過映像應用程序的系統管理員將實際系統環境中的使用者和角色與安全角色連絡起來，讓實際的使用者擁有對企業資源存取的適當授權。
被傳播的呼叫者身份識別數據（Propagated Caller Identities）
在J2EE 1.3中可以選擇用傳播呼叫者識別數據作為web組件和ejb組件呼叫者的識別數據以便進行驗證。在這種方式下，整個ejb組件的呼叫鏈中interface EJBContext的方法getCallerPrincipal傳回相同的主體名（principal name）。如果呼叫鏈中的第一個ejb是被jsp/servlet呼叫的，interface EJBContext的方法getCallerPrincipal傳回的主體名（principal name）應與interface HttpServletRequest的方法getUserPrincipal的 傳回值相同。要注意的是在呼叫鏈中傳遞的是使用者的識別數據，而不是憑證（credentials），這一點非常重要，因為在呼叫鏈的每個節點上使用者可能使用不同的安全屬性。
Run As Identities
J2EE 1.3中提供了容許組件開發者和布署這來指定組件以什么身份執行的方法。符合J2EE1.3規范的產品會提供將組件設定成Run As Identities方式的方法。如果Run As Identities方式被選中，在執行中被設定為Run As Identities的組件的呼叫者不再是呼叫鏈中第一個節點的呼叫者了，而是在布署時被指定的呼叫者。而呼叫鏈中隨后節點的呼叫者也變為與被設定為Run As Identities的組件的呼叫者相同。
圖四 使用者識別數據傳遞

這一部分介紹了J2EE的安全概念，意在使讀者能夠對J2EE在安全方面有一定的了解，后面還會有應用這些概念的具體例子。

結論

J2EE為我們提供了對于驗證和授權的安全服務，在開發基于J2EE的應用時應該盡可能的使用J2EE為我們提供的這些服務。因為祇有遵循J2EE標準，才能使你的應用具有良好的移植性、擴充性和可維護性。祇有在所選J2EE產品不能滿足特定的安全需求時，才應該考慮使用第三方安全產品或自己開發安全服務。

轉載于:https://blog.51cto.com/515632/788603

總結

以上是生活随笔為你收集整理的J2EE 中的安全第一部分 - J2EE安全介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。