JavaServlet,JSP的安全性實現
一個web application 擁有能夠被共享多種資源。經常有許多敏感的信息在沒有保護措施的情況下在開放性網絡上傳輸。在這種環境下，實際上許多web application有一定程度的安全性要求。大多數的servlet containers有明確的機制和結構來達到這種要求。雖然保證和執行的細節可能有些不同，但是，都具有下面的特點：
1.Authentication:通訊實體相互驗證對方的行為是以一個明確的身份在進行的一種機制。
2.Access control for resources：對某組用戶來說，對數據庫的某些操作是受到限制的，或對有些程序強調可用性，完整性或保密性的一種機制。
3.Data Integrity：數據在傳遞過程中保證不被第三方修改的一種機制。
4.Confidentiality or Data Privacy：保證數據只被那些授權使用的用戶使用，能被安全傳遞的一種機制。
Java Servlet, JSP中安全性通過如下幾各方式實現：
一、 Declarative Security
Declarative security指的是表達一個應用的安全結構，包括角色，存取控制，和在一個應用的外部表單所要求的驗證。在web application中發布描述器是實施declarative security的一種主要的工具。
發布者把application所要求的邏輯完整性映射為在特定運行環境下的安全策略。在運行時，servlet container使用這些策略來強迫驗證。
二 、Programmatic Security
當declarative security不能夠完全表達一個application的安全模型時，就可以使用programmatic Security。Programmatic Security包括HttpServletRequest接口的下列方法：
getRemoteUser
isUserInRole
getUserPrincipal
getRemoteUser方法返回經過客戶端驗證的用戶名。IsUserInRole向container的安全機制詢問一個特定的用戶是否在一個給定的安全角色中。GetUserPrinciple方法返回一個java.security.Pricipal對象。這些APIs根據遠程用戶的邏輯角色讓servlet去完成一些邏輯判斷。它也可以讓servlet去決定當前用戶的主要名字。如果getRemoteUser返回null值（這意味著沒有用戶被驗證），那么isUserInRole就總會返回false，getUserPrinciple總會返回null。
三 、Roles
一個Roles就是由Application Developer和Assembler所定義的一個抽象的邏輯用戶組。當一個application被發布的時候，Deployer就把這些角色映射到在運行環境中的安全認證，例如組或規則。
一個servlet container能夠為規則執行一些說明或編程安全，這些規則是與調用這些principal的安全屬性所輸入的要求相聯系的。例如：
1． 當deployer把一個安全角色映射為操作環境下的一個用戶組，調用principle所屬的用戶組就從安全屬性中獲得。如果principle的用戶組與在操作環境下的用戶組相匹配，那么principle 就是一個安全角色。
2． 當deployeer把一個安全角色映射為一個在安全方針域中的principle名時，調用principle的確principle名就被從安全屬性中提取出來。如果兩者相同的話，調用的principle就是安全的。
四、Authentication
一個web 客端能夠使用下面的一種機制來對web 服務器驗證一個用戶。
HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication
五、HTTP Basic Authentication
HTTP Basic Authentication是一個定義在HTTP/1.1規范中的驗證機制。這種機制是以用戶名和密碼為基礎的。一個web server要求一個web client去驗證一個用戶。作為request的一部分，web server 傳遞被稱之為realm的字符串，用戶就是在它里面被驗證的。注意：Basic Authentication機制的realm字符串不一定反映任何一種安全方針域。Web client得到這些用戶名和密碼，然后把它傳遞給web server。Web server然后在一個特定的領域驗證這些用戶。
由于密碼是使用一種64位的編碼來傳遞，而且目的server沒有驗證，所以Basic Authentication不是一種安全的驗證協議。然而一些附加的保護像使用一種安全傳輸機制（HTTPS）或在網絡層使用安全措施能夠解決一些問題。
六、HTTP Digest Authentication
與HTTP Digest Authentication一樣，HTTP Digest Authentication根據用戶名和密碼驗證一個用戶。然而密碼的傳輸是通過一種加密的形式進行的，這就比Basic Authentication所使用的64位編碼形式傳遞要安全的多。這種方法沒有像HTTPS Client Authentication的個人密鑰方案安全。由于Digest Authentication當前不被廣泛使用，servlet containers不要求支持它但是鼓勵去支持它。
七、HTTPS Client Authentication
使用HTTPS（HTTP over SSL）的終端用戶驗證是一種嚴格非驗證機制。這種機制要求用戶去處理公共密鑰證明（Public Key Certification PKC）。當前，PKCs在e-commerce應用中是有用的。不適應J2EE的servlet containers不要求支持HTTPS協議。
八、Server Tracking of Authentication Information
就像映射在角色中的安全標識一樣，運行環境是環境的說明而不是應用的說明。
1． 在web application的發布環境創建一個登錄機制和策略。
2、 對發布在同一個container的application能夠使用同樣的驗證信息來代表這些application的principal。
3、 僅僅當通過安全策略域時要求用戶重新驗證。
因此，一個servlet container要求在container層來跟蹤這些驗證信息，而不是在application層。允許一個經驗證的用戶拒絕一個使用其它資源的application，這些是通過受同樣安全性標識限制的container管理的。
1.Authentication:通訊實體相互驗證對方的行為是以一個明確的身份在進行的一種機制。
2.Access control for resources：對某組用戶來說，對數據庫的某些操作是受到限制的，或對有些程序強調可用性，完整性或保密性的一種機制。
3.Data Integrity：數據在傳遞過程中保證不被第三方修改的一種機制。
4.Confidentiality or Data Privacy：保證數據只被那些授權使用的用戶使用，能被安全傳遞的一種機制。
Java Servlet, JSP中安全性通過如下幾各方式實現：
一、 Declarative Security
Declarative security指的是表達一個應用的安全結構，包括角色，存取控制，和在一個應用的外部表單所要求的驗證。在web application中發布描述器是實施declarative security的一種主要的工具。
發布者把application所要求的邏輯完整性映射為在特定運行環境下的安全策略。在運行時，servlet container使用這些策略來強迫驗證。
二 、Programmatic Security
當declarative security不能夠完全表達一個application的安全模型時，就可以使用programmatic Security。Programmatic Security包括HttpServletRequest接口的下列方法：
getRemoteUser
isUserInRole
getUserPrincipal
getRemoteUser方法返回經過客戶端驗證的用戶名。IsUserInRole向container的安全機制詢問一個特定的用戶是否在一個給定的安全角色中。GetUserPrinciple方法返回一個java.security.Pricipal對象。這些APIs根據遠程用戶的邏輯角色讓servlet去完成一些邏輯判斷。它也可以讓servlet去決定當前用戶的主要名字。如果getRemoteUser返回null值（這意味著沒有用戶被驗證），那么isUserInRole就總會返回false，getUserPrinciple總會返回null。
三 、Roles
一個Roles就是由Application Developer和Assembler所定義的一個抽象的邏輯用戶組。當一個application被發布的時候，Deployer就把這些角色映射到在運行環境中的安全認證，例如組或規則。
一個servlet container能夠為規則執行一些說明或編程安全，這些規則是與調用這些principal的安全屬性所輸入的要求相聯系的。例如：
1． 當deployer把一個安全角色映射為操作環境下的一個用戶組，調用principle所屬的用戶組就從安全屬性中獲得。如果principle的用戶組與在操作環境下的用戶組相匹配，那么principle 就是一個安全角色。
2． 當deployeer把一個安全角色映射為一個在安全方針域中的principle名時，調用principle的確principle名就被從安全屬性中提取出來。如果兩者相同的話，調用的principle就是安全的。
四、Authentication
一個web 客端能夠使用下面的一種機制來對web 服務器驗證一個用戶。
HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication
五、HTTP Basic Authentication
HTTP Basic Authentication是一個定義在HTTP/1.1規范中的驗證機制。這種機制是以用戶名和密碼為基礎的。一個web server要求一個web client去驗證一個用戶。作為request的一部分，web server 傳遞被稱之為realm的字符串，用戶就是在它里面被驗證的。注意：Basic Authentication機制的realm字符串不一定反映任何一種安全方針域。Web client得到這些用戶名和密碼，然后把它傳遞給web server。Web server然后在一個特定的領域驗證這些用戶。
由于密碼是使用一種64位的編碼來傳遞，而且目的server沒有驗證，所以Basic Authentication不是一種安全的驗證協議。然而一些附加的保護像使用一種安全傳輸機制（HTTPS）或在網絡層使用安全措施能夠解決一些問題。
六、HTTP Digest Authentication
與HTTP Digest Authentication一樣，HTTP Digest Authentication根據用戶名和密碼驗證一個用戶。然而密碼的傳輸是通過一種加密的形式進行的，這就比Basic Authentication所使用的64位編碼形式傳遞要安全的多。這種方法沒有像HTTPS Client Authentication的個人密鑰方案安全。由于Digest Authentication當前不被廣泛使用，servlet containers不要求支持它但是鼓勵去支持它。
七、HTTPS Client Authentication
使用HTTPS（HTTP over SSL）的終端用戶驗證是一種嚴格非驗證機制。這種機制要求用戶去處理公共密鑰證明（Public Key Certification PKC）。當前，PKCs在e-commerce應用中是有用的。不適應J2EE的servlet containers不要求支持HTTPS協議。
八、Server Tracking of Authentication Information
就像映射在角色中的安全標識一樣，運行環境是環境的說明而不是應用的說明。
1． 在web application的發布環境創建一個登錄機制和策略。
2、 對發布在同一個container的application能夠使用同樣的驗證信息來代表這些application的principal。
3、 僅僅當通過安全策略域時要求用戶重新驗證。
因此，一個servlet container要求在container層來跟蹤這些驗證信息，而不是在application層。允許一個經驗證的用戶拒絕一個使用其它資源的application，這些是通過受同樣安全性標識限制的container管理的。