SCEA - Security

Security package of the Java Platform

• java.security - 包含了提供存取控制管理以及驗證，也包括了有加密的演算操作、訊息摘要、簽章等等。


• java.security.acl - 這已經在Java 1.2當中就被標記為Deprecated，改用上述的package代替了。


• java.security.cert - 用來處理與管理X.509憑證的部分、CRL以及憑證路徑。


• java.security.interfaces - RSA, DSA key 加密使用


• java.security.spec -  for DSA, RSA , dER and X.509 keys and params used in 公開金鑰加密使用


• javax.crypto - 針對資料進行加解密


• javax.crypto.interfaces - Interfaces for Diffie-Hellman public/private keys.


• javax.crypto.spec - for key specifications and algorithm specifications used in crypto


• javax.net.ssl - SSL加密溝通使用


• javax.security.auth - 用來驗證及授權使用，通常這是 JAAS


• javax.security.auth.callback - 提供一些很底層的程序呼叫，取得驗證的資料結果呈現給user


• javax.security.auth.kerberos - 支援Kerberos Network 驗證協定


• javax.security.auth.login - 提供plugin framework 作為驗證使用


• javax.security.auth.spi - LoginModule interface for impl plug-in user authentication moudles


• javax.security.auth.x500 - X.500 Principal and X.500 Private Credentials


• javax.annotation 


• javax.annotation.security


• javax.ejb

• Two Applet Flavors




• Signed




• Signed Applet就是一個具有數位簽章的applet，是從一個特定的發行單位所送發出來的，使用Signed Applet時，使用者可以在第一次載入web browser時移除沙箱化的限制。最常見的誤解就是ㄧ般人都以為java的安全性限制就僅止於Applet，實際上對於安全性管理是可以套用到任何一個class身上的。


• 當每個Java API在執行時若有任何可能潛在的不安全性議題會產生時，這時候JSM ( Java Security Manager)會被呼叫起來，來判定這個行為是否是被允許的，通常是在以下這些類型時運作, ex: 讀寫刪除檔案、開啟等待或接收socket connection、修改一個thread attribute (ex: priority)、或者是修改系統參數( System properties)。不過實際上，JSM不是預設就會執行的，要搭配以下作法才行




• 在main method中第一行就執行 System.setSecurityManager(new SecurityManager());


• Java -Djava.security.manager








• 當上述的做法執行後，JSM就會開始對於要進行運作的class檢查其權限，若該權限不被允許，則會拋出SecurityException




• Unsigned




• Java technoloy environments normally 強加於一個unsigned applet running in a browser，的一些特性詳列如下：






1. Can make network connections only to the host from which it was downloaded.


2. Can utlize only its own code and is not allowed to load libs or define native methods.


3. Can't change thread priority.


4. Can't excute any native code.


5. Can't install software.


6. Can't issue an RMI call to remote on different server .


7. Can't monitor mouse motion.


8. Can't programmatically read or write to the clipboard.


9. Can't read or write local files on the host that is executing it.


10. Can't read the system property - java.home , java.class.path,user.name,user.home,user.dir


11. Can't send mail to a server other than the host from which it was downloaded.


12. Can't start any program on the local host.


13. Can't talk to a serial or parallel port.


14. Can't use System.setOut , setErr


15. Can't use Preferences , Reflection APIs.

Potential policies for controlling access to an authentication context are listed here:

• Once the user performs an autehntication , the processes the user invokes inherit access to the authentication context.


• When a component is authenticated, access to the authentication context may be available to other trusted components.


• When a component is expected to impersonate its caller , the caller delegates its authentication context to the called component.

Java Protection Domains

在某些情況下，各個組之間的溝通是不需驗證的，那是因為已經有預設先建立好的信任機制了。

A protection domain is the name given to a group of components that have this trust established.

如果已經存在於同一個 Protected Domain裏頭的各個系統組件，在彼此進行呼叫時是不需要被再次驗證的，除非是跨不同的domain時則會發出驗證請求，像是以下這個例子

Java Protection Domain

JavaEE container 在JavaEE 環境中提供了驗證的機制與系統邊界(其實這應該說是提供一個驗證的scope)，用來給予JavaEE內部與外部組件之間溝通的驗證使用，在JavaEE環境中有時候會包含有多個protection domains延展到多個不同的container的情況。

一般而言，Container是有責任來進行物件之間method call的身分驗證，並且管理這些受保護的 protection domain邊界。在一個protection domain內的method call，container 傳遞一個已被驗證通過的憑據(credential)給被呼叫的component。這credential可以是一個簡單的identity 或是以X.509憑證形式存放。類似的情況下，當進行一個外部domain的呼叫時，container必須去建立這個identity確保component可以進行呼叫，當一個method call在跨container的環境下運作時，container 會先檢查是否有存在任何已被信任的呼叫的憑證，若有的話則通過，否則這個method call將被拒絕。

有幾個重點要釐清，關於 identity propagation model / identity  delegation model / identity  impersonation model，這三種有不同的意義：

• Propagation Model

Provider 必須判斷到底要不要接受這個被傳遞過來的identities，並將之視為以驗證通過。

• Delegation Model / Impersonation Model

被呼叫的Component是被授予存取權限可去存取呼叫者的authentication context，如此將開這個被呼叫的component可以使用傳遞過來的憑據credentials 來執行呼叫者的工作(也可以說是去扮演呼叫者的工作)

Authentication in the WebContainer   

在Web Container之下，所有的資源包括html , jsp .. etc等等 都是受到保護的(under a protection domain)，當一個browser request送出時，container就會 針對需求的資源去檢視是否受保護並進行相關身分驗證，而這些的資源安全性設定通常是在一開始的DD中設置的，以下是Web Container 支援的幾種驗證機制

• HTTP basic

HTTP basic驗證，web server 驗證使用者身分( principal )主要是透過 user name and passwrod，這裡簡單列舉一下http 交談時的情境

1. sending a HTTP GET request - GET /secure/index.html HTTP/1.1 Host: kim.com


2. Web Container 回傳一個身分驗證的請求 by WWW-Authenticate Header - HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="weblgoic"


3. 使用者輸入帳號密碼，並送出這些帳號資訊透過一個特殊的Header,把"帳號,密碼"這樣一組資訊送出，經過base64編碼，如下例； Get /secure/declarative.html HTTP/1.1 Host : kim.com  Authorization: Basic c31zdGvtOnBhc3N3b3Jk


4. Server嘗試驗證這些輸入的帳號密碼是否正確，若錯誤將會再次拋出請求驗證，正確則提供所需要的Resources.

實際上，基本驗證(Basic authentication)是相當的受限制的，因為HTTP 是 stateless protocol，若使用者種機制則必須每次送交需求申請時都得去不斷的驗證，而且密碼並沒有受到加密，雖然有經過base64編碼，但這實在是太容易被解開了，這樣的情況也潛在的促使企業架構必須去處理這些妥協的問責( Compromise of accountability ??  page 11)

為了這些的缺點，所以在實務的作法上，建議是改採用一個加密過的link存取資源以及server authentication，這就是後來的 Digest Authentication.

• HTTP digest

Digest authentication 是basic驗證的改良進階版本，因為他允許client端可以不透過http去傳送一組真實的密碼去流傳，client是透過向server 送出一組degest message(訊息摘要) ，將之包進Http request header裏頭，這種機制很像是一般的basic authentication，事實上 web container 將會回傳一些額外的資訊給client要求驗證。

Web container ack Digest message

如上圖例示，WWW-Authenticate header 包含了 驗證機制的名稱(Digest)，以及 realm (ucny)，還有一些其他的參數等等來要求驗證。而browser client必須拿出user , password , realm, nonce , HTTP method, 還有URI來去做一個摘要計算，最後將算完的結果再用HTTP request送出去...

[caption id="attachment_415" align="alignnone" width="700" caption="digest response"][/caption]

這時候Server端就會依據這些送來的資訊，重新去計算一次digest，看是否與送來的數據相同，如果不一致的話，會直接送出 401 Unauthorized Error，若相同則表示這密碼憑據是合法的並且接著判斷哪些功能是可以授權給使用者使用的,若是未被授權的則會丟出403 Access Denied Error。

• FORM based

對於Form based驗證則是太常見了，不過多了更漂亮的HTML 介面來做驗證即是。不過他也跟basic驗證模式一樣，密碼仍然是明碼的方式在傳遞的(vulnerable，容易被駭)。

• HTTPS mutual

Mutual authentication，X.509憑證是用來建立驗證唯一性的關鍵，通常會走SSL來進行驗證，當然也相對地複雜的很多。

Encrypted Communication

[caption id="attachment_416" align="alignnone" width="581" caption="Async Cryptography"][/caption]

Cryptography 機制通常可區分為兩大類- 對稱式加解密、非對稱式加解密，對稱式加解密就是用同一組key來進行加密、解密的行為，而這樣的key是流通在傳輸端與接收端的。非對稱式的加解密則是以公鑰加密、私鑰解密，或是另一種形式的私鑰加密公鑰解密。

Asymmetric cryptography

在資料交換時，通常會先加密以後，並且伴隨著送出一組hash code 演算結果，當接收方收到data進行解密後，需要再次驗算hash code result是否相符，用以驗證資料完整、正確、唯一性，這跟我在NAA project中用過的 XML Signature是同一個道理的。非對稱式的加密過程是比對稱式加密耗時的，因為非對稱式的key較長，需要更多運算資源，不過現在已經有很多廠商有出SSL硬體加速器了，說不定會把整個效能拉高上來。

Digital Certificates

對於公鑰的傳遞方式一直是個重要的議題，對於公鑰有資格收取的接收者，我們都會認定他是值得信賴的，但若有人是透過非正當性的手法來取得公鑰時，那個人也許就不一定是被信任的，為此我們會將公鑰、私鑰成對的放進一個憑證裡頭，也就是所謂的數位憑證，然後以私鑰簽署給一個信任的第三方單位ex:CA，未來將透過CA這單位來發行憑證，這些數位憑證要如何取得?

使用者們必須透過信任CA，則可以透過CA取得CAs的公鑰，像這樣的機制已經運行很久，大多數的網站與瀏覽器都支援CA。

現今的數位憑證都須至少符合國際電信標準 X.509 v3版本，以下補充X.509的格式參考：

依 X.509 標準，數位憑證必須具備標準化的資訊。特別是，X.509 第 3 版憑證必須包含下列欄位：

• 版本號碼   憑證所符合之 X.509 標準的版本。


• 序號   由憑證授權單位所發行，可用來唯一識別該憑證的號碼。


• 憑證演算法識別碼   憑證授權單位簽署數位憑證時，所使用的特定公開金鑰演算法的名稱。


• 發行者名稱   實際發行憑證之憑證授權單位的身分。


• 有效期限   數位憑證具有效力的期間，包含開始日期與到期日期。


• 主體名稱   數位憑證擁有者的名稱。


• 主體公開金鑰資訊   和數位憑證擁有者關聯的公開金鑰，以及和公開金鑰關聯的特定公開金鑰演算法。


• 發行者唯一識別項   可用來唯一識別數位憑證發行者的資訊。


• 主體唯一識別項   可用來唯一識別數位憑證擁有者的資訊。


• 其他資訊   使用及處理憑證的其他相關資訊。


• 憑證授權單位的數位簽章   使用憑證授權單位的私密金鑰，透過憑證演算法識別項欄位中所指定的演算法，所做出的實際數位簽章。

由於 S/MIME 必須要有 X.509 v3 憑證，因此這項資訊也同時說明了 S/MIME 針對特定憑證所使用的特性。 相關細節可以參考微軟的數位憑證

Secure Sockets Layer

Wow, it was created by Netscape, SSL 這是一個基於安全性所發展出來的通訊協定，避免資料遭到竊聽竊取，SSL提供了資料加密機制、Server side驗證、訊息完整性，Server對於每一次的request都會進行驗證確保是驗證通過的，而且是基於HTTP or FTP之上的一種協定。

SSL使用了一系列的網路交談( handshakes)來建立互信的機制，而相關技術是採用了非對稱式加密以及數位憑證，這樣的網路交談動作handshake會在連線的兩端完成 談判code set之後結束，這個code set當中包括了有 session keys(用來批次進行加解密用)。

SSL的驗證有兩種模式，分別是Mutual and Server。在Mutual驗證模式當中，client nad server 彼此交換數位憑證來確認對方的身分，而Server驗證模式，則是Server送發一個憑證給client，在client端用來建立身分別已表示Server side的身分。

HTTPS running over SSL , typically use port 443 instead of HTTPs default port 80.

Authentication Within the EJB Container

J2EE Setup protection domains

雖然EJB containr有實作了驗證機制，但通常都把驗證的工作都先丟給web container來負責，如上圖所示。

EJB container以及EJB client Containers 支援OMG的CSIv2 protocol。

(OMG: Object Management Group's    CSI: Common Secure Interoperability)

CSIv2是一種標準的線性通訊協定，用來對於進行IIOP 的method call確保其安全，而在這個協定的核心當中， CSIv2 適用模擬的或者是身分確認必然正確(identity assertion)的機制，這種特性是基於目標物對於內部的物件的信任感而成立。

Summary of CSIv2：

• An Interoperable Object Reference (IOR) holds a component that identifies the security mechanisms supported by the object. The IOR also includes information about the transport , client authentication, and identity and authorization tokens.


• 在IOR中的Security 機制是明確的標示的，並且支援由client端所選定的各種形式。


• Client端可以用COBRA  SecurityAttribute Service protocol來建立一個 security context，這個協定用service context紀錄住 request and replies，而 Security context可以支援stateful or stateless。


• CSIv2也支援Generic Security Services API (GSSAPI) initial context tokens, 但為了遵循level0的一致性，只有user name 以及 password是必須依定要支援的。


• CSIv2是在ISO通訊層當中的通訊層進行運作的，SSL也是在這一層。


• 當AP佈署在ap server上時，DD檔標記的內容將會成為CSIv2 policy。

[caption id="attachment_420" align="alignnone" width="648" caption="CSIv2"][/caption]

如果container無法判別method caller的身分別，那麼將會從web.xml當中去找<login-config> tag來查驗。

[caption id="attachment_421" align="alignnone" width="579" caption="security check"][/caption]

其他的還有Basic auth , Digest Auth , Client -Cert

other auth method

如果要使用Form Auth，務必要在Form submit 的action標記為 "j_security_check"，且method必須為POST，使用者帳號與密碼須為 j_username and j_password。當驗證通過時，container會將Session ID以cookie方式傳回給client端，而client端在後續的每一次的request送出時，都會把這個記錄了session id的cookie再送回，用來作為雙方溝通的基準，若是驗證失敗，那麼有標記為<form-error-page>的頁面則會顯示給client。

更多詳細的Form Authentication參考這裡

Authentication in the Enterprise Information System Layer

在JavaEE的環境中，系統通常會與EIS做結合進行溝通，但實際上不可能直接與 EIS做存取管理，一定會有一些替代性的安全性管控方式來操作，這時候就是需要一個第三者來輔助完成這樣的工作，其中著名的就是Container-Managed Resource Manager Sign-on，當然JavaEE也能指定caller的credential，called Application-Managed Resource Manager Sign-on。

在DD檔當中，可以透過<resource-ref>來指定那些resource可被那些caller呼叫，而<res-auth>則是用來指定到底是Container Managed or Application Managed，若設定為Application managed，則可使用getUserPrincipal()  (for web component) or getCallerPrinciple (for ejb component)，去取得caller 的 identity，然後便可將這identity 對應到EIS去做存取需求的處理。

Identity selection的部分，Container可以選用兩種模式，<use-caller-identity> , <run-as>分別為直接委派予caller 的身分，以及以模擬角色的方式在運作。

Authorization

在JavaEE的授權設計上採用兩種方式，宣告式授權或者程式化授權

[caption id="attachment_427" align="alignnone" width="700" caption="Authorized by DD"][/caption]

在使用宣告式授權時，對於EJB端的授權管理，資源可以是remote , home , local home，參考下例：

[caption id="attachment_428" align="alignnone" width="536" caption="Method permission"][/caption]

對於這些受到保護的method，同時也支援那些被overload的其他同名method。

若是對於一些特定的method不想要特別去管控授權，可以使用unchecked來處理。

[caption id="attachment_429" align="alignnone" width="643" caption="unchecked"][/caption]

而對於授權的規則中想要有例外則用這個。

在當使用宣告式的授權受到限制，感覺到不夠靈活時，可以使用程式化授權來處理，對於這部分，Web Container上可以從HttpServletRequest取得 getUserPrincipal() , isUserInRole(), 而在EJB Container上面則可以從EJB Context身上 ( ex: SessionBeanContext)拿到 getCallerPrincipal(), isCallerInRole()。

除了程式進行處理之外，在ejb-jar.xml當中，assembly組件部分也得做一些宣告的對應，如下參考：

Assembly descriptor

Java5 Annotation Facility

在Java5.0之後開始出現的Annotation，現在也已經很活躍的被應用在J2EE的各項設定當中，且承襲使用上的慣例，若有某個Object Value有使用Annotation賦予值，而且又同時在Deployment Descriptor中設置述職的話，那麼在DD檔中的設置是具有較高的優先權的。

在Web app上使用的Annotation:

1. Declare roles for the EJB module using @DeclareRoles

2. Set the security identity using @RunAs

在EJB上使用的Annotation:

1. Declare roles for the EJB module using @SecurityRoles

2. Assign roles to the bean class and/or bean methods with @MethodPermissions

3. Override bean role permissions to allow unrestricted access with @Unchecked

4. Disable access to a business method with @Exclude

5. Set the Security identity of a bean with @RunAs