用SSL保護你的站點
在日常使用在線站點時，你很可能已經聽說或使用過SSL。安全套接字層（SSL）協議，以及其后續的傳輸層安全（TLS），被用來為網絡上的HTTP事務提供傳輸層的安全——它們被稱為安全的HTTP事務（HTTPS）。
簡而言之，SSL和TLS以一種對用戶透明的方式保護原始的HTTP傳輸數據，這些數據在客戶端瀏覽器和web服務器之間傳輸。但是作為開發人員，在設計安全站點時，規划使用SSL是很重要的。Spring Security提供了一系列的配置選項可以靈活的將SSL集成到web應用中。
【盡管SSL和TLS是不同的協議（TLS是更成熟的協議），單數大多數人更熟悉SSL這個術語，所以在本書的剩余部分，我們使用這個術語來代指SSL和TLS兩個協議。】
詳細介紹SSL協議的機制已經超出了本書的范圍，有一些很好的書籍和技術論文很詳細地介紹了其規范和協議（你可以從RFC：5246：傳輸安全協議（TLS）Version1.2開始，在以下地址http://tools.ietf.org/html/rfc5246）
配置Apache Tomcat以支持SSL
首先且最重要的是，如果你計划執行如下SSL相關的例子，需要配置應用服務器以支持SSL連接。對於Apache Tomcat，這相對很容易。如果你在使用其它的應用服務器，請查看文檔的相關部分。
生成server key store
我們需要使用Java的keytool命令來生成一個key store。打開一個命令提示窗口，並輸入以下的命令：
按照提示進行如下的輸入。輸入密碼password作為key store和個人密鑰的密碼。
- What is your first and last name?
- [Unknown]: JBCP Pets Admin
- What is the name of your organizational unit?
- [Unknown]: JBCP Pets
- What is the name of your organization?
- [Unknown]: JBCP Pets
- What is the name of your City or Locality?
- [Unknown]: Anywhere
- What is the name of your State or Province?
- [Unknown]: NH
- What is the two-letter country code for this unit?
- [Unknown]: US
- Is CN=JBCP Pets Admin, OU=JBCP Pets, O=JBCP Pets, L=Anywhere, ST=NH, C=US
- correct?
- [no]: yes
這將會在當前目錄下，生成一個名為tomcat.keystore的文件。這就是啟用Tomcat SSL所使用的key store。
【注意的是要執行的是genkeypair命令（在早於java 6的釋放版本中要使用keytool的genkey命令）】
為了下一步的操作，需要記住這個文件的地址。
配置Tomcat的SSL Connector
在Apache Tomcat的conf目錄下，用XML編輯器（Eclipse或類似的都可以）打開server.xml，並取消注釋或添加SSL Connector聲明。應該如下所示：
- <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
- maxThreads="150" scheme="https" secure="true"
- sslProtocol="TLS"
- keystoreFile="conf/tomcat.keystore"
- keystorePass="password"/>
確保在上一步中生成的tomcat.keystore文件被copy到了Tomcat安裝路徑的conf目錄下。在配置后，Tomcat服務器可以重啟，JBCP Pets應用能夠在一個安全的端口https://localhost:8443/JBCPPets/上進行訪問。
取決於不同的瀏覽器，可能需要包含https而不是http。這樣的問題可能會比較難發現，你可能會比較奇怪為什么不能看到JBCP Pets的主頁。
對站點進行自動的安全保護
我們假設你在對客戶的數據進行SSL保護時遇到了麻煩，你想把應用的特定部分置於SSL的保護之下。幸運的是，Spring Security讓這一切變得很簡單，只需要在<intercept-url>聲明上添加一個配置屬性。
requires-channel屬性能夠添加到任何<intercept-url>聲明中，以要求所有匹配的URL要以特定的協議（HTTP，HTTPS或都可以）進行傳遞。如果按照這種形式來增強JBCP Pets站點，配置可能如下所示：
- <http auto-config="true" use-expressions="true">
- <intercept-url pattern="/login.do" access="permitAll"
- requires-channel="https"/>
- <intercept-url pattern="/account/*.do"
- access="hasRole('ROLE_USER') and fullyAuthenticated"
- requires-channel="https"/>
- <intercept-url pattern="/*" access="permitAll"
- requires-channel="any"/>
- <!-- ... -->
- </http>
如果此時重啟應用，你將會發現：
l 現在訪問登錄頁和賬號頁需要HTTPS，瀏覽器將會為用戶自動從不安全的（HTTP）URL重定向到安全的URL。例如，嘗試訪問http://localhost:8080/JBCPPets/login.do將會被定向到https://localhost:8443/JBCPPets/login.do；
l 如果用戶被切換到了安全的HTTPS URL，如果他訪問一個不必要使用HTTPS的URL，他能繼續保留在HTTPS狀態。
我們可以想象這種配置對於安全的好處——大多數的現代應用服務器使用一個secure標識session的cookie，所以強制要求登錄頁是安全的（如果這是應用的session被首次分配的地方）能夠保證session的cookie能夠被安全的傳輸，所以出現session劫持的可能性也更小。另外，直接將SSL加密配置在安全聲明上的做法，能夠很容易的保證應用中所有敏感的頁面被適當和完整的保護。
為用戶自動切換適當協議（HTTP或HTTPS）的功能，通過Spring Security過濾器鏈上的另外一個servlet過濾器來實現的（它的位置很靠前，在SecurityContextPersistenceFilter后面）。如果任何URL用requires-channel屬性聲明使用特定類型的協議，o.s.s.web.access.channel.ChannelProcessingFilter將會自動添加到過濾器鏈上
ChannelProcessingFilter在請求時的交互過程如下圖所示：
如果你的應用需要超出內置功能的復雜邏輯，ChannelProcessingFilter的設計可以進行擴展和增強。注意我們盡管只在圖中說明了SecureChannelProcessor和RetryWithHttpsEntryPoint的實現，但是有類似的類去校驗和處理聲明為要求HTTP的URL。
注意，ChannelEntryPoint使用了HTTP 302的URL重寫，這就不能使用這種技術去重定向POST的URL（盡管典型的POST請求不應該在安全協議和不安全協議間傳遞，因為大多數的應用都會對這種行為提出警告）。
安全的端口映射
在一些特定的環境中，可能不會使用標准的HTTP和HTTPS端口，其默認為80/443或8080/8443。在這種情況下，你必須配置你的應用包含明確的端口映射，這樣ChannelEntryPoint的實現能夠確定當重定向用戶到安全或不安全的URL時，使用什么端口。
這僅需要增加額外的配置元素<port-mappings>，它能夠指明除了默認的端口以外，額外的HTTP 的HTTPS端口：
- <port-mappings>
- <port-mapping http="9080" https="9443"/>
- </port-mappings>
如果你的應用服務器在反向代理后的話，端口映射將會更加的重要。