共用方式為

  • 發行項

本文章是由機器翻譯。

Windows Azure AppFabric

再敘 Windows Azure AppFabric 存取控制服務

Vittorio Bertocci

如果您要尋找能更輕鬆地在您的網站和服務中對使用者進行身份驗證和授權的服務，則應再來關注一下 Windows Azure AppFabric 存取控制服務（簡稱 ACS），因為現在實現了一些重大更新（在撰寫本文的時候）。

允許分屬不同組織的使用者訪問您的應用程式，同時維持較高的安全標準，這樣的工作一直以來都頗具挑戰性。這個問題在傳統上一直與業務和企業方案有關，在這些方案中，使用者通常依賴于目錄。隨著社交網站作為線上活動的重要舞臺的興起，使得人們日益關注如何可以讓使用者從 Windows Live ID、Facebook、Yahoo 和 Google 這類媒介訪問應用程式。

隨著開放標準的出現，這種情況有所改觀；但是直到今日，要直接在應用程式中實現這些標準並同時處理好所有這些不同實體使用的身份驗證協定，仍是一個巨大的挑戰。如果要自行完成這些任務，最糟糕的事可能是您始終有忙不完的工作：協定不斷演變，新標準不斷湧現，而且您經常會被迫恢復並升級那些複雜的、受到加密約束的身份驗證代碼。

ACS 極大簡化了這些難題。簡而言之，ACS 可作為您的應用程式與存儲您要使用的帳戶的使用者存儲庫（標識提供程式，簡稱 IP）之間的仲介。ACS 將負責處理有關將每個 IP 與適當的協定相結合的低層細節，從而使您的應用程式碼不必考慮每個事務類型的細節。ACS 支援很多協定，如 OpenID、OAuth WRAP、OAuth 2.0、WS-Trust 和 WS-Federation。這樣，您就可以利用很多 IP。

將您的解決方案中的身份驗證（以及某些授權）外包給 ACS 很容易。您只需利用 Windows Identity Foundation (WIF)（一個可通過高級標識和訪問功能增強應用程式的 Microsoft .NET Framework 擴展）並完成一個簡短的 Visual Studio 嚮導即可。您通常可以輕易完成此操作而不必編寫任何代碼！

聽起來很難吧？別擔心，此問題不只您一個人遇到；因為發生此問題時通常涉及標識和安全，所以解釋起來比實際操作要難。讓我們選擇一個 ACS 的常見用途，即，將您的網站的身份驗證外包給多個 Web IP，然後按照必需的步驟進行操作。

將網站的身份驗證外包給 ACS

首先選擇一個普通的網站，並讓使用者可以使用 Google 帳戶登錄。

開始之前，請先確保我們已具有必備軟體。以下是所需的軟體：

  • Visual Studio 2010
  • Windows Identity Foundation Runtime
  • Windows Identity Foundation SDK 和以下軟體之一：Windows 7、Windows Server 2008、Windows Server 2008 R2 或 Windows Vista SP1

儘管不是硬性要求，但在電腦上安裝 IIS 還是有説明的；如果您沒有安裝 IIS，則需要對演練的各個步驟進行調整。

Visual Studio 無需贅述，但對 WIF（發音為“dub-IF”）略微介紹一下並解釋它成為必備軟體的原因可能會對您有所説明。（有關 WIF 的詳細解釋，請參閱“Programming Windows Identity Foundation”[Microsoft Press, 2010]）。

WIF 是對 .NET Framework 的擴展，提供了一個用於處理身份驗證和使用者身份的新模型，此模型將應用程式與身份驗證執行過程的細節分離開來。傳統的身份驗證系統（如 ASP.NET 成員提供程式 API）會強制您處理身份驗證過程的細節。這要求您使用低級別的 API 來處理低級別構造，如密碼和證書等。WIF 提供了便利的抽象功能，使您可以指定外部實體來處理使用者身份驗證，從而完全改變了這種狀況。利用基於表單的身份驗證，您可以指定一個給定頁面（通常為 login.aspx），在這個頁面中，只要調用方尚未進行身份驗證，就會重定向請求。利用 WIF，您可以登記每當使用者需要進行身份驗證時要調用的外部實體（一個 IP）。在設計時選擇 IP 的方式以及在運行時使用 IP 的方式需遵循眾所周知的協定。WIF 負責發現應使用哪些協定並相應地強制執行通信策略。再次重申，演示操作比解釋操作容易得多。

創建初始解決方案

打開 Visual Studio。通過選擇“檔”|“新建”|“網站”來創建一個新網站。讓我們創建一個新的 ASP.NET 網站，但在此之前，請先確定已將 Web 位置選擇為“HTTP”並將 URL 配置為在 IIS 中運行（參見圖 1）。這將確保在使用 WIF 工具時可以順暢運行。如果您的 Web 伺服器上提供了 HTTPS，那麼最好使用它；雖然本演練並沒有嚴格要求，但我們強烈建議在生產系統上使用它，因為這會減少 WIF 出現警告的次數。

圖 1 選擇 ASP.NET 網站並使用 HTTP 作為位置

按一下 F5 後，您將會看到，您有了一個基本的 ASP.NET 網站；按一下“登錄”連結後，系統將提示您輸入使用者名和密碼。我們要做出的更改之處就是：不使用使用者名和密碼，也不直接在網站中處理身份驗證，而是使用 WIF 將身份驗證外包給 ACS。ACS 將反過來允許我們開放對外部 IP 的訪問。

配置 ACS 專案

首先，我們需要在 Windows Azure AppFabric LABS 門戶網站中創建一個專案。LABS 門戶網站是一個專門設置的、用來允許社區訪問早期元件的環境。這裡沒有與 AppFabric LABS 相關的成本，但也沒有服務級別的協定或保證。

打開您的流覽器並轉到 portal.appfabriclabs.com。系統將提示您使用 Windows Live ID 進行登錄。登錄後，您將需要創建新專案，請按一下“創建專案”連結。您將必須選擇專案名稱，請選擇適當的名稱並按一下“確定”。完成後，您將看到活動的專案名稱（本例中為“acsdemoproject”），請按一下它（參見圖 2）。

圖 2 在 Windows Azure AppFabric LABS 門戶網站中創建專案

在可以將身份驗證外包給 ACS 之前，您需要定義一個服務命名空間。應將該服務命名空間看作為您提供一小部分您自己的 AppFabric LABS 環境，而對於 ACS，則應將其看作與應用程式中 ACS 交互時將使用的資源的所有 URI 的唯一元件。該服務命名空間中的所有內容都由您來控制。按一下“添加服務命名空間”，指定名稱，選擇區域（在 LABS 中，您只能選擇“美國(南部/中部)”），再按一下“創建”。請注意，AppFabric 使用的 URI 在公共 Internet 上可用，並且用以唯一地標識服務，因此您必須選擇尚未被他人選用的命名空間。

啟動命名空間會花費一點時間，但是一旦啟動後，您就可以按一下“存取控制”連結來開始為您的網站配置 ACS。

現在您已經進入管理門戶網站，可以在此處為您的網站配置 ACS（參見圖 3）。

圖 3 Windows Azure AppFabric 存取控制服務管理門戶網站

按一下“管理”按鈕以開始操作。該管理門戶網站提供了一些引導式步驟來引導您完成開始過程，而這正是我們要做的。

選擇所需的標識提供程式

按一下“標識提供程式”連結。我們將在此處配置要在您的應用程式中使用的各個社交 IP。預設情況下，Windows Live ID 將顯示在清單中；讓我們添加對 Google 帳戶的支援。

按一下“添加標識提供程式”連結，這將會顯示提供程式的清單。按一下“Google”旁邊的“添加”按鈕。您可以為 IP 指定自訂圖像 URL，但在此示例中無需指定，請繼續操作並按一下“保存”。這樣，我們就添加了 Google 作為已識別的使用者身份來源。

讓 ACS 識別您的網站

既然已經配置了我們的 IP，就需要為 ACS 提供有關我們的網站的資訊。在標識術語中，我們通常將應用程式稱為“依賴方”，這表示應用程式依賴一個或多個 IP 來代為處理身份驗證。ACS UI 也與此術語保持一致。

按一下“依賴方應用程式”URL，然後按一下“添加依賴方應用程式”。讓我們指定以下資訊：

  • 名稱：我的網站
  • 領域：https://localhost/Website/
  • 返回 URL：https://localhost/Website/
  • 權杖格式：SAML 2.0
  • 權杖簽名：使用服務命名空間證書（典型）

在這裡至少要簡單介紹一下“權杖格式”（我們將在本文的後面花更多時間討論這個主題）。權杖是 IP 用來表明已成功進行身份驗證操作的專案（通常是 XML 片段或其他序列化格式的專案）。當使用 IP 選擇的任何系統進行使用者身份驗證後，使用者的流覽器將重定向至 ACS 並帶有一個證明使用者已被識別的權杖。使用的權杖格式和協定將根據 IP 確定。ACS 將檢查權杖，如果對此滿意（稍後將對此進行詳細的說明），則會發出它自己的新權杖並將其發送回您的應用程式。您在本步驟中更改的設置將確定您希望 ACS 使用哪個權杖格式傳回應用程式。ACS 能夠發出三種類型的權杖（SAML2.0、SAML1.1 和 SWT），它們在表達力、安全性、對某些用戶端類型的適用性等方面的能力各有千秋。此處請選擇 SAML2.0；在這裡，細節不是很重要。

領域應該與我們之前創建的網站的 URL 對應，這點很重要。當使用選擇的 IP 進行身份驗證後，ACS 將使用您在此處指定的 URL 將使用者重定向回您的網站。請注意，預設情況下“創建新規則組”將處於選定狀態，我們將在下個步驟中利用它。完成操作之後，請按一下“保存”以返回管理門戶網站。

添加規則

規則是一些很有趣的構造，可用於對使用者身份資訊進行更細緻的控制。但是，為了啟用從多個 IP 登錄，我們現在要使用的方案不需要顯式使用規則。因此，我們會將所有關于規則的說明延後到本文的下個部分中講述，因為它們在那裡才會派上用場。在這裡，我們將只採用預設設置。

按一下“規則組”連結。您應會看到在我們添加依賴方應用程式時創建的規則組（“我的網站的預設規則組”）。選擇此規則組，按一下“生成規則”連結，確認已選擇 Google 和 Windows Live ID，然後按一下“生成”按鈕 – 您在本方案中只需對規則執行這些操作就可以了。

收集 WS-Federation 中繼資料位址

至此，我們已完成了 ACS 的配置。但是，在回到 Visual Studio 之前，讓我們從“應用程式集成”頁面獲取一些資訊。按一下“應用程式集成”連結並複製“WS-Federation 中繼資料”URL – 我們要將它與 WIF 結合使用以設置要利用的網站。

簡單介紹一下，WS-Federation 中繼資料文檔是電腦可讀的、有關 ACS 如何處理身份驗證的說明。您的應用程式將需要該文檔，以便配置為將身份驗證外包給 ACS。

將網站配置為使用 ACS

返回到 Visual Studio 和您的網站。現在我們要利用 WIF 將身份驗證外包給 ACS，這將使 Google 帳戶能夠訪問我們的應用程式。在解決方案資源管理器中，按右鍵網站專案並選擇“添加 STS 引用”。這將啟動聯合身份驗證實用工具嚮導，該嚮導會將網站配置為使用 WIF 作為身份驗證機制並使用 ACS 作為身份驗證機構。STS 是“Security Token Service”（安全權杖服務）的縮寫，用於指示能提供請求權杖的入口點的特殊類型的 Web 服務或網頁；每個 IP 或權杖頒發者通常使用一個安全權杖服務。

您在大多數時候只需按一下“下一步”即可；必須輸入資訊的步驟非常少。前進到“安全權杖服務”步驟並指定“使用現有 STS”。粘貼從 ACS 門戶網站複製的聯合身份驗證中繼資料 URL（參見圖 4）。

圖 4 在 Visual Studio 中啟動聯合身份驗證實用工具嚮導

對於從此處開始的後續步驟，請保留預設值並按一下“下一步”，直至最後選擇“完成”。該嚮導添加所有必需的 WIF 程式集，向您的網站添加某些檔，（最重要的是）使用在進行身份驗證時利用 ACS 所必需的資訊更新您的 web.config。

測試身份驗證流

現在是時候嘗試您剛進行了安全加固的網站了！按一下 F5。您將立即重定向到“本地域發現”頁面，使用者可以通過此頁面從我們之前在 ACS 管理門戶網站中配置的多個 IP 中進行選擇（參見圖 5）。

圖 5**“本地域發現”頁面**

在選擇“Google”並輸入 Google 帳戶憑據之後，您將看到要求您允許 ACS 專案訪問的審批頁面 – 這不是您的網站在請求許可權，而是 ACS 在請求許可權，瞭解這點很重要（參見圖 6）。

圖 6 要求獲得從 Google 獲取資訊的許可權的 Windows Azure AppFabric 存取控制服務

在允許 ACS 要求的存取權限之後，您將重定向回該網站（參見圖 7）。就是這樣 – 您現在登錄網站了！

圖 7 **成功！**登錄到網站

如果您要驗證使用 Windows Live ID（命名空間中配置的其他 IP）是否也會獲得相同的體驗，則只需執行以下操作：關閉流覽器，再次按一下 F5，在“本地域發現”頁面選取“Windows Live ID”而不選取“Google”。

如果您有任何在網站上啟用身份驗證協定的經驗，就會知道，添加一個 IP 在傳統上意味著要學習其協定和 API，編寫頗具挑戰性的代碼，然後進行一遍又一遍的測試，直到能夠正常運行。以後每次另外添加一個 IP 都要完成同樣的工作，而且通過請求瞭解正在使用哪個協定也非常麻煩。

在這裡，我們事實上不需要做任何這類工作，您可能已注意到，我們連一行代碼都沒有編寫。如果我們要添加額外的標識提供程式，則只需操作 ACS 管理門戶網站上的幾個螢幕即可，而不會對應用程式本身造成任何影響。如果 IP 改進了它們的協定，則 ACS 會對其代碼做出更改以適應新的條件，我們的應用程式甚至會完全不知道已經發生了變化。

ACS：結構和功能

既然已經親自體驗過 ACS 的強大功能，您就可以簡單瞭解一下 ACS 的概念以及它的工作原理了。這裡將需要一些理論知識，但您會發現您在演練前面所述的方案時已經瞭解了大部分需要瞭解的內容。

ACS 根據基於聲明的標識 原則運行。基於聲明的標識背後的主要設計理念是，標識事務中的每個實體都扮演著一個或多個規範的角色，這些角色有四種，如下麵的簡短清單所示：主體、標識提供程式 (IP)、依賴方 (RP) 和聯合身份驗證提供程式 (FP)。在本演練中，您已經看到了所有這些角色的運轉。這些實體之間的交互可歸結為請求、獲取和轉發安全權杖，如圖 8 所示。

圖 8 請求、獲取和轉發安全權杖

主體是由使用者扮演的角色，也就是需要進行身份驗證的實體。IP 是一個實體，用於存儲主體的帳戶：使用者名、憑據和特性等。IP 使用一個或多個 STS 來公開其身份驗證功能和頒發權杖。RP 是主體要使用的應用程式。這三個角色對於描述最基本的情況已經足夠了：主體從 RP 信任的 IP 處獲取一個權杖，然後將該權杖用於 RP，從而完成身份驗證。

我們在演練過程中有件事沒有說明，那就是權杖不只用於表示身份驗證操作的成功結果，還用於傳輸描述使用者的以下特性：名稱、電子郵寄地址角色和 RP 需要瞭解且由 IP 提供的任何其他內容。如果您回想一下簽名安全權杖的屬性，就會明白這些特性為何無法篡改，以及它們如何通過加密確保來自特定的 IP。這意味著，一個 RP 可以根據對生成它收到的特性的 IP 的信任度來確定這些特性是否有效。想像一下在現實生活中您需要證明某些事情的情況 – 例如，您實際上住在某個位址。公司經常要您提供公共事業帳單，主要是因為他們對公共事業公司的信任度比對您的信任度更高。儘管資訊是一樣的（位址），但生成此資訊的 IP 就使情況完全不一樣了。

當某個特性作為安全權杖的一部分發出時，我們將該特性稱為聲明。這個概念非常重要，它為整個方法提供了名稱，而 ACS 所做的每件事幾乎都是圍繞聲明展開的。我們先要瞭解另一個概念，然後再深入討論一下相關細節。

儘管您可以用主體-RP-IP 角色為每個系統建模，但這種方法在實際操作中並不是十分方便。如果一個 RP 信任多個 IP（正如我們方案中的情況），模型就會要求 RP 維持多個關係並處理不同的協定，等等。第四個角色 FP 在這裡就派上用場了。FP 是一個或多個 RP 與一個或多個 IP 之間的仲介，如圖 9 所示。

圖 9 作為仲介的聯合身份驗證提供程式

FP 信任多個 IP，它的行為方式與應用程式一樣，期望獲得由 IP 生成的權杖。反過來，RP 也信任 FP，目的是讓 FP 公開自己的 STS（用於為 RP 頒發權杖）。FP 負責處理使用各個 IP 的細節，同時始終對 RP 顯示相同的外觀，所以可以對 IP 進行配置和解除配置而不會影響 RP。FP 也可以將來自不同 IP 的聲明轉換為對 RP 更有用的聲明。它可以規範化不同的傳入聲明類型和額外聲明（如角色或許可權）等。

正如您猜想的那樣，ACS 扮演著 FP 的角色，如圖 10 所示。

圖 10 扮演聯合身份驗證提供程式角色的 Windows Azure AppFabric 存取控制服務

當您創建服務命名空間之後，可以在雲中獲取完全屬於自己的功能完備的 FP。該 FP 在預設模式下包括四個不同的 STS 端點，這些端點全都提供適用于不同應用程式類型的不同協定：WS-Federation 用於登錄到網站；WS-Trust 用於調用 SOAP Web 服務；OAuth WRAP 和 OAuth 2 用於 REST Web 服務；Web API 用於一般情況。這些都是用來將您的應用程式配置為將身份驗證外包的端點。

正如我們看到的，ACS 已預配置為信任各個 Web IP，它還通過為這些 IP 提供頁面或可嵌入代碼來改善在這些 IP 中進行選擇的體驗。除此之外，ACS 還能用於與商用 IP（如 Active Directory Federation Services 2.0 (AD FS 2.0)）建立信任關係，這些 IP 會公開 STS 端點本身。在實際操作中，ACS 會公開您在將網站配置為信任 ACS 時已看到的“添加 STS 引用”功能的對應功能。將 AD FS 2.0 用作 IP 的做法非常有用，因為它允許您在需要時重用使用者帳戶，包括 Windows Azure 託管應用程式中的帳戶（這些帳戶傳統上只在內部部署中有效）。商用 IP 還有另一個有用的功能，那就是它們通常會提供大量聲明集，在權杖處理過程中可以使用這些聲明集來添加複雜的身份驅動邏輯。

ACS 允許您以規則的形式描述聲明轉換邏輯，這是一個簡單但又功能強大的機制。例如，您可以為客戶分配一個角色，方法很簡單，只需在“如果傳入名稱識別字聲明具有值 X，請添加類型角色的輸出聲明和值 Y。”行中輸入相應內容即可。

此處討論的所有功能都可以通過您在本演練中使用的管理門戶網站訪問；或者，也可以利用基於 OData 的管理服務訪問，該服務可在與現有流程集成的同時完全控制 ACS 設置。

我想多說一句，我們這裡只是介紹了 ACS 功能的一些皮毛。我們歡迎您查看身份標識開發人員培訓工具包和 Windows Azure 平臺培訓工具包中的動手實驗室，以便更深入地探討瞭解方案。如果您要為網站、Web 服務或 Web API 簡化訪問管理，那麼 ACS 就能助您一臂之力！

Vittorio Bertocci* 是開發人員和平臺推廣團隊的架構推廣人員，還是擴大的工程團隊（負責生產基於 Microsoft 聲明的平臺的元件）的成員。他負責 .NET 開發人員社區的標識推廣以及身份標識開發人員培訓工具包和第 9 頻道的“IdElement 秀”節目等方案的實施。他最近撰寫了“Programming Windows Identity Foundation”(Microsoft Press, 2010) 一書。*

Wade Wegner* 是 Microsoft 的高級技術推廣人員，負責影響和推動 Microsoft 對於 Windows Azure 平臺的技術策略。您可以通過他在 wadewegner.com 上的博客或在 twitter.com/WadeWegner 上的 Twitter 與他聯繫。*

*衷心感謝以下技術專家對本文的審閱：*Kent Brown