❶ JCA難發嗎
難發的。因為JCA是平台的一個主要部分，包含一個「Provider」體系結構和一組用於數字簽名，消息摘要（哈希），證書和證書驗證，加密（對稱/非對稱塊/流密碼），密鑰生成管理和安全隨機數生成等，比較重要的所以不好發的。
Java語言是一種非常適用於網路編程的語言，它的基本結構與C++極為相似，但拋棄了C/C++中指針等內容，同時它吸收了Smalltalk、C++面向對象的編程思想。它具有簡單性、魯棒性、可移植性、動態性等特點。這些特點使得Java成為跨平台應用開發的一種規范，在世界范圍內廣泛流傳。 加密Java源碼的原因 Java源代碼經過編譯以後在JVM中執行。由於JVM界面是完全透明的，Java類文件能夠很容易通過反編譯器重新轉換成源代碼。因此，所有的演算法、類文件等都可以以源代碼的形式被公開，使得軟體不能受到保護，為了保護產權，一般可以有以下幾種方法： (1)"模糊"類文件，加大反編譯器反編譯源代碼文件的難度。然而，可以修改反編譯器，使之能夠處理這些模糊類文件。所以僅僅依賴"模糊類文件"來保證代碼的安全是不夠的。 (2)流行的加密工具對源文件進行加密，比如PGP(Pretty Good Privacy)或GPG(GNU Privacy Guard)。這時，最終用戶在運行應用之前必須先進行解密。但解密之後，最終用戶就有了一份不加密的類文件，這和事先不進行加密沒有什麼差別。 (3)加密類文件，在運行中JVM用定製的類裝載器(Class Loader)解密類文件。Java運行時裝入位元組碼的機制隱含地意味著可以對位元組碼進行修改。JVM每次裝入類文件時都需要一個稱為ClassLoader的對象，這個對象負責把新的類裝入正在運行的JVM。JVM給ClassLoader一個包含了待裝入類(例如java.lang.Object)名字的字元串，然後由ClassLoader負責找到類文件，裝入原始數據，並把它轉換成一個Class對象。 用戶下載的是加密過的類文件，在加密類文件裝入之時進行解密，因此可以看成是一種即時解密器。由於解密後的位元組碼文件永遠不會保存到文件系統，所以竊密者很難得到解密後的代碼。 由於把原始位元組碼轉換成Class對象的過程完全由系統負責，所以創建定製ClassLoader對象其實並不困難，只需先獲得原始數據，接著就可以進行包含解密在內的任何轉換。 Java密碼體系和Java密碼擴展 Java密碼體系(JCA)和Java密碼擴展(JCE)的設計目的是為Java提供與實現無關的加密函數API。它們都用factory方法來創建類的常式，然後把實際的加密函數委託給提供者指定的底層引擎,引擎中為類提供了服務提供者介面在Java中實現數據的加密/解密，是使用其內置的JCE(Java加密擴展)來實現的。Java開發工具集1.1為實現包括數字簽名和信息摘要在內的加密功能，推出了一種基於供應商的新型靈活應用編程介面。Java密碼體系結構支持供應商的互操作,同時支持硬體和軟體實現。 Java密碼學結構設計遵循兩個原則: (1)演算法的獨立性和可靠性。 (2)實現的獨立性和相互作用性。 演算法的獨立性是通過定義密碼服務類來獲得。用戶只需了解密碼演算法的概念,而不用去關心如何實現這些概念。實現的獨立性和相互作用性通過密碼服務提供器來實現。密碼服務提供器是實現一個或多個密碼服務的一個或多個程序包。軟體開發商根據一定介面,將各種演算法實現後,打包成一個提供器,用戶可以安裝不同的提供器。安裝和配置提供器,可將包含提供器的ZIP和JAR文件放在CLASSPATH下,再編輯Java安全屬性文件來設置定義一個提供器。Java運行環境Sun版本時, 提供一個預設的提供器Sun。 下面介紹DES演算法及如何利用DES演算法加密和解密類文件的步驟。 DES演算法簡介 DES(Data Encryption Standard)是發明最早的最廣泛使用的分組對稱加密演算法。DES演算法的入口參數有三個：Key、Data、Mode。
❸ 用Java實現IDEA數據加密解密
隨著Internet的迅速發展,電子商務的浪潮勢不可擋，日常工作和數據傳輸都放在Internet網上進行傳輸,大大提高了效率,降低了成本,創造了良好的效益。但是,由於Internet網路協議本身存在著重要的安全問題(IP包本身並不繼承任何安全特性,很容易偽造出IP包的地址、修改其內容、重播以前的包以及在傳輸途中攔截並查看包的內容),使網上的信息傳輸存在巨大的安全風險電子商務的安全問題也越來越突出。加密是電子商務中最主要的安全技術,加密方法的選取直接影響電子商務活動中信息的安全程度，在電子商務系統中,主要的安全問題都可以通過加密來解決。數據的保密性可通過不同的加密演算法對數據加密來實現。
對我國來講，雖然可以引進很多的外國設備，但加密設備不能依靠引進，因為它涉及到網路安全、國家機密信息的安全，所以必須自己研製。當前國際上有許多加密演算法，其中DES（Data Encryption Standard）是發明最早的用得最廣泛的分組對稱加密演算法，DES用56位蜜鑰加密64位明文，輸出64位密文，DES的56位密鑰共有256 種可能的密鑰，但歷史上曾利用窮舉攻擊破解過DES密鑰，1998年電子邊境基金會（EFF）用25萬美元製造的專用計算機，用56小時破解了DES的密鑰，1999年，EFF用22小時完成了破解工作，使DES演算法受到了嚴重打擊，使它的安全性受到嚴重威脅。因為JAVA語言的安全性和網路處理能力較強，本文主要介紹使用IDEA（Internation Data Encryption Algorithm ）數據加密演算法在Java環境下實現數據的安全傳輸。
一、IDEA數據加密演算法
IDEA數據加密演算法是由中國學者來學嘉博士和著名的密碼專家 James L. Massey 於1990年聯合提出的。它的明文和密文都是64比特，但密鑰長為128比特。IDEA 是作為迭代的分組密碼實現的，使用 128 位的密鑰和 8 個循環。這比 DES 提供了更多的 安全性，但是在選擇用於 IDEA 的密鑰時，應該排除那些稱為「弱密鑰」的密鑰。DES 只有四個弱密鑰和 12 個次弱密鑰，而 IDEA 中的弱密鑰數相當可觀，有 2 的 51 次方個。但是，如果密鑰的總數非常大，達到 2 的 128 次方個，那麼仍有 2 的 77 次方個密鑰可供選擇。IDEA 被認為是極為安全的。使用 128 位的密鑰，蠻力攻擊中需要進行的測試次數與 DES 相比會明顯增大，甚至允許對弱密鑰測試。而且，它本身 也顯示了它尤其能抵抗專業形式的分析性攻擊。
二、Java密碼體系和Java密碼擴展
Java是Sun公司開發的一種面向對象的編程語言,並且由於它的平台無關性被大量應用於Internet的開發。Java密碼體系(JCA)和Java密碼擴展(JCE)的設計目的是為Java提供與實現無關的加密函數API。它們都用factory方法來創建類的常式,然後把實際的加密函數委託給提供者指定的底層引擎,引擎中為類提供了服務提供者介面在Java中實現數據的加密/解密,是使用其內置的JCE(Java加密擴展)來實現的。Java開發工具集1.1為實現包括數字簽名和信息摘要在內的加密功能,推出了一種基於供應商的新型靈活應用編程介面。Java密碼體系結構支持供應商的互操作,同時支持硬體和軟體實現。Java密碼學結構設計遵循兩個原則:(1)演算法的獨立性和可靠性。(2)實現的獨立性和相互作用性。演算法的獨立性是通過定義密碼服務類來獲得。用戶只需了解密碼演算法的概念,而不用去關心如何實現這些概念。實現的獨立性和相互作用性通過密碼服務提供器來實現。密碼服務提供器是實現一個或多個密碼服務的一個或多個程序包。軟體開發商根據一定介面,將各種演算法實現後,打包成一個提供器,用戶可以安裝不同的提供器。安裝和配置提供器,可將包含提供器的ZIP和JAR文件放在CLASSPATH下,再編輯Java安全屬性文件來設置定義一個提供器。Java運行環境Sun版本時,提供一個預設的提供器Sun。
三、Java環境下的實現
1．加密過程的實現
void idea_enc( int data11[], /*待加密的64位數據首地址*/ int key1[]){
int i ;
int tmp,x;
int zz[]=new int[6];
for ( i = 0 ; i < 48 ; i += 6) { /*進行8輪循環*/
for(int j=0,box=i;j<6;j++,box++){
zz[j]=key1[box];
}
x = handle_data(data11,zz);
tmp = data11[1]; /*交換中間兩個*/
data11[1] = data11[2];
data11[2] = tmp;
}
tmp = data11[1]; /*最後一輪不交換*/
data11[1] = data11[2];
data11[2] = tmp;
data11[0] = MUL(data11[0],key1[48]);
data11[1] =(char)((data11[1] + key1[49])%0x10000);
data11[2] =(char)((data11[2] + key1[50])%0x10000);
data11[3] = MUL(data11[3],key1[51]);
}
2．解密過程的實現
void key_decryExp(int outkey[])/*解密密鑰的變逆處理*/
{ int tmpkey[] = new int[52] ;
int i;
for ( i = 0 ; i < 52 ; i++) {
tmpkey[i] = outkey[ wz_spkey[i] ] ;/*換位*/
}
for ( i = 0 ; i < 52 ; i++) {
outkey[i] = tmpkey[i];
}
for ( i = 0 ; i < 18 ; i++) {
outkey[wz_spaddrever[i]] = (char)(65536-outkey[wz_spaddrever[i]]) ;/*替換成加法逆*/
}
for ( i = 0 ; i < 18 ; i++){
outkey[wz_spmulrevr[i]] =(char)(mulInv(outkey[wz_spmulrevr[i]] ));/*替換成乘法逆*/
}
}
四、總結
在實際應用中,我們可以使用Java開發工具包(JDK)中內置的對Socket通信的支持,通過JCE中的Java流和鏈表,加密基於Socket的網路通信.我們知道,加密/解密是數據傳輸中保證數據完整性的常用方法,Java語言因其平台無關性,在Internet上的應用非常之廣泛.使用Java實現基於IDEA的數據加密傳輸可以在不同的平台上實現並具有實現簡潔、安全性強等優點。
❹ java 加密與解密的藝術怎麼樣
這幾章主要介紹了一些為什麼要加密，加密的歷史原因以及演變過程，並介紹了幾種常見的加密演算法，畫出了對稱與非對稱加密在實際應用中的思維導圖。
（了解到加密技術分為對稱加密，非對稱加密，單向加密（散列加密））
（一般單向加密用於提供數據完整性的校驗，使用到的演算法有MD5，SHA1等Hash演算法），（消息認證，鑒權等多用非對稱加密演算法，通過使用數字證書，公鑰私鑰來實現）
另外，JCA 是提供基礎的加密框架，類似於一個工廠，生產密鑰產生器，數字證書，簽名等基礎設施。JCE 是JCA的擴展，也就是加工廠，拿到JCA的基礎設施後，放入一些亂七八糟的演算法，讓產出的產品具有保密性。JSSE 是負責在網路傳輸中加密的，是基於SSL的。
JCE 最後封裝成了一套介面，作為安全提供者介面。據說，它的精髓就是，引擎和演算法。一個演算法是一個引擎的具體實現，例如（provider + rsa演算法）
↑ 這裡面使用到了提供者模式。↑ 即，基礎功能提供者只需要關注提供哪種服務（加密，解密，or anyone else），不需要關心演算法是否又推層出新了。
（據書里說，java.security.Provider 和 java.security.Security 這兩個類是JCE的核心，於是我去翻了翻API）……基本看不到什麼有意思的。
於是人書里繼續說了，其實真的要實現加密解密，還要用javax.crypto里的功能。好吧，這樣就和我見過的匹配上了。所以上面說的核心只是說掌握如何操作，這里的核心是干實事，基層核心。
❺ 常用的java第三方jar包有哪些附上用途的介紹，最好給官方下載連接，和中文文檔
commons-digester.jar
Digester基於規則的XML文檔解析,主要用於XML到Java對象的映射.
commons-beanutils.jar
提供對Java 反射和自省API的包裝.
aspectjweaver.jar
用於在Spring 2.0中集成AspectJ AspectJ LTW織入器
ognl.jar
OGNL是Object-Graph Navigation Language的縮寫，它是一種功能強大的表達式語言（Expression Language，簡稱為EL），通過它簡單一致的表達式語法，可以存取對象的任意屬性，調用對象的方法，遍歷整個對象的結構圖，實現欄位類型轉化等功 能。它使用相同的表達式去存取對象的屬性。
hibernate2依賴的一些包
hibernate2.jar
Hibernate的庫，沒有什麼可說的，必須使用的jar包
cglib-asm.jar:
CGLIB庫，Hibernate用它來實現PO位元組碼的動態生成，非常核心的庫，必須使用的jar包
dom4j.jar:
dom4j是一個Java的XML API，類似於jdom，用來讀寫XML文件的。dom4j是一個非常非常優秀的Java XML API，具有性能優異、功能強大和極端易用使用的特點，同時它也是一個開放源代碼的軟體，可以在SourceForge上找到它。在IBM developerWorks上面可以找到一篇文章，對主流的Java XML API進行的性能、功能和易用性的評測，dom4j無論在那個方面都是非常出色的。我早在將近兩年之前就開始使用dom4j，直到現在。如今你可以看到越 來越多的Java軟體都在使用dom4j來讀寫XML，特別值得一提的是連Sun的JAXM也在用dom4j。這是必須使用的jar 包，Hibernate用它來讀寫配置文件。
odmg.jar:
ODMG是一個ORM的規范，Hibernate實現了ODMG規范，這是一個核心的庫，必須使用的jar包。
commons-collections.jar：
Apache Commons包中的一個，包含了一些Apache開發的集合類，功能比java.util.*強大。必須使用的jar包。
commons-beanutils.jar：
Apache Commons包中的一個，包含了一些Bean工具類類。必須使用的jar包。
commons-lang.jar:
Apache Commons包中的一個，包含了一些數據類型工具類，是java.lang.*的擴展。必須使用的jar包。
commons-logging.jar:
Apache Commons包中的一個，包含了日誌功能，必須使用的jar包。這個包本身包含了一個Simple Logger，但是功能很弱。在運行的時候它會先在CLASSPATH找log4j，如果有，就使用log4j，如果沒有，就找JDK1.4帶的 java.util.logging，如果也找不到就用Simple Logger。commons-logging.jar的出現是一個歷史的的遺留的遺憾，當初Apache極力游說Sun把log4j加入JDK1.4， 然而JDK1.4項目小組已經接近發布JDK1.4產品的時間了，因此拒絕了Apache的要求，使用自己的java.util.logging，這個包 的功能比log4j差的很遠，性能也一般。
後來Apache就開發出來了commons-logging.jar用來兼容兩個logger。因此用commons-logging.jar 寫的log程序，底層的Logger是可以切換的，你可以選擇log4j，java.util.logging或者它自帶的Simple Logger。不過我仍然強烈建議使用log4j，因為log4j性能很高，log輸出信息時間幾乎等於System.out，而處理一條log平均只需 要5us。你可以在Hibernate的src目錄下找到Hibernate已經為你准備好了的log4j的配置文件，你只需要到Apache 網站去下載log4j就可以了。commons-logging.jar也是必須的jar包。
使用Hibernate必須的jar包就是以上的這幾個，剩下的都是可選的。
ant.jar:
Ant編譯工具的jar包，用來編譯Hibernate源代碼的。如果你不準備修改和編譯Hibernate源代碼，那麼就沒有什麼用，可選的jar包
optional.jar：
Ant的一個輔助包。
c3p0.jar：
C3PO是一個資料庫連接池，Hibernate可以配置為使用C3PO連接池。如果你准備用這個連接池，就需要這個jar包。
proxool.jar：
也是一個連接池，同上。
commons-pool.jar,
commons-dbcp.jar:
DBCP資料庫連接池，Apache的Jakarta組織開發的，Tomcat4的連接池也是DBCP。
實際上Hibernate自己也實現了一個非常非常簡單的資料庫連接池，加上上面3個，你實際上可以在Hibernate上選擇4種不同的資料庫 連接池，選擇哪一個看個人的偏好，不過DBCP可能更通用一些。另外強調一點，如果在EJB中使用Hibernate，一定要用App Server的連接池，不要用以上4種連接池，否則容器管理事務不起作用。
connector.jar:
JCA 規范，如果你在App Server上把Hibernate配置為Connector的話，就需要這個jar。不過實際上一般App Server肯定會帶上這個包，所以實際上是多餘的包。
jaas.jar:
JAAS是用來進行許可權驗證的，已經包含在JDK1.4裡面了。所以實際上是多餘的包。
jcs.jar：
如果你准備在Hibernate中使用JCS的話，那麼必須包括它，否則就不用。
jdbc2_0-stdext.jar:
JDBC2.0的擴展包，一般來說資料庫連接池會用上它。不過App Server都會帶上，所以也是多餘的。
jta.jar：
JTA規范，當Hibernate使用JTA的時候需要，不過App Server都會帶上，所以也是多餘的。
junit.jar:
Junit包，當你運行Hibernate自帶的測試代碼的時候需要，否則就不用。
xalan.jar, xerces.jar, xml-apis.jar:
Xerces是XML解析器，Xalan是格式化器，xml-apis實際上是JAXP。一般App Server都會帶上，JDK1.4也包含了解析器，不過不是Xerces，是Crimson，效率比較差，不過Hibernate用XML只不過是讀取 配置文件，性能沒什麼緊要的，所以也是多餘的。
antlr.jar
語法生成工具詳見
❻ 什麼是JCA
JCA(J2EE Connector Architecture, 也縮寫為，J2C， J2CA)，是J2EE平台上連接傳統系統的一個技術規范。JCA1.0提供了出站操作，1.5提供了消息流入和事務流入，以及生命周期管理和工作管理等系統契約。但是由於JCA尚未規定統一的元數據獲取方式，開發工具對JCA的支持還很有限。各廠商對JCA的支持也不足，因此JCA在通用性和廣泛接受方面存在不足。
❼ 如何用JAVA實現CA認證
by fleshwound (http://www.smatrix.org)
(註：這是我們的完整設計中的一部分，其它有些部分尚要求保密，希望這個拙文能給做J2EE項目的兄弟們帶來點幫助,有任何關於JAVA安全和密碼學理論和應用的問題可以來我們的論壇:http://bbs.smatrix.org)
近年來，隨著互連網和計算機的普及，電子商務和電子政務成為當今社會生活的重要組成部分，以網上訂購和網上在線支付的為主要功能的網店系統(Web Shop System)是目前電子商務的熱門技術。
JAVA以它「一次編譯，處處運行」的神奇魅力和強大的安全技術支持，很快成為WEB信息系統開發的首選語言，而J2EE就是為了WEB應用開發而誕生的。目前J2EE的應用大部份都是多層結構的, 良好的分層可以帶來很多好處，例如可以使得代碼結構清晰，方便組件復用，可以快速適應應用的新需求。同時，JAVA還提供了強大的安全技術(例如:JCA,HTTPS,JSSA等)。對於電子商務系統而言,系統平台的安全性和效率是其中的核心問題,而這些正好是J2EE及其相關技術的強項。
0 系統中所要使用的API及其特點介紹
該系統中主要使用的技術和特點如下:
(1)EJB :主要是作為J2EE中間層，完成商業邏輯。目前主要有三種類型的EJB: 會話 Bean (Session Bean)、實體Bean (Entity Bean)、消息驅動的Bean（MDB）；
(2)JAAS:在J2EE 中用於處理認證和授權服務，進行資源控制；
(3)JSP和Java Servlets:用於J2EE的表示層，生成用戶界面；
(4)JDBC:用於資料庫（資源層）的連接和與資料庫進行交互；
(5)JNDI:Java命名和目錄介面,該API實際上是用來訪問J2EE的所有資源；
(6)JMS:Java消息傳輸服務，配合MDB使用。
1 Session的安全問題與解決方案
在項目中,保存Session一般有兩種方法，一是分別放在客戶端，一是集中放在伺服器端。在客戶端保存Session是指將Session的狀態串列化，然後嵌入到返回給客戶的HTML頁面中。當Session中的信息很少時，這樣實現比較容易，另外這種方法還消除了跨越多個伺服器復制狀態的問題。
但是在客戶端保存Session狀態時，必須考慮到由此帶來的安全問題，因為黑客可能通過嗅探攻擊（Sniffer）獲取敏感信息。為了不讓敏感信息數據暴露，解決的方法是對數據進行加密或者使用HTTPS，採用SSL技術。
如果是要保存大量Session狀態的應用，最好的方法是將Session狀態統一放在伺服器端。當狀態被保存在伺服器上時，不會有客戶端Session管理的大小和類型限制。此外，還避免了由此帶來的安全問題，而且也不會遇到由於在每個請求間傳送Session狀態帶來的性能影響，但是對伺服器的性能要求比較高。網店系統的安全性要求較高，因此Session還是集中放在中間層伺服器端,同時對客戶端到伺服器端採用SSL連接。
2客戶端的緩存安全設計
大部分顧客使用的WEB瀏覽器將瀏覽過的頁面緩存在磁碟上，這樣我們瀏覽網頁的時候不需要重新向伺服器發出HTTP請求，對於普通的網頁不存在安全問題。但是對於需要保密的WEB應用，會帶來安全隱患和泄漏隱私，因此對於客戶端緩存，也必須做適當的處理。最好的方法就是禁止使用緩存，但是對於大部分顧客而言，要求在客戶端不用緩存是不現實的，因此我們必須在中間層解決該問題，方法是採用Servlet過濾器技術。該技術是Servlet2.3以後才出現的，在J2EE中的應用很廣泛。要使用該技術，需要執行以下步驟：
（1） 編寫一個Servlet過濾器，實現javax.servlet.Filter介面；
（2） 修改Web.xml文件，使容器知道過濾器在什麼時候被調用。
Javax.servlet.Filter主要有3個方法：
(1)init(FilterConfig cfg) :當開始使用 servlet 過濾器服務時，容器調用此方法一次。傳送給此方法的 FilterConfig 參數包含 servlet 過濾器的初始化參數；
(2)destroy() :當不再使用 servlet 過濾器服務時，容器調用此方法；
(3)doFilter(ServletRequest req, ServletResponse res, FilterChain chain): 容器為每個映射至此過濾器的 servlet 請求調用此方法，然後才調用該 servlet 本身。傳送至此方法的 FilterChain 參數可用來調用過濾器鏈中的下一個過濾器。當鏈中的最後一個過濾器調用 chain.doFilter() 方法時，將運行最初請求的 servlet。因此，所有過濾器都應該調用 chain.doFilter() 方法。如果過濾器代碼中的附加認證檢查導致故障，則不需要將原始 servlet 實例化。在這種情況下，不需要調用 chain.doFilter() 方法，相反，可將其重定向至其它一些錯誤頁面。
如果 servlet 映射至許多 servlet 過濾器，則按照應用程序的部署描述符（web.xml）中的先後出現的次序來調用 servlet 過濾器。這一部分的主要代碼如下：
//要引入的類庫
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.*;
import java.security.*;
//設置servlet過濾代碼段
public class CacheFilter implements Filter {
protected FilterConfig filterConfig;
private String cachetp;
//初始化
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
cachetp=config.getInitParameter("CacheControlType");
if (cachetp==null)
{
throw new ServletException("沒有定義Cache控制類型");
}
}
//
public void destroy()
{
this.filterConfig = null;
}
//執行過濾器部分
public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain)
throws IOException, ServletException {
if (response instanceof HttpServletResponse )
{
HttpServletResponse resp=(HttpServletResponse) response;
resp.addHeader("Cache-Control",cachetp);
}
else
{
throw new ServletException("非法相應!");
}
chain.doFilter(request, response);
}
}
以下是在Web.xml中添加的對應的內容
CacheFilter
CacheFilter
Cache filter
CacheControlType
no-store
CacheFilter
/cachecontrol
3視圖訪問的安全設置
所有用戶都必須登陸，只有登陸才可以看到用戶的角色和許可權相對應的視圖。因此一個重要的問題就是如何防止一個視圖或者部分的視圖被一個未被授權的客戶直接訪問。
在一些情況下，資源被限制為完全不允許某些用戶訪問,例如：管理後台就不應該讓普通顧客會員訪問。有幾個方法可以做到這一點。一個方法是加入應用邏輯到處理控制器或者視圖的程序中，禁止某些用戶訪問。另一個方案是設置運行時的系統，對於一些資源，僅允許經由另一個應用資源內部調用。在這種情形，對於這些資源的訪問必須被通過另一個表現層的應用資源進行，例如一個servlet控制器。對於這些受限制的資源不允許通過瀏覽器直接調用。
在J2EE中，可以利用Web容器中內置的安全技術來進行角色訪問資源的控制。根據最新版本的servlet和EJB規范，安全限制在web.xml的配置描述文件中描述，我們可以通過配置web.xml來控制角色訪問，修改配置描述文件web.xml就可以達到快速修改安全策略的目的。
安全限制允許使用編程的方法根據用戶的角色來控制訪問。資源可以被某些角色的用戶訪問，同時禁止其它的角色訪問。另外，某個視圖的一部分也可以根據用戶的角色來限制其訪問。如果某些資源完全不允許來自於瀏覽器的直接訪問，那麼這些資源可以配置只允許一些特殊的安全形色訪問，而這些安全形色不分配給任何一個用戶。這樣只要不分配這個安全形色，那麼以這種方式配置的資源將禁止所有的瀏覽器直接訪問。下面一個例子就是web.xml配置文件的一部分，它定義了一個安全的角色以限制直接的瀏覽器訪問。角色的名字是「vip」，受限制資源的名字是specialgood1.jsp、specialgood2.jsp、specialgood3.jsp和bookinfo.jsp。除非一個用戶或者組被分配到「vip」角色，否則這些客戶都不可以直接訪問這些JSP頁面。不過，由於內部的請求並不受這些安全的限制，一個初始時由某servlet控制器處理的請求將會導向到這些受限制的頁面，這樣它們就可以間接訪問這些JSP頁面。
＜security-constraint＞
＜web-resource-collection＞
＜web-resource-name＞specialgood ＜/web-resource-name＞
＜description＞special good infomation＜/description＞
＜url-pattern＞/shop/jsp/a1/specialgood1.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/specialgood2.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/specialgood3.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/bookinfo.jsp＜/url-pattern＞
＜http-method＞GET＜/http-method＞
＜http-method＞POST＜/http-method＞
＜/web-resource-collection＞
＜auth-constraint＞
＜role-name＞vip＜/role-name＞
＜/auth-constraint＞
＜/security-constraint＞
3 各層次間的耦合問題與解決策略
表現層的數據結構，例如HttpServletRequest，應該被限制在表現層上。如果將這些細節放到其它層(主要是業務邏輯層)中，將大大降低了代碼的的重用性，令代碼變得復雜，並且增加了層間的耦合。解決方法一個常用方法是不讓表現層的數據結構和商業層共享，而是拷貝相關的狀態到一個更常見的數據結構中再共享。你也可以選擇由表現層數據結構中將相關的狀態分離出來，作為獨立的參數共享。另外在域對象暴露表現層的數據結構，如果將諸如HttpServletRequest的請求處理數據結構和域對象共享，這樣做也會增加了應用中兩個不同方面的耦合。域對象應該是可重用的組件，如果它們的實現依賴協議或者層相關的細節，它們可重用性就很差，同時維護和調試高耦合的應用更加困難。成熟的解決方案是不通過傳送一個HttpServletRequest對象作為一個參數，而是拷貝request對象的狀態到一個更為常用的數據結構中，並且將這個對象共享給域對象。你也可以選擇由HttpServletRequest對象中將相關的狀態分離出來，並且將每一個的狀態作為一個獨立的參數提供給域對象。
4 EJB的安全設計與控制
EJB的執行過程一般是這樣的：(1)客戶端通過JNDI檢索Home對象的引用；(2)JNDI返回Home對象的引用；(3)請求創建一個新的EJB對象；(4)創建EJB對象；(5)返回EJB對象；(6)調用商務方法；(7)調用Enterprise Bean.引起EJB的安全問題原因主要存在三個方面:
(1)用包嗅探器(Packet Sniffer)獲取用戶憑證信息並直接調用會話Bean；（2）對實體Bean進行未授權訪問；（3）對消息驅動的Bean的無效訪問(發布惡意或者虛假的消息).
以上安全問題可導致客戶端或者服務端欺騙攻擊和DDOS攻擊。解決問題(1)的方法是使用JAVA中SSL技術來保護通訊，解決(2)的方法是對於實體Bean全部採用本地介面或者採用JAAS(文獻[1])，對於(1)和(2)，我們可以同時採取以下措施：讓容器完成認證並傳輸用戶憑證信息,另外使用聲明性或者程序設計的安全驗證角色。對於問題(3),J2EE並沒有提供一個很好的方案，我們的解決方案是採用數字簽名技術來保證信息來自可信任的源。該方法的結合代碼簡要說明如下,消息採用JMS傳遞：
//客戶端，要用到消息發送者的私鑰進行簽名
...
message.setString("userid",userid);
message.setString("useritem",useritem);
message.setInt("usersn",serialnum);//包含一個序列號
message.setString("usercertid",certid);
String signature=getSignature(userid+":"+useritem+":"+serialnum+":"+certid);
//進行簽名,其中getSignature為簽名函數，要用到消息發送者的私鑰進行簽名，具體密碼學技術可參考文獻[2]；
message.setString("signature",signature);
sendmessage(message);//發送信息
...
//伺服器端
String checkstr=userid+":"+message.getString("useritem")+":"+
message.getInt("usersn")+":"+usercertid;
boolean b_check=checkSignature(checkstr,msg.getString("signature"),
usercertid,userid);
//進行驗證,其中checkSignature為驗證函數，要用到消息發送者的公鑰進行驗證，具體密碼學技術可參考文獻[2]；
5 CA中心與證書的生成
前面我們已經提出在客戶端要使用HTTPS和SSL,因此要建立一個自己的CA中心來管理分發證書,加強客戶端到中間層伺服器端通訊的安全性.建立CA中心的第一步是利用JAVA工具包中的Keytool生成一個X509證書,然後將該證書交由權威CA中心Vertsign簽名,再將該證書設置為根證書,建立自己的CA.每次有新用戶注冊交易的時候，都必須簽發一個用戶獨一無二的證書，關鍵的過程是如何簽發證書.簽發證書的過程如下：
(1)從中間層CA伺服器的密鑰庫中讀取CA的證書：
FileInputStream in=new FileInputStream(ShopCAstorename);
KeyStore ks=KeyStore.getInstance("JKS");
ks.load(in,storepass);
java.security.cert.Certificate c1=ks.getCertificate(alias);
(2)獲得CA的私鑰：
PrivateKey caprk=(PrivateKey)ks.getKey(alias,cakeypass);
(3)從CA的證書中提取簽發者信息：
byte[] encod1=c1.getEncoded();
X509CertImpl shopcimp1=new X509CertImpl(encod1);
X509CertInfo shopcinfo1=(X509CertInfo)shopcimp1.get(X509CertImpl.NAME+
"."+X509CertImpl.INFO);
X500Name issuer=(X500Name)shopcinfo1.get(X509CertInfo.SUBJECT+
"."+CertificateIssuerName.DN_NAME);
(4)獲取待簽發的證書相關信息，與（3）類似；
(5)設置新證書的有效期、序列號、簽發者和簽名演算法：
//設置新證書有效期為1年
Date begindate =new Date();
Date enddate =new Date(begindate.getTime()+3000*24*360*60*1000L); CertificateValidity cv=new CertificateValidity(begindate,enddate);
cinfo2.set(X509CertInfo.VALIDITY,cv);
//設置新證書序列號
int sn=(int)(begindate.getTime()/1000);
CertificateSerialNumber csn=new CertificateSerialNumber(sn);
cinfo2.set(X509CertInfo.SERIAL_NUMBER,csn);
//設置新證書簽發者
cinfo2.set(X509CertInfo.ISSUER+"."+
CertificateIssuerName.DN_NAME,issuer);
//設置新證書演算法
AlgorithmId algorithm =
new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid);
cinfo2.set(CertificateAlgorithmId.NAME+
"."+CertificateAlgorithmId.ALGORITHM, algorithm);
(6)創建證書並簽發：
// 創建證書
X509CertImpl newcert=new X509CertImpl(cinfo2);
// 簽名
newcert.sign(caprk,"MD5WithRSA");
(7)將新證書提供給注冊用戶，並提示安裝,一般的做法是在用戶注冊成功後系統立即返回一個證書對象給中間層某個Servlet，由其返回給用戶。
參考文獻
[1]沈耀,陳昊鵬,李新顏.EJB容器中基於JAAS 的安全機制的實現.[J]:計算機應用與軟體 2004.9 16~18
[2](美)Jess Garms著，龐南等譯. Java安全性編程指南[M].北京:電子工業出版社 2002
[3] http://java.sun.com/j2ee/
[4] 蔡劍,景楠. Java 網路程序設計：J2EE（含1.4最新功能）[M].北京: 清華大學出版社 2003
[5](美)John Bell Tony Loton. Java Servlets 2.3編程指南[M].北京: 電子工業出版社 2002
[6](美)Joseph J.Bambara等著,劉堃等譯. J2EE技術內幕[M].北京:機械工業出版社 2002
[7](美)Li Gong著.JAVA 2平台安全技術——結構、API設計和實現[M].北京: 機械工業出版社 2000
[8](英)Danny Ayers等著,曾國平等譯. Java伺服器高級編程[M].北京：機械工業出版社 2005
[9]http://www.smatrix.org/bbs
[10]http://www.smatrix.cn/bbs
❽ JCA和JCE的區別與聯系
JCE是JCA（Java Cryptography Architecture）的一種擴展。
❾ (java加密解密)如何實現JCE介面的各種演算法
關於如何去實現Provider，官方文檔中有詳細的說明。
請參照：http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Steps
❿ java的安全性比其它編程語言相較如何
不知道樓主問的是哪方面的安全性。
從程序本身來說，java .net這種高級語言都是安全的。
從代碼安全性上來說，java是比較容易被反編譯的，所以java更適合的是運用在b/s的系統之上，代碼至於伺服器中不能被客戶直接訪問。
從應用程序安全性來說，java提供了諸如jca之類的安全框架，恰當的應用能給應用程序提供很好的安全保障。