spring的基本認證和摘要認證

#Basic and Digest Authentication 基本摘要認證

一般會整合到基於form表單的認證的應用中,該應用使用一個基於瀏覽器的用戶接口和web-service.可是,基本認證把密碼看成日常文本運輸,實際上只在無需加密的傳輸層使用,如https.

##16.1 BasicAuthenticationFilter

BasicAuthenticationFilter 被用來處理在http頭部的基本認證資格.它用來驗證spring的遠程協議(例如Hessian,Burlap),以及通常的瀏覽器用戶代理.http基本認證是由RFC1945,11節來定義的,BasicAuthenticationFilter也是有RFC來定義的.基本認證是一個很是吸引人的認證,由於它的用戶代理和實現的部署很是簡單.(只須要把用戶名:密碼用base64來加密,在http的header中指定便可).

###16.1.1 Configuration 你須要在你的攔截鏈裏配置BasicAuthenticationFilter.應用的上下文應該包含BasicAuthenticationFilter及其必要的協助對象.

<bean id="basicAuthenticationFilter"
class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter">
<property name="authenticationManager" ref="authenticationManager"/>
<property name="authenticationEntryPoint" ref="authenticationEntryPoint"/>
</bean>

<bean id="authenticationEntryPoint"
class="org.springframework.security.web.authentication.www.BasicAuthenticationEntryPoint">
<property name="realmName" value="Name Of Your Realm"/>
</bean>

AuthenticationManager處理每一個認證請求.若是authentication失敗,那麼配置的AuthenticaionEntryPoint將重試認證過程.一般你要和BasicAuthenticationEntryPoint一塊兒使用,它會返回401的響應並附帶一個合適的頭來重試Http基本認證.若是認證成功,那麼生成的Authentication對象將放到SecurityContextHolder中.

若是認證成功或不進行認證嘗試時(當http頭不包含支持認證的請求),那麼攔截鏈會繼續.當認證失敗攔截鏈會中斷,且AuthenticationEntryPoint被回調.

##16.2 DigestAuthenticaitonFilter

摘要認證處理器用來處理http頭部的摘要認證消息.摘要認證主要用來解決基本認證的弱點,特別是保證認證證書在傳輸中不以文本形式發送.許多用戶代理支持摘要認證,如Firefox,IE.HTTP Digest標準是由RFC 2617來定義的.spring security的DigestAuthenticationFilter兼容了RFC 2617的'auth'級別的防禦,但對2069的作了兼容.Digest認證吸引點:使用不加密的http協議,你就能夠作到最大程度的安全認證.另外,Digest認證是WebDAV協議的必需品.

你不該該在如今的應用中是用Digest,由於你須要以日常文本,加密或者MD5的方式存儲密碼.這些存儲方式被認爲是不安全的.相反,你須要使用一種方式來適配密碼哈希.

摘要認證的核心是一個"nonce",這是服務器產生的值.spring security的nonce適配如下格式.

base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))
expirationTime:   The date and time when the nonce expires, expressed in milliseconds
key:              A private key to prevent modification of the nonce token

DigestAuthenticationEntryPoint有一個屬性來指定nonce令牌的key值,用nonceValiditySeconds來指定過時時間.diges是經過各類字符串進行計算的,包括用戶名,密碼,nonce,請求路徑,客戶端的nonce,real名稱等,而後執行MD5的散列.當服務器和用戶代理同事執行摘要計算時,若是接受到的數據不同(如密碼不被接受),會產生不一樣結果.spring實現中,服務器產生的nonce不多過時,DigestAuthenticationEntryPoint會發送一個"stale=true"的頭.它告訴瀏覽器不須要打擾用戶(假設用戶名,密碼正確),只需從新申請一個新的nonce值.

DigestAuthenticationEntryPoint的nonceValiditySeconds的值取決於你的應用.很是重視安全的應用應該注意一個攔截認證頭能夠被模擬用戶直到nonce中的expirationTime過時.這個是一個選擇合適設置的關鍵點,可是對於不在TLS/https上運行的應用來講,這個極大的不安全.

由於有不少Digest認證的複雜實現,全部大部分是瀏覽器問題.例如,在相同的session下,IE沒法在隨後的請求中提供一個'opaque'令牌.spring security所以會將全部狀態信息封裝到'nonce'中.在咱們測試中,spring security的實現和fireFox,IE協助中,會正確的處理nonce超時.

###16.2.1 Configuration 在攔截鏈中定義DigestAuthenticationFilter.

<bean id="digestFilter" class=
	"org.springframework.security.web.authentication.www.DigestAuthenticationFilter">
<property name="userDetailsService" ref="jdbcDaoImpl"/>
<property name="authenticationEntryPoint" ref="digestEntryPoint"/>
<property name="userCache" ref="userCache"/>
</bean>

<bean id="digestEntryPoint" class=
	"org.springframework.security.web.authentication.www.DigestAuthenticationEntryPoint">
<property name="realmName" value="Contacts Realm via Digest Authentication"/>
<property name="key" value="acegi"/>
<property name="nonceValiditySeconds" value="10"/>
</bean>

配置UserdetailsService是必須的,由於DigestAuthenticationFilter必須直接訪問一個用戶清晰的文本密碼.若是你在你的DAO中使用編碼密碼,Digest Authentication則不會工做.DAO的寫做者,UserCache,通常會和DaoAutnenticationProvider共享.這個authenticationEntryPoint屬性必須是DigestAuthenticationEntryPoint,這樣DigestAuthenticationFilter 纔會在摘要計算中獲取正確的realName和key.

認證成功,則在SecurityContextHolder中授予正確的Authentication請求token.若是沒有觸發攔截或攔截不成功,攔截鏈繼續進行.其餘狀況觸發了但驗證失敗,則攔截鏈會中斷,並調用AuthenticationEntryPoint.