SQL Server的安裝有兩個關於安全模式的選項。它們之間的差別在於由哪一個軟件執行認證過程。認證是一個確認將要連接SQL Server的用戶身份的過程。一旦執行了認證，SQL Server就能驗證這個用戶是否具有許可來連接一個被請求的資源，例如一個數據庫。如果用戶具有連接數據庫的許可，那麼SQL Server將允許連接請求成功，否則，連接失敗。這個驗證用戶許可的過程還被稱為授權。
· Windows Authentication(還被稱為Trusted Authentication或者Integrated Security)使用進行連接請求過程的Windows用戶身份來執行對數據庫的授權。在這種情況下，連接字符串不必提供顯式的用戶名和密碼。ASP.NET以一個名為"ASPNET"的本地用戶來運行(或者在IIS 6.0當中使用用戶名"Network Service")，所以當使用Windows Authentication時，SQL將會檢查這個用戶是否擁有使用數據庫的許可。此時，所有的ASP.NET應用程序都用這個相同的用戶運行，所以該安全模式對這些應用程序一視同仁。雖然可以在單獨的ASP.Net進程中運行每一個應用程序(單獨的用戶運行每個程序)，或者可以模擬進行連接請求的浏覽器客戶的Windows用戶身份，但是這些內容都超出了本書所要講述的范圍。不過，客戶模擬的情況在Web應用程序中是Windows Authentication最常見的使用方式。
· SQL Authentication針對在SQL Server內配置的用戶來檢查顯式提供的用戶名和密碼(無需涉及操作系統)。在這種情況下，在ASP.NET進程中運行的每個應用程序都能以單獨的證書來連接數據庫，這樣就把應用程序合理地隔離開了(應用程序A如果沒有B的用戶名和密碼就不能連接至B的數據庫)。這是用於部署的Web應用程序的最常見認證模式，特別是在共享宿主的情況下。它的一個小缺點就是需要應用程序保留用於連接的用戶賬戶的密碼，並且如果該密碼被惡意用戶獲取，那麼將危及數據庫的安全。但是，在本書後面將會看到，ASP.Net提供了一個安全的方式，將SQL Authentication密碼以加密的格式保存在Web.config文件中，這樣就降低了密碼被獲取的風險。
· Mixed Mode是SQL Server的配置，它既允許Windows Authentication，也允許SQL Authentication。
在安裝SQL Server或者SSE時，要選擇一種認證模式。在SQL Server中，有向導會在安全步驟中幫助選擇，而在SSE中，默認選擇是Windows Authenti cation。如果要安裝SQL Authentication，就必須顯式地配置。本文使用的是Windows Authentication。
如果已經安裝了SQL Server或者SSE，就能通過打開RegEdit來查看所指定的認證模式(當然需要先備份)，找到HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server並搜索LoginMode。值為1的注冊子鍵表示Windows Auth entication，而值2表示Mixed Authentication模式。
表3-1總結了這些模式之間的區別。
表3-1
Windwos Authentication
SQL Authentication
可替換名稱
Trusted Authentication
Integrated Security
沒有，但是Mixed Mode Authen tication允許使用Windows或者SQL Authentication
典型環境
內部網
因特網
用戶和認證過程列表的位置
Windows
SQL Server
SSE安裝
默認安裝
需要指定安裝
連接字符串
Trusted_connection=true或者Integrated Security=true
user=username;
password=passWord
ASP.Net Web應用程序的用戶
ASP.Net進程、ASPNET(IIS 5.x)或者Network Service(IIS 6)
SQL用戶
優勢
較好的安全性；可以對用戶在SQL事件和Windows事件中的活動進行跟蹤
無需創建新賬戶即可在宿主機上部署；獨立於操作系統
宿主的內部網站點只需一般技術
為應用程序提供更加靈活的方式以不同的證書來連接每個數據庫
劣勢
給予Web應用程序Windows證書有可能會將OS中的權限范圍設置過大
密碼存儲在Web應用程序中(在Windows認證中則不是)。確認密碼保存在Web.config文件中並已加密。
允許使用sa證書的Web應用程序的低級操作。總是為ASP.Net Web應用程序創建新的證書並只給予所需的權限
現在，知道了SQL使用安全的方式，我們來考慮數據使用者(DataSource控件)將如何滿足需求。首先，使用從VWD和VWD Web Server(Cassini)獲取的數據，主要是在設計和測試的時候。第二，在部署之後應當從IIS訪問數據。這兩個數據使用者有不同的用戶名。VWD和VWD Web Server使用登錄進Windows的人員的名稱，而IIS程序使用名稱ASPNET。
如果SQL Server使用Windows認證，那麼SqlDataSource控件需要在連接字符串中包含如下代碼：Integrated Security=true(或者Trusted_connection=true)。這個參數將指示SQL Server根據請求者的Windows登錄賬戶對數據請求進行認證。如果是登錄安裝SSE的用戶，其證書將授予訪問SSE的權限。使用VWD和VWD Web Server將一切順利，因為VW Web Server的用戶被認為是登錄進Windows的程序人員，於是具有SSE上的賬戶。但是，即使是應用程序在VWD之外工作正常，當站點遷移至IIS後，也會不正常。IIS是在名為ASPNET的用戶賬戶下運行的(或者是在IIS6/Windows 2003 Server中的Network Service)。因此，運行著IIS的機器的管理員必須添加ASP.NET用戶並授予其許可。這個過程超出了本書講解的范圍，但是在很多IIS管理員手冊中都有詳細的描述。總而言之，如果SQL Server使用的是Windows認證，就能使用VWD和VWD Web Server進行本書的練習。只有在授予了訪問數據庫的ASP.Net進程賬戶許可之後，您的頁面才可以在IIS上運行。
如果
SQL Server使用的是SQL認證，SQL將進行自己的認證過程。這個過程將不依靠Windows的用戶列表。連接字符串中包含了兩個參數：user=username， password=passWord。現在就可以從VWD、VWD Web Server或者IIS中使用頁面了，因為不需要在Windows中創建用戶賬戶。但是，我們還要使用SQL Server中的賬戶。惟一的默認賬戶是sa。在部署之前，應當在SQL Server中創建另外一個賬戶，該賬戶只擁有執行ASPX頁面的權限。如果不創建sa以外的替換賬戶(和密碼以保護sa)，那麼將會使站點處於最知名、最易於利用的安全漏洞之中。任何黑客都知道使用空密碼的userID='sa'來登錄。
對兩種認證模式來說，當使用前面所述的連接字符串時，用戶將以初始賬戶登錄進SQL Server。這個賬戶就是sa，表示系統管理員，從名稱上可以看出，它具有對所有對象的所有權限。在當前的SQL Server版本中，不能以密碼為NULL的sa來安裝服務。而在SSE中，必須以參數SAPWD="MyStrongPassWord"來安裝。這裡的強密碼表示至少不為NULL。最好使用不少於七位的字符並確保使用字母、數字和符號的混和形式。在學生練習之外的大多數情況下，需要為每個數據庫和應用程序指定一個賬戶。應避免讓一個應用程序擁有可以訪問其他應用程序數據的權限。
