安全性基本概念和 ASP.NET 支援 (VB)

  • 發行項

作者 ：Scott Mitchell

注意

自本文撰寫以來，ASP.NET 成員資格提供者已被 ASP.NET 身分識別取代。 強烈建議您更新應用程式以使用 ASP.NET 身分識別 平臺，而不是本文撰寫時精選的成員資格提供者。 ASP.NET 身分識別對於 ASP.NET 成員資格系統有一些優點，包括 ：

  • 更好的效能
  • 改善擴充性和可測試性
  • 支援 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 檔案或任何其他內容類型。 Web 伺服器的工作是傳回要求的內容。 如此一來，它必須判斷要求的相關一些事項，包括提出要求的人員，以及身分識別是否獲得授權來擷取要求的內容。

根據預設，瀏覽器會傳送缺少任何類型的識別資訊的 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) 时遭到未经授权的 (，授權系統會報告使用者遭到拒絕，導致窗體驗證系統自動將使用者重新導向至登入頁面。

使用者成功登入之後，後續的 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 的情況下，每個實作使用者帳戶的開發人員必須取得自己的設計決策，例如，如何? 儲存密碼或其他敏感性資訊的問題？以及我應該對密碼長度和強度施加哪些指導方針？

現在，在 ASP.NET 應用程式中實作用戶帳戶會比 成員資格架構 和內建的登入 Web 控件更簡單。 成員資格架構是 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 中提供兩個成員資格提供者類別：

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

提供者模型可讓不同的實作順暢地插入架構

圖 03：提供者模型可讓不同的實作順暢地插入架構 (按兩下即可檢視大小完整的映像)

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

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

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

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

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

摘要

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

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

快樂的程序設計！

深入閱讀

如需本教學課程中討論之主題的詳細資訊，請參閱下列資源：

關於作者

Scott Mitchell 是 1998 年以來，1998 年與 Microsoft Web 技術合作的 七篇 ASP/ASP.NET 書籍和 4GuysFromRolla.com 作者。 Scott 是獨立的顧問、訓練者和作者。 他的最新書籍是 Sams 在 24 小時內自行 ASP.NET 2.0。 您可以透過mitchell@4GuysFromRolla.com部落格連到，也可以透過其部落格來存取，網址為 http://ScottOnWriting.NET。

特別感謝

本教學課程系列是由許多實用的檢閱者所檢閱。 本教學課程的潛在客戶檢閱者是本教學課程系列是由許多實用的檢閱者所檢閱。 本教學課程的首席檢閱者包括 Alicja Maziarz、John Suru 和 Teresa Murphy。 想要檢閱即將推出的 MSDN 文章嗎？ 如果是，請將一行放在 mitchell@4GuysFromRolla.com。

下一步