j2ee安全介绍--转
一.簡介
現在越來越多的企業應用構建在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． 基于容器的安全
在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或VPN技術。
基于表單的驗證（Form-Based Authentication）
基于表單的驗證 使系統開發者可以自定義用戶的登陸頁面和報錯頁面。這種驗證方法與基本HTTP的驗證方法的唯一區別就在于它可以根據用戶的要求制定登陸和出錯頁面。基于表單的驗證方法同樣具有與基本HTTP驗證類似的不安全的弱點。用戶在表單中填寫用戶名和密碼，而后密碼以明文形式在網路中傳遞，如果在網路的某一節點將此驗證請求截獲，在經過反編碼很容易就可以獲取用戶的密碼。因此在使用基本HTTP的驗證方式和基于表單的驗證方法時，一定確定這兩種方式的弱點對你的應用是可接受的。
基于客戶端證書的驗證（Client-Certificate Authentication）
基于客戶端證書的驗證方式要比上面兩種方式更安全。它通過HTTPS（HTTP over SSL）來保證驗證的安全性。安全套接層（Secure Sockets Layer）為驗證過程提供了數據加密，服務器端認證，信息真實性等方面的安全保證。在此驗證方式中，客戶端必須提供一個公鑰證書，你可以把這個公鑰證書看作是你的數字護照。公鑰證書也稱數字證書，它是被稱作證書授權機構（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、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產品不能滿足特定的安全需求時，才應該考慮使用第三方安全產品或自己開發安全服務。
來源：http://www.ibm.com/developerworks/cn/java/l-j2eeSecurity/
轉載于:https://www.cnblogs.com/davidwang456/p/3818810.html
總結
以上是生活随笔為你收集整理的j2ee安全介绍--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： WebLogic Server的单点登陆
- 下一篇： Tomcat源码分析--转