安全性基本概念與 ASP.NET 支援 (C#)

發行項
11/21/2024

注意

自本文撰寫以來，ASP.NET 成員資格提供者已由 ASP.NET Identity 取代。我們強烈建議更新應用程式以使用 ASP.NET Identity 平台，而不是撰寫本文時介紹的成員資格提供者。與 ASP.NET 成員資格系統相比，ASP.NET Identity 具有許多優勢，包括：

更好的效能
改進的可擴展性和可測試性
支援 OAuth、OpenID Connect 和雙重認證
基於宣告的身分支援
與 ASP.Net Core 更好的互通性

下載 PDF

這是一系列教學課程中的第一個教學課程，將探索透過 Web 窗體驗證訪客、授權存取特定頁面和功能，以及在 ASP.NET 應用程式中管理使用者帳戶的技術。

簡介

論壇、電子商務網站、在線電子郵件網站、入口網站和社交網路網站都有什麼共同之處？他們全都提供 用戶帳戶。提供用戶帳戶的網站必須提供一些服務。新訪客至少必須能夠建立帳戶，而傳回的訪客必須能夠登入。這類 Web 應用程式可以根據登入的使用者做出決策：某些頁面或動作可能僅限於登入的使用者，或特定使用者子集;其他頁面可能會顯示登入使用者的特定資訊，或可能會根據用戶檢視頁面的內容顯示更多或更少的資訊。

這是一系列教學課程中的第一個教學課程，將探索透過 Web 窗體驗證訪客、授權存取特定頁面和功能，以及在 ASP.NET 應用程式中管理使用者帳戶的技術。在這些教學課程中，我們將探討如何：

識別使用者並登入網站
使用 ASP。用來管理用戶帳戶的 NET 成員資格架構
建立、更新和刪除用戶帳戶
根據登入的使用者限制網頁、目錄或特定功能的存取
使用 ASP。NET 的角色架構，將用戶帳戶與角色產生關聯
管理使用者角色
根據登入的使用者角色限制網頁、目錄或特定功能的存取
自定義和擴充 ASP。NET 的安全性 Web 控制件

這些教學課程旨在簡潔，並提供具有大量螢幕快照的逐步指示，以可視化方式引導您完成程式。 C# 和 Visual Basic 版本提供每個教學課程，並包含所使用完整程式碼的下載。（本第一個教學課程著重於高階觀點的安全性概念，因此不包含任何相關聯的程序代碼。

在本教學課程中，我們將討論重要的安全性概念，以及 ASP.NET 中有哪些設施可用來協助實作窗體驗證、授權、用戶帳戶和角色。現在就開始吧！

注意

安全性是任何跨實體、技術和原則決策且需要高度規劃和領域知識的應用程式的重要層面。本教學課程系列並非用來開發安全 Web 應用程式的指南。相反地，它特別著重於窗體驗證、授權、用戶帳戶和角色。雖然一些圍繞這些問題的安全性概念在此系列中討論，但其他概念則未探索。

驗證、授權、用戶帳戶和角色

驗證、授權、用戶帳戶和角色是本教學課程系列中經常使用的四個詞彙，因此我想花一點時間在 Web 安全性內容中定義這些詞彙。在用戶端-伺服器模型中，例如因特網，伺服器需要識別提出要求的用戶端。驗證是確定用戶端身分識別的程式。已成功識別的用戶端據說已經過驗證。身份不明的客戶端據說未經驗證或匿名。

安全驗證系統至少涉及下列三個 Facet 之一：您知道的專案、您擁有的專案，或您擁有的專案。大部分的 Web 應用程式都依賴用戶端知道的內容，例如密碼或 PIN。用來識別用戶的資訊，例如她的使用者名稱和密碼，稱為認證。本教學課程系列著重於 窗體驗證，這是使用者透過在網頁窗體中提供認證來登入網站的驗證模型。我們以前都經歷過這種類型的驗證。移至任何電子商務網站。當您準備好簽出時，系統會要求您在網頁上的文字框中輸入您的使用者名稱和密碼來登入。

除了識別用戶端之外，伺服器可能需要根據提出要求的用戶端來限制可存取的資源或功能。授權是判斷特定使用者是否有權存取特定資源或功能的程式。

用戶帳戶是保存特定使用者相關信息的存放區。用戶帳戶必須至少包含可唯一識別用戶的資訊，例如使用者的登入名稱和密碼。除了這項基本資訊之外，用戶帳戶可能包含下列專案：用戶的電子郵件位址;建立帳戶的日期和時間;他們上次登入的日期和時間;名字和姓氏;電話號碼;和郵寄地址。使用窗體驗證時，用戶帳戶資訊通常會儲存在關係資料庫中，例如Microsoft SQL Server。

支援用戶帳戶的 Web 應用程式可能會選擇性地將使用者分組為角色。角色只是套用至使用者的標籤，並提供定義授權規則和頁面層級功能的抽象概念。例如，網站可能包含具有授權規則的系統管理員角色，禁止系統管理員存取特定網頁集的任何人。此外，所有使用者可存取的各種頁面（包括非系統管理員）可能會在系統管理員角色中瀏覽用戶時顯示其他數據或提供額外的功能。使用角色時，我們可以根據角色來定義這些授權規則，而不是依使用者。

在 ASP.NET 應用程式中驗證使用者

當使用者在瀏覽器的位址視窗中輸入 URL 或按兩下連結時，瀏覽器會針對指定的內容向網頁伺服器發出超文本傳輸通訊協定（HTTP）要求，無論是 ASP.NET 頁面、影像、JavaScript 檔案或任何其他內容類型。網頁伺服器負責傳回要求的內容。這樣做時，它必須判斷要求的相關事項，包括提出要求的人員，以及身分識別是否獲得擷取要求的內容。

根據預設，瀏覽器會傳送 HTTP 要求，這些要求缺少任何種類的識別資訊。但是，如果瀏覽器包含驗證資訊，則網頁伺服器會啟動驗證工作流程，以嘗試識別發出要求的用戶端。驗證工作流程的步驟取決於 Web 應用程式所使用的驗證類型。 ASP.NET 支援三種類型的驗證：Windows、Passport 和表單。本教學課程系列著重於窗體驗證，但讓我們花一分鐘的時間比較和對比 Windows 驗證使用者存放區和工作流程。

透過 Windows 驗證進行驗證

Windows 驗證工作流程會使用下列其中一種驗證技術：

基本驗證
摘要式驗證
Windows 整合式驗證

這三種技術的運作方式大致相同：當未經授權的匿名要求送達時，網頁伺服器會傳回 HTTP 回應，指出需要授權才能繼續。然後瀏覽器會顯示強制回應對話框，提示使用者輸入其使用者名稱和密碼（請參閱圖 1）。此資訊接著會透過 HTTP 標頭傳回至網頁伺服器。

強制回應對話框會提示使用者輸入他的認證

圖 1：強制回應對話框提示使用者輸入他的認證

提供的認證會根據網頁伺服器的 Windows 使用者存放區進行驗證。這表示 Web 應用程式中的每個已驗證使用者都必須在您的組織中擁有 Windows 帳戶。這在內部網路案例中很常見。事實上，在內部網路設定中使用 Windows 整合式驗證時，瀏覽器會自動提供網頁伺服器用來登入網路的認證，從而隱藏圖 1 中顯示的對話方塊。雖然 Windows 驗證非常適合內部網路應用程式，但因特網應用程式通常不可行，因為您不想為每個註冊網站的使用者和每位使用者建立 Windows 帳戶。

透過窗體驗證進行驗證

另一方面，窗體驗證非常適合用於因特網 Web 應用程式。回想一下，窗體驗證會提示使用者透過 Web 窗體輸入其認證，藉此識別使用者。因此，當用戶嘗試存取未經授權的資源時，他們會自動重新導向至登入頁面，讓他們可以輸入其認證。然後，系統會根據自定義使用者存放區來驗證提交的認證，通常是資料庫。

驗證提交的認證之後， 會為使用者建立窗體驗證票證 。此票證表示使用者已通過驗證，並包含識別資訊，例如用戶名稱。窗體驗證票證會儲存為客戶端電腦上的 Cookie。因此，後續造訪網站時，會在 HTTP 要求中包含窗體驗證票證，藉此讓 Web 應用程式在使用者登入後識別使用者。

圖 2 說明來自高階優勢的窗體驗證工作流程。請注意 ASP.NET 中的驗證和授權片段如何作為兩個不同的實體。窗體驗證系統會識別使用者（或報告他們是匿名的）。授權系統是決定使用者是否具有所要求資源的存取權。如果使用者未經授權（如同嘗試匿名流覽ProtectedPage.aspx時，圖 2 所示，授權系統會回報使用者遭到拒絕，導致窗體驗證系統自動將使用者重新導向至登入頁面。

使用者成功登入之後，後續的 HTTP 要求會包含窗體驗證票證。窗體驗證系統只會識別使用者 - 它是授權系統，可決定使用者是否可以存取所要求的資源。

窗體驗證工作流程

圖 2：窗體驗證工作流程

我們將在下一個教學課程《窗體驗證概觀》中深入探討窗體驗證。如需 ASP 的詳細資訊。NET 的驗證選項，請參閱 ASP.NET 驗證。

限制網頁、目錄和頁面功能的存取

ASP.NET 包含兩種方式來判斷特定使用者是否有權存取特定檔案或目錄：

檔案授權 - 由於 ASP.NET 頁面和 Web 服務會實作為位於網頁伺服器檔案系統上的檔案，因此可以透過存取控制清單（ACL）來指定這些檔案的存取權。檔案授權最常與 Windows 驗證搭配使用，因為 ACL 是適用於 Windows 帳戶的許可權。使用窗體驗證時，不論使用者瀏覽網站，所有操作系統和文件系統層級要求都會由相同的 Windows 帳戶執行。
URL 授權 - 具有 URL 授權的頁面開發人員會在 Web.config 中指定授權規則。這些授權規則會指定允許哪些使用者或角色存取，或拒絕存取應用程式中的特定頁面或目錄。

檔案授權和 URL 授權會定義存取特定 ASP.NET 頁面或特定目錄中所有 ASP.NET 頁面的授權規則。使用這些技術，我們可以指示 ASP.NET 拒絕特定使用者對特定頁面的要求，或允許存取一組使用者，並拒絕其他人的存取權。所有使用者都可以存取頁面的案例為何，但頁面的功能取決於使用者？例如，支援使用者帳戶的許多網站都有頁面，可顯示已驗證使用者與匿名使用者的不同內容或數據。匿名使用者可能會看到登入網站的連結，而已驗證的使用者會看到類似「歡迎回來」、「用戶名稱」之類的訊息，以及註銷的連結。另一個範例：在拍賣網站上檢視專案時，您會看到不同的資訊，視您是競拍者還是拍賣專案而定。

這類頁面層級的調整可以以宣告方式或以程序設計方式完成。若要顯示匿名使用者與已驗證使用者不同的內容，只要將LoginView控件拖曳到您的頁面上，然後將適當的內容輸入到其 AnonymousTemplate 和 LoggedInTemplate 範本中。或者，您也可以以程式設計方式判斷目前的要求是否已通過驗證、用戶是誰，以及他們所屬的角色（如果有的話）。您可以使用這項資訊來顯示或隱藏頁面上方格或面板中的數據行。

本系列包含三個著重於授權的教學課程。 使用者型授權會檢查如何限制特定使用者帳戶目錄中頁面或頁面的存取權; 角色型授權會查看在角色層級提供授權規則;最後，根據目前登入的使用者教學課程顯示內容會探索根據瀏覽頁面的使用者修改特定頁面的內容和功能。如需 ASP 的詳細資訊。NET 的授權選項，請參閱 ASP.NET 授權。

用戶帳戶和角色

ASP。NET 的窗體驗證提供一個基礎結構，讓用戶能夠登入網站，並在頁面瀏覽期間記住其已驗證狀態。而 URL 授權提供一個架構，可用來限制存取 ASP.NET 應用程式中的特定檔案或資料夾。不過，這兩項功能都未提供儲存用戶帳戶資訊或管理角色的方法。

ASP.NET 2.0 之前，開發人員必須負責建立自己的使用者和角色存放區。它們也處於設計使用者介面的鉤子上，併為必要的使用者帳戶相關頁面撰寫程序代碼，例如登入頁面和頁面，以建立新的帳戶等等。 ASP.NET 中沒有任何內建使用者帳戶架構，每個實作使用者帳戶的開發人員必須就如何? 儲存密碼或其他敏感性資訊等問題達成自己的設計決策？以及我應該對密碼長度和強度施加哪些指導方針？

現在，由於 成員資格架構 和內建的登入 Web 控件，在 ASP.NET 應用程式中實作使用者帳戶會更簡單。成員資格架構是 System.Web.Security 命名空間中的少數類別，可提供執行基本用戶帳戶相關工作的功能。 Membership 架構中的索引鍵類別是 Membership 類別，其方法如下：

CreateUser
DeleteUser
GetAllUsers
GetUser
UpdateUser
ValidateUser

成員資格架構會使用提供者模型，以清楚分隔成員資格架構的 API 與其實作。這可讓開發人員使用一般 API，但讓開發人員能夠使用符合其應用程式自定義需求的實作。簡言之，Membership 類別會定義架構的基本功能（方法、屬性和事件），但實際上不會提供任何實作詳細數據。相反地，Membership 類別的方法會叫用已設定的提供者，這是執行實際工作的方式。例如，當叫用 Membership 類別的 CreateUser 方法時，Membership 類別並不知道使用者存放區的詳細數據。它不知道使用者是否在資料庫或 XML 檔案或其他存放區中維護。 Membership 類別會檢查 Web 應用程式的組態，以判斷要委派呼叫的提供者，而該提供者類別負責實際在適當的使用者存放區中建立新的用戶帳戶。圖 3 說明此互動。

Microsoft會提供 .NET Framework 中的兩個成員資格提供者類別：

ActiveDirectoryMembershipProvider - 在 Active Directory 和 Active Directory 應用程式模式（ADAM）伺服器中實作成員資格 API。
SqlMembershipProvider - 在 SQL Server 資料庫中實作成員資格 API。

本教學課程系列著重於 SqlMembershipProvider。

圖 03：提供者模型可讓不同的實作無縫插入架構中（按兩下即可檢視完整大小的映射）

提供者模型的優點是，替代實作可由Microsoft、第三方廠商或個別開發人員開發，並順暢地插入成員資格架構。例如，Microsoft已針對 Microsoft Access 資料庫發行成員資格提供者。如需成員資格提供者的詳細資訊，請參閱 Provider Toolkit，其中包含成員資格提供者的逐步解說、範例自定義提供者、提供者模型上超過 100 頁的檔，以及內建成員資格提供者的完整原始程式碼（即 ActiveDirectoryMembershipProvider 和 SqlMembershipProvider）。

ASP.NET 2.0 也引進角色架構。如同成員資格架構，角色架構會建置在提供者模型之上。其 API 會透過 Roles 類別公開，而 .NET Framework 隨附三個提供者類別：

AuthorizationStoreRoleProvider - 管理授權管理員原則存放區中的角色資訊，例如 Active Directory 或 ADAM。
SqlRoleProvider - 在 SQL Server 資料庫中實作角色。
WindowsTokenRoleProvider - 根據訪客的 Windows 群組關聯角色資訊。這個方法通常與 Windows 驗證搭配使用。

本教學課程系列著重於 SqlRoleProvider。

由於提供者模型包含單一正向 API（成員資格和角色類別），因此可以在該 API 周圍建置功能，而不需擔心實作詳細數據 - 這些是由頁面開發人員選取的提供者所處理。此整合 API 可讓Microsoft和第三方廠商建置與成員資格和角色架構介面的 Web 控制件。 ASP.NET 隨附許多登入 Web 控制件，以實作一般使用者帳戶用戶帳戶的介面。例如，登入控件會提示使用者輸入其認證、驗證認證，然後透過窗體驗證登入。 LoginView 控件提供範本，以針對匿名用戶顯示不同的標記，或根據使用者的角色來顯示不同的標記。 CreateUserWizard 控制項提供建立新用戶帳戶的逐步使用者介面。

下方涵蓋各種登入控件會與成員資格和角色架構互動。大部分的登入控件都可以實作，而不需要撰寫單行程序代碼。我們將在未來的教學課程中更詳細地檢查這些控制項，包括擴充和自定義其功能的技術。

摘要

支援使用者帳戶的所有 Web 應用程式都需要類似的功能，例如：用戶能夠登入，並在頁面瀏覽期間記住其登入狀態;新訪客建立帳戶的網頁;以及頁面開發人員指定哪些資源、數據和功能可供哪些使用者或角色使用的能力。驗證和授權使用者及管理用戶帳戶和角色的工作，在 ASP.NET 應用程式中，由於窗體驗證、URL 授權和成員資格和角色架構，在 ASP.NET 應用程式中非常容易完成。

在接下來的幾個教學課程中，我們將逐步建置工作 Web 應用程式，以檢查這些層面。在接下來的兩個教學課程中，我們將詳細探索窗體驗證。我們將會看到窗體驗證工作流程作用中、剖析窗體驗證票證、討論安全性考慮，以及瞭解如何設定窗體驗證系統，同時建置可讓訪客登入和註銷的 Web 應用程式。

快樂程式！

深入閱讀

有關本教學課程中討論的主題的更多資訊，請參閱以下資源：

關於作者

Scott Mitchell，七本 ASP/ASP.NET 書籍的作者和 4GuysFromRolla.com 創始人，自 1998 年以來便開始使用 Microsoft Web 技術。 Scott 擔任獨立顧問、講師和作家。他的新書是 Sams Teach Yourself ASP.NET 2.0 in 24 Hours。您可以透過 mitchell@4GuysFromRolla.com 或他的部落格 (可以在 http://ScottOnWriting.NET 找到) 與他聯繫。

特別感謝

本教學課程系列已經過許多熱心的檢閱者檢閱。本教學課程的潛在客戶檢閱者是本教學課程系列是由許多實用的檢閱者檢閱。本教學課程的主要檢閱者包括 Alicja Maziarz、John Suru 和 Teresa Murphy。有興趣檢閱我即將推出的 MSDN 文章嗎？如果是這樣，請留言給我 mitchell@4GuysFromRolla.com。

下一步

共用方式為