匯出 (0) 列印
全部展開

使用 Azure AD 將登入新增至 Web 應用程式

更新日期: 2014年5月

note附註
此範例已過時。其中的技術、方法和 (或) 使用者介面指示已被更新的功能取代。若要查看可建立類似應用程式的更新版範例,請參閱 WebApp-OpenIDConnect-DotNet

.

本逐步解說將示範如何使用 Azure AD 在 ASP.NET 應用程式中實作網頁單一登入。其中的指示將著重在運用與您 Azure 訂閱關聯的目錄租用戶,因為它構成您組織中企業營運 (LOB) 應用程式之識別提供者的明顯選項。

網頁單一登入方案通常需要設定 Web 應用程式以將其驗證功能委外給一個外部實體,這通常稱為「識別提供者 (IdP)」。明確而言,這表示要將應用程式設定為根據 SAML-P、WS-同盟或 OpenID Connect 等登入通訊協定,將未驗證的要求重新導向至 IdP。

授權單位 (或稱 IdP) 會處理驗證經驗,且通常需要透過某些佈建程序事先得知 Web 應用程式。驗證成功後,瀏覽器就會被重新導向回 Web 應用程式並隨附一個含有連入使用者相關資訊的安全性權杖;應用程式會驗證權杖 (通常透過可判別識別的中介軟體),而如果檢查成功,就會將使用者視為已通過驗證並將其登入。

此高階說明同樣適用於 Azure AD。本文件將說明如何使用 Visual Studio 2012 和 .NET Framework 4.5 中的 Windows Identity Foundation (WIF) 類別,來設定 MVC 4 應用程式以使用網頁登入通訊協定。其中將說明如何在 Azure AD 租用戶中佈建相同的應用程式,以及如何設定應用程式的登入設定為連接到該租用戶。逐步解說結束後,您的 Web 應用程式便已完整設定好,可進行組織單一登入。

此逐步解說的目標是要協助您了解 Azure AD 的運作方式:所牽涉到的不僅僅是將此處所述的簡化版方案組合在一起而已。除了提供您建置可行範例的明確指示,本文件也會介紹成品和概念,讓您更熟悉 Azure AD,並了解如何在此處所討論的案例以外運用其功能。以方框附註形式呈現的額外小節,在執行逐步解說時並非絕對必要,但如果您有興趣在自己的方案中使用 Azure AD,則建議您一併閱讀這些部份。

本文件的教學課程部份分為下列幾節:

  • 必要條件:本節列出完成本逐步解說必須符合的所有要求。

  • 解決方案架構:本節提供 LOB (企業營運) 應用程式適用之網頁 SSO 方案的高階介紹。我們會檢視讓 SSO 運作的功能元件、設定連線架構 (您可於稍後依照文件指示來增加細節)。

  • 使用 Azure AD 目錄租用戶:本節介紹 Azure AD 租用戶和將在本案例中使用的功能。其中也簡短描述 Azure 管理入口網站之 Active Directory 區段的主要元素。

  • 將應用程式連接至 Azure AD:本節說明如何使用 Visual Studio 2012 適用的「身分與存取工具」以在 MVC 應用程式中啟用網頁單一登入,並將驗證設定連結至選擇的特定 Azure AD 租用戶。

  • 進階主題:本節將不著墨在基本知識,而是將更深入討論一些重要主題,並涵蓋將您的應用程式移往下一層級所需執行的一些其他工作。

完成本教學課程需要具備下列必要條件:

如果您有疑問或需要協助,請參閱Preparing for Azure AD Solutions and Scenarios

單一租用戶應用程式架構

此逐步解說的著重於下列案例:開發人員計劃將其 Web 應用程式部署至雲端,且只想供來自 Azure Active Directory 租用戶的使用者進行存取。若要完成此工作,他必須:

  1. 在 Azure AD 租用戶中登錄 Web 應用程式。知道此應用程式後,Azure AD 就會接受向其提出驗證的使用者要求。

  2. 在應用程式前端加入一些項目,以便:

    1. 可將未驗證的要求封鎖,並重新導向至正確的 Azure AD 租用戶以進行使用者驗證

    2. 可以辨識已獲 Azure AD 驗證的使用者並授與存取權

我們將使用 Azure 管理入口網站來實作第一個步驟。您將學會如何在您的 Azure 訂閱中佈建新的 Azure AD 租用戶,以及如何使用 Azure AD 管理入口網站功能來登錄應用程式。

步驟 2 則可使用允許跨組織邊界 (或網際網路) 進行驗證作業的多種高階通訊協定來實作。

在 .NET 平台中,第二個步驟可簡化為設定 .NET 現成提供的類別來使用宣告式識別或同盟驗證。這些類別統稱為 Windows Identity Foundation (WIF),包含 HTTP 模組和組態設定,可用來新增執行步驟 2 所述之重新導向和驗證工作的攔截層。Visual Studio 2012 提供的工具可協助您自動設定 Web 應用程式,以使用 WIF 將驗證委外給支援特定 Web SSO 通訊協定 (例如 WS-同盟) 的外部授權單位。此逐步解說將說明如何搭配 Azure AD 使用這類工具。

Azure Active Directory 是可提供 Office 365 和 Intune 等 Microsoft 服務項目的識別骨幹的服務。如果您訂閱這些服務,且想重新使用與該服務關聯的目錄租用戶,請建立新的 Azure 訂閱並使用 [加入使用者] 功能以加入該租用戶中的管理員。此逐步解說不提供該程序的詳細指導方針。

每個訂閱都有一個 Azure AD 租用戶及關聯的目錄。如果已自動產生租用戶,其目錄將命名為 [預設目錄],不過您可以變更此名稱。在逐步解說的這一部分,我們將新增使用者至目錄,接著新增應用程式。

目錄租用戶建立後,會設定為將使用者和認證儲存在雲端。如需如何將目錄租用戶與內部部署 Windows Server Active Directory 整合的詳細指示,請參閱目錄整合

如果您有疑問或需要協助,請參閱Preparing for Azure AD Solutions and Scenarios

Azure AD 案例和方案 (以及程式碼範例和範例應用程式) 需要使用 Azure Active Directory 網域中的使用者帳戶。如果您嘗試以 Microsoft 帳戶 (例如 Hotmail.com、Live.com 或 Outlook.com) 登入應用程式,登入會失敗。如果您已有 Active Directory 網域中的使用者帳戶 (例如 User@Contoso.onmicrosoft.com 帳戶),則可使用此帳戶來登入此案例。否則請建立新的使用者。

  1. 移至 Microsoft Azure 管理入口網站 (https://manage.WindowsAzure.com),登入後按一下 [Active Directory]。(疑難排解提示:"Active Directory" 項目遺失或無法使用)

  2. 如果您的目錄名稱是「預設目錄」,請新增一個目錄,例如 "ContosoEngineering"。若要加入目錄,請在 Active Directory 頁面底部按一下 [加入],然後依照指示執行以加入新目錄。

  3. 按兩下目錄然後按一下 [網域]。建立使用者帳戶時,請使用出現在頁面上的網域名稱。例如,如果網域是 ContosoEngineering@onmicrosoft.com,請在該網域中建立使用者名稱,例如 Test@ContosoEngineering@onmicrosoft.com。

  4. 若要在網域中建立使用者帳戶,請按一下 [使用者] (如果您沒看到 [使用者] 索引標籤,請按兩下目錄名稱。[使用者] 索引標籤會顯示在每個目錄的特定頁面)。按一下頁面底部的 [加入使用者]。

  5. 選取 [組織中的新使用者]。在新網域中加入使用者,例如 Test@ContosoEngineering.onmicrosoft.com,然後按一下頁面底部的核取記號。

    輸入使用者名稱和網域
  6. 在 [使用者設定檔] 頁面上,指派組織角色給使用者。為了進行測試,最好至少有一位使用者具備「全域管理員」角色、一位使用者具備「使用者」角色。

    輸入使用者角色

在上一個步驟中,Azure 管理入口網站會產生暫時密碼,供使用者用來進行第一次登入。完成第一次登入後,使用者必須變更暫時密碼。請務必保存此暫時密碼,因為我們需要用它來測試案例。

至此,我們已有一個具有有效使用者的租用戶目錄,可在網頁單一登入案例中提供驗證授權單位。

暫時密碼

  1. 現在要開始進行一些應用程式設定。開啟 Visual Studio,按一下 [新增專案] 並挑選 [ASP.NET MVC 4 Web 應用程式]。在 [新增 ASP.NET MVC 4 專案] 視窗中選取 [內部網路應用程式],確定檢視引擎設為 Razor,然後按一下 [確定]。在此逐步解說中,我們將使用 ExpenseReport 做為專案名稱。

    note附註
    此逐步解說假設您的 Visual Studio 安裝是使用預設值加以設定。如果您曾變更基本組態 (例如開發期間 Web 應用程式的裝載位置),則需據以調整指示。



    Visual Studio 中的新專案

    您可將此逐步解說的指示套用至任何現有的 VS 2012 Web 應用程式、MVC 或 Web Forms,只要您沒有會對 ASP.NET 要求處理管線進行大幅變更的邏輯即可。但為求簡化,我們將從頭開始建置新專案。

    note附註
    此逐步解說提供如何設定 .NET 方案的詳細指示,但目標為其他平台和程式設計堆疊時,也能達成相同的結果。Azure AD 的網頁登入功能採用開放式通訊協定,而每個主要平台都有支援此類通訊協定的程式庫和工具。您必須調整詳細步驟以便適應每種堆疊的語法和作法,不過高階的工作細分則可全面適用。

    Visual Studio 會為您建立新的 MVC 專案,並已設定為在 IIS Express 上執行:我們不會再新增其他功能,因為預設值已足夠用來示範如何增加網頁登入功能。唯一例外是應用程式使用的端點。依預設,Visual Studio 會將您的應用程式設定為透過 HTTP 提供內容服務:但此設定不適合用來建立安全的工作階段,因為會造成通訊未受保護,並允許潛在攻擊者竊取 Cookie 和權杖。Azure 不會嚴格強制使用 HTTPS,所以在開發階段這不是必要步驟。但這仍是理想的做法。

  2. IIS Express 讓您可以輕鬆地從 Visual Studio 直接啟用 HTTPS。在 [方案總管] 中選取您的專案,然後在 [內容] 窗格中將 [SSL 已啟用] 切換為 [True]。

    您會看到先前空白的 SSL URL 現在已填入新位址。選取此位址並複製至剪貼簿。



    複製 SSL URL

  3. 現在需要讓 Visual Studio 知道,我們想在偵錯期間一律使用 HTTPS 端點。返回 [方案總管],在專案上按一下滑鼠右鍵並選擇 [內容]。選擇左邊的 [Web] 索引標籤,向下捲動至 [使用本機 IIS Web 伺服器] 選項並在 [專案 URL] 欄位中貼上 HTTPS URL。儲存設定 (CTRL+S) 然後關閉 [內容] 索引標籤。



    變更專案 URL

    至此,我們的應用程式已適合設定為運用 Azure AD 進行登入。下一個步驟是讓您的 Azure AD 租用戶知道這個特定的應用程式。

  1. 將 Visual Studio 最小化並返回 Azure 管理入口網站的 [Active Directory] 索引標籤。稍早的逐步解說中,我們在 [使用者] 區域操作,現在要在 [應用程式] 區域操作。在頁面頂端按一下 [應用程式]。



    整合的應用程式

    本區域會列出在您目錄租用戶中登錄的應用程式。符合以下條件時,表示該應用程式已在租用戶中登錄

    • 應用程式在目錄中具有項目,用來描述其主要參數:名稱、關聯的端點等。稍後會提供更多詳細資訊。

    • 應用程式本身已獲權限,可以在目前的目錄租用戶中執行某些作業:作業範圍從要求登入權杖到能夠查詢目錄。同樣地,稍後會提供更多詳細資訊。

    Important重要事項
    未先進行登錄的應用程式,將無法運用 Azure AD:這是基於安全考量 (只應允許管理員核准的應用程式) 和實際考量 (與 Azure AD 互動需要用到特定的開放式通訊協定,而這些通訊協定需要知道描述應用程式的重要參數)。

  2. 假設我們是從頭建立此目錄租用戶,已登錄應用程式的清單仍會是空的。事實上,第一個項目將是我們才剛在 Visual Studio 中建立的應用程式:本節內容就是關於將它登錄為應用程式。

    假設這是第一個應用程式,請按一下畫面底部 Azure 管理入口網站命令列上的 [加入] 按鈕來開始此程序。接著會提示您如下所示的畫面:



    告訴我們您的應用程式

    透過 Azure 管理入口網站登錄應用程式的程序已經被建構為傳統精靈,後續畫面將根據您的選擇,分別呈現收集必要資訊的步驟。

    上圖顯示的是這些畫面中的第一個畫面。提供的選項簡單易懂:

    • 顯示名稱:此處輸入的文字將做為人類可讀的 Moniker,當使用者 (無論是管理已登錄應用程式清單的管理員或決定要授與目錄存取權給應用程式的客戶) 需對應用程式進行一些動作時可以用來參考該應用程式。如需詳細資訊,請參閱使用 Azure AD 開發多租用戶 Web 應用程式一文。

    • 存取類型:這組選擇鈕可讓您指定應允許應用程式對目錄租用戶執行哪些作業。基於本教學課程的目的,我們的目標只是要為應用程式設定網頁登入,適當的選項是 [單一登入]。

      note附註
      其他文件則將深入探討應用程式權限的主題,不過此處我們僅簡單提及相關原則,供您了解一些背景資訊。

      Azure AD 會以名為 ServicePrincipal 的實體代表應用程式。正如名稱所示,這些實體類似於大家較熟悉的使用者主體,不同之處在於它們是用來描述應用程式。

      登錄應用程式的動作,實際上是為應用程式在其應具有存取權之目錄執行個體的租用戶中建立 ServicePrincipal

      應授與給特定應用程式的存取層級,則由相對應 ServicePrincipal 所屬的角色來決定。在此逐步解說中,您不需要選擇讀取與寫入存取層級,但如果您選擇了,則登錄流程會增加一些步驟來收集其他資訊,例如在執行這些查詢時要使用哪些金鑰來進行驗證:在此情況下,金鑰也會儲存在用來描述應用程式的 ServicePrincipal 中。使用 Graph API 來查詢 Azure AD 主題在這方面有更詳細的資訊。

      透過應用程式登錄程序授與的權限只在存取目錄本身時有效,並無法判斷其他 Azure 資源 (例如 SQL Azure 資料庫、管理入口網站區段及類似資源) 的存取原則。

  3. 輸入應用程式的名稱並選擇 [單一登入] 存取類型後,按一下右下角的箭頭移往下一個畫面。

    應用程式屬性 在此畫面中,Azure 管理入口網站會收集服務驅動登入通訊協定流程所需的重要參數。您需在此處輸入以下資訊:

    • 應用程式 URL:此參數代表 Web 應用程式的 address。在此範例中,這相當於 https://localhost:44341/,即 IIS Express 指派給您應用程式的位址。如果您到此為止都確實按照指示進行,則此位址應仍存在剪貼簿中,您只需貼上即可。 您輸入的值將用於開發階段期間:將應用程式部署至其目標預備或生產環境後,就必須返回管理入口網站並修改位址以讓其符合新應用程式的位置。本逐步解說稍後將討論如何進行。

      Warning警告
      Azure AD 需要知道您應用程式的位址,以便在 Azure AD 頁面上成功驗證使用者後,可將流程重新導向回您的應用程式。

      您必須事先提供此位址:如果 Azure AD 能將驗證流程重新導向至任意位址,攻擊者就能輕鬆劫持驗證流程並竊取權杖。事先登錄應用程式的 URL,可以保證只會將您應用程式專用的驗證權杖傳送給您的應用程式。

    • 應用程式識別碼 URI:此參數代表 Web 應用程式的 identifier。Azure AD 在登入時使用此值來判斷驗證要求是否是要允許使用者存取此特定應用程式 (而非所有已登錄的應用程式),以便套用正確設定。

    note附註
    應用程式識別碼 URI 在目錄租用戶中必須是唯一的。其理想的預設值是應用程式 URL 值本身,但採用這個策略有可能無法遵守唯一性限制。在本機裝載環境 (例如 IIS Express 和「Azure 網狀架構模擬器」) 中開發應用程式很容易產生範圍有限的位址,被多個開發人員或甚至同一位開發人員的多個專案重複使用。一個可行的策略是在應用程式 URI 值後面附加一些值,做為區別元素。

    另外請注意,應用程式識別碼 URI 是 URI,因此不需對應至任何網路可定址端點。這表示您可選擇與應用程式 URL 無關的項目:事實上,雖然本教學課程是使用全新的應用程式,但您偶爾也會登錄已經擁有應用程式識別碼 URI (在此處所用的登入通訊協定 WS-同盟中,應用程式識別碼 URI 稱為 realm) 的現有應用程式,在這種情況下您應該會在此處使用該值。在使用 Azure AD 開發多租用戶 Web 應用程式主題中,我們會強調多租用戶引進的一些額外限制。

  4. 輸入 [應用程式 URL] 和 [應用程式識別碼 URI] 後,您可以按一下右下角的核取方塊按鈕。

    快速入門 如此便完成了登錄程序,您的應用程式現在已在目錄租用戶中擁有自己的項目,Azure AD 也已準備好代表您的應用程式處理 Web 驗證。

    通知您登錄成功的畫面會提供將 Web 應用程式設定為使用 Azure AD 進行登入所需的資訊。也就是說:[使用 Azure AD 啟用單一登入] 區段包含一些您將必須貼回至 Visual Studio 的設定。

    將瀏覽器保持開啟在此頁面,並切換回 Visual Studio 以便進行逐步解說的下一個工作。

現在 Azure AD 已準備就緒,可以為您的應用程式發出驗證權杖,而啟用網頁登入的最後一個步驟,就是將應用程式本身設定為使用正確的驗證通訊協定來處理要求。強制執行通訊協定可讓應用程式在使用者對應用程式的工作階段開始時,叫用 Azure AD (特別是您的目錄租用戶) 來處理使用者驗證。

使用網頁登入通訊協定時,請務必了解驗證機制的一些背景資訊。您可在「進階」一節找到更多詳細資料。

我們選擇的專案範本是 MVC 4 內部網路應用程式。該範本通常需仰賴 Windows 整合式驗證來確保應用程式的使用者已獲驗證。該機制在網路層級運作:它會套用至發佈至內部網路的任何服務,不需新增任何驗證邏輯至應用程式本身。

在內部網路之外部署應用程式時,因為這屬於雲端應用程式的情況,就無法再仰賴網路層級驗證。在這些情況下處理驗證的最常見策略包括在應用程式前端新增一些中介軟體,在更高層級重新建立必要的驗證檢查。額外層級可以處理攔截未驗證的要求、實施驗證通訊協定、重新導向使用者以驗證外部應用程式、將已驗證使用者的相關資訊傳回給應用程式、管理工作階段,以及存取控制所需的所有一般工作。

此策略在業界全面適用於所有主要平台、開發堆疊與登入通訊協定;連接方式和程式設計模型可能有所不同,但一般模式大致相同。

在此逐步解說中,我們會透過 WS-同盟通訊協定將應用程式連接至 Azure AD:這只是實作網頁 SSO 的其中一個可行選項,SAML-P 則是另一個最常見的選項。

.NET Framework 4.5 原生支援 WS-同盟:在 ASP.NET 應用程式範圍中實施通訊協定流程、處理驗證和處理工作階段所需的所有類別都顯示在方塊中。

簡言之:.NET 4.5 提供一組 HttpModule,供您在應用程式的 HTTP 管線中將其啟動。這些模組是設計為參考已知的組態區段,其中包含應用程式和驗證授權單位 (在此例中是您的 Azure AD 租用戶) 的通訊協定參數。當要求進入時,模組會檢查這些要求,並實施適當的驗證通訊協定:例如,收到未驗證的要求時,模組會從組態讀取 Azure AD 租用戶的參數、使用這些參數來編寫 WS-同盟登入訊息,並用來自動重新導向使用者為透過 Azure AD 進行驗證。

note附註
.NET Framework 4.5 中專用於宣告式識別相關工作的類別子集稱為 Windows Identity Foundation (WIF)。目標為舊版架構 (3.5 和 4.0) 的應用程式也能實作此逐步解說所述的步驟,方法是運用舊版 WIF 獨立發行的程式庫 (從此處下載)。但是請注意逐步指示會有差異,考慮到兩個版本並非完全相容 (類別存在於不同的命名空間中),您必須使用不同 Visual Studio 版本的工具 (2008 和 2010,從此處下載)。

Visual Studio 2012 提供點選工具,可協助您設定應用程式來使用 WS-同盟進行網頁登入:您可使用工具的 UI 來提供您信任之驗證授權單位的一些重要資訊,工具會發出對應的組態項目。在此逐步解說中,您只需編寫一點程式碼,因為工具事實上會為您自動產生大部分的程式碼。

  1. 現在您已知道如何實作網頁登入,讓我們改用「身分與存取工具」來設定應用程式。在 [方案總管] 中,以滑鼠右鍵按一下應用程式的專案,然後按一下內容功能表中的 [身分與存取...]。

    識別和存取 Visual Studio 會顯示如下所示的對話方塊。

    識別和存取提供者 您要執行的工作都位在 [提供者] 索引標籤中,也就是目前顯示的索引標籤。針對本逐步解說的目的,我們將忽略目前工作用不到的所有選項。

  2. 工具會列出您可用來委外驗證的各種授權類型。在我們的特定情形中,將使用 [商務識別提供者]:按一下對應的項目,亦即上面數來第二個選項。

    識別和存取設定 選取此選項後,對應的 UI 元素就會顯示在下方面板中。這些控制項要求的資訊,正好符合先前小節所述應用程式登錄程序結束時所顯示的項目。以下是您必須輸入的資訊,從上往下為:

    • 輸入您應用程式的應用程式識別碼 URI (領域):這是您在登錄期間所定義的應用程式識別碼。切換回顯示管理入口網站的瀏覽器視窗,複製 [使用應用程式識別碼 URI 更新您的程式碼] 欄位中的對應值並貼至此處。

    • 輸入 STS 中繼資料文件的路徑:「STS 中繼資料文件」是一個檔案,包含您想連接之授權單位的機器可讀取描述:工具會取用它來決定登入流程的必要參數值 (下面會提供更多詳細資料)。每個 Azure AD 租用戶會公開一份這種文件,其位置會在登錄程序結束時提供。切換至管理入口網站,從應用程式登錄頁面複製對應值,切換回工具並在此欄位中貼上路徑。

      note附註
      當您在文字方塊中貼上中繼資料文件的路徑時,工具會顯示憑證無效的警告。這是因為中繼資料文件使用自我簽署憑證,可加以忽視。

    按下 [確定]。工具會前往指定的中繼資料文件、讀取授權單位的參數 (用於登入的端點位址、用於確認驗證權杖之簽章的 X.509 憑證、所發出驗證權杖的格式和版本等等),並使用該資訊來產生將應用程式連接至 Azure AD 的必要項目,並將這些項目加入至 web.config

下列清單說明工具加入至 web.config 的主要項目。如需更詳細的說明,請參閱本文件的「進階」一節。

  • system.identityModel 和 system.identityModel.services 的 <section> 項目:這些是讓組態了解識別特定之組態設定的必要項目。

  • <system.web> 中的 <authorization> 設定:工具會將現有 ASP.NET 驗證設定自動變更為必須驗證通往應用程式的每個要求。如此會強制實施所謂的「保護傘重新導向」行為,將每個未驗證的要求重新導向至驗證授權單位 (而不是讓使用應用程式的某些部分可讓未經驗證的使用者使用)。這種行為是 LOB 應用程式的預設值,假設使用者已透過授權單位登入,驗證通常會無訊息進行。如果開發人員想將此行為改成根據個別案例提供驗證需求,只需據以變更 <authorization> 設定即可。

  • <system.webServer/modules> 中的 WSFederationAuthenticationModule (FAM) 和 SessionAuthenticationModule (SAM):這些項目會在應用程式的 HTTP 管線中,將負責處理強制使用 WS-同盟進行驗證的 HttpModule 加入。FAM 是負責強制執行通訊協定的模組:登入要求、權杖驗證與登出管理是其負責的主要流程。SAM 處理工作階段:明確而言,它會產生工作階段 Cookie、加以驗證並強制其存在於每個要求、處理工作階段的長度等。其行為由以下所述的組態元素驅動。

  • <system.identitymodel/identityConfiguration> 區段:此元素決定驗證階段的應用程式行為。例如:在子元素 ValidatingIssuerNameRegistry 中,它會記錄這些授權單位的名稱及其用於簽署的憑證,以便儲存一份可提供驗證服務的受信任授權單位清單。

  • <system.identitymodel.services/federationConfiguration> 區段:此區段提供驅動 WS-同盟流程的必要參數:用於登入要求的授權單位位址、包含在要求中之應用程式的識別碼等。

若想運用 Azure AD 進行網頁登入,您只需要自動產生的組態。您不需要在應用程式本身編寫任何驗證特定的程式碼。 如果您想存取使用者識別的資訊,只需查詢目前主體中的宣告即可。例如,假設您想存取目前使用者的姓氏和名字。您不需要知道驗證如何進行的任何相關資訊,只需使用下列程式碼:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

從 .NET 4.5 開始,.NET 中的每個識別都以 ClaimsPrincipal 代表。在此例中,目前的 ClaimsPrincipal 是在驗證 Azure AD 產生的驗證權杖時所建構,並由使用者在登入時出示。

每個 ClaimsPrincipal 都包含一組宣告與屬性,說明目前使用者經證明為授權單位所驗證的使用者。在我們的逐步解說中,主體中的宣告是 Azure Active Directory 在權杖中發出的宣告:如需可用宣告的完整清單,請參閱線上文件。

Azure AD 會為已驗證使用者發出一組固定宣告。以下是 Azure AD 使用之所有宣告的快速參考,您可在文件中找到完整說明。

 

型別 範例中的值 描述

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

目前應用程式之已驗證使用者的唯一、不可變、不可重複使用的導向識別碼

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

目錄中使用者的識別碼。對於查詢該使用者的相關目錄有幫助。

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

目錄租用戶的識別碼

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

使用者的名字

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

使用者的 UPN

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

使用者的姓氏

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

驗證使用者的授權單位識別碼,如同網頁登入通訊協定 (在此例中是 WS_Federation) 中所示

至此,您的應用程式已具備展示透過 Azure AD 進行網頁登入所需的一切資訊,但程序尚未完成。您至少還要新增兩個重要功能:支援登出和自動重新整理授權單位的通訊協定參數。

以下兩節將詳細說明如何新增這兩個功能:建議您也進行這些步驟,之後再前往「執行應用程式」一節。

現今使用的網頁登入通訊協定通常包含執行分散式登出作業的規定:這些流程不僅由目前應用程式用來取消其目前使用者的工作階段,也用來連絡授權單位,以通知它們應傳播登出命令給相同授權單位所建立之所有其他應用程式的工作階段。WS-同盟也不例外,提供可在 WIF 的物件模型中完整實作的完整登出流程。在本小節中,我們將討論如何加入分散式登出功能至範例應用程式:這其實就是在使用者經驗中提供正確的連結以觸發登出流程,以及產生要傳送給您 Azure AD 租用戶的適當登出訊息。

  1. 從加入 SignOut 控制器至應用程式開始。您只需在 [方案總管] 的專案底下找到 [控制器] 資料夾、在其上按一下滑鼠右鍵,選擇 [加入],然後按一下 [控制器]。將其命名為 SignOutController,選擇 [空白 MVC 控制器] (這通常是預設設定),然後按一下 [加入]。

  2. 我們需要用到一些新組件的類別,因此必須加入這些類別的參考。再次在 [方案總管] 中,以滑鼠右鍵按一下 [參考] 節點、選擇 [加入參考...]、在 [搜尋組件] 欄位中輸入 system.identitymodel.services,然後從主要清單中選取對應的組件。按下 [確定]。

  3. 返回新建立的 SignOutController.cs 檔案。新增 using 指示詞至下列項目:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    現在變更 SignOutController 類別的實作,如下所示:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    此處簡短說明程式碼的作用。

    • 第一個方法 Index()https://localhost:44341/SignOut 形式提供要求服務。這是檢視的位址,您稍後將在本逐步解說中步驟中加入此位址。其目的是要發出成功登出的訊號,我們將在下一個方法中用到。

    • SignOut() 方法提供 https://localhost:44341/SignOut/SignOut 形式的要求服務,包含主要登出邏輯。

    • 第一行擷取 web.config 中 WIF 用來追蹤 WS-同盟設定的物件:我們需使用它來製作目前應用程式專用的登出訊息。

      note附註
      參考組態值通常是理想的做法 (與硬式編碼值或從客戶存放庫取得來源相對),因為如此可讓您的程式碼適應並配合其餘的通訊協定設定:無論部署前後的組態檔案變更過多少次設定,邏輯都能維持運作。

    • 第二行和第三行會建立我們希望授權單位用在登出流程結尾處的回覆地址。我們希望該地址指向先前討論的檢視:因此,程式碼會取得目前要求的 URL,並消除結尾 'SignOut'。從要求衍生地址可以保證能為用戶端正確解析,而從裝載層取得位址可能會在使用負載平衡器時導致內部連接埠問題。

    • 第四行使用 WIF 製作 WS-同盟登出訊息,傳遞授權單位的 URL 和上一行定義的回覆地址。您在其連線表單中就能輕鬆地直接建立訊息,不過使用 WIF 物件模型可以協助您編寫更簡潔的程式碼,並忽略大部分的語法細節。如果您對登出訊息的成果有興趣,在稍後小節執行應用程式時請務必擷取 HTTP 追蹤,或參考此處的規格。

    • 第四行將目前應用程式的識別碼加入至訊息,如 <wsFederation> 組態元素的 realm 屬性中所記錄。

    • 第五行使用 SAM (稍早的自動產生組態說明中有描述) 來清理本機工作階段:這包括刪除在登入期間產生的工作階段 Cookie,以及任何必要的本機資源清理。

      note附註
      此處示範的範例應用程式還沒有很多作用,但您的實際應用程式可能會在使用者的工作階段配置資源。若是這樣,您可以在 Global.asax 檔案中加入對應的事件處理常式來清理關閉工作階段時應捨棄的資源,以便運用 SAM 的 SigningOutSignedOut 事件。

此處所用的檢視將會非常簡單:如先前所述,其目的只是為登出流程建立有意義的傳回點。

  1. 在 [方案總管] 中,以滑鼠右鍵按一下 [檢視] 節點並加入 SignOut 資料夾。

  2. 在該資料夾中,以滑鼠右鍵按一下資料夾並按一下 [加入] 然後按一下 [檢視],加入檢視。將此新檢視也命名為 SignOut。在檢視檔案 (SignOut.cshtml) 放置一些預留位置呈現程式碼,做為發生登出時的訊號。例如:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. 您可能記得在前一節中,我們將應用程式設定為透過「保護傘重新導向」來處理驗證。這表示如果我們在成功登出 (這是我們的目的) 後嘗試存取此檢視,我們會被立即重新導向至 Azure AD 再次登入!為避免發生這種情形,您可以使用 web.config 中的 <location> 元素來建立驗證原則的例外狀況。

    找到第一個 <system.web> 元素,在緊鄰其上方貼上下列程式碼片段:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    這會告知 ASP.NET 任何人都能存取 SignOut 路徑,包括未經驗證的使用者。此安排可讓您在瀏覽器中查看呈現的檢視,即使已成功登出亦然。

  1. 現在,應用程式已具備登出功能,現在只剩將此功能呈現給使用者運用。以下是一個很簡單的方法:在 [方案總管] 中開啟 Views\Shared 路徑中的 _layout.cshtml。搜尋字串 "Hello,",找到負責在典型 MVC 4 版面配置上方呈現登入資訊的程式碼,然後如下所示修改登入區段:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

這會在對登入使用者的歡迎詞右邊新增登出命令,因此可從任何檢視觸發登出動作。

「身分與存取工具」已將您的應用程式設定為接受來自您所選擇之 Azure AD 租用戶的權杖。為了這麼做,此工具將連接至目標 Azure AD 端點的必要通訊協定參數都快取至 web.config。此外,它也儲存在驗證期間所使用的金鑰資訊,以驗證連入權杖確實源自於您 Azure AD 租用戶:這些是代表您租用戶的簽發者名稱,以及應該用來驗證權杖簽章的公開金鑰 (採用 X.509 憑證的形式)。

定期更新加密編譯金鑰是常見的安全做法,Azure AD 簽署金鑰也不例外:在固定的時間間隔後,舊金鑰會過期,新金鑰將取代簽發者簽署邏輯和租用戶中繼資料文件中的金鑰。 如有緊急狀況,也可能不經警告而立即更新金鑰。

每次輪替簽署金鑰時,您的應用程式設定也必須跟著變更:依照逐步解說所示方式進行至此,這表示需重新執行工具,才能讀取新的中繼資料文件,並重新整理 web.config 項目。

若想將停機時間降至最低,建議可在應用程式中直接加入自我修復邏輯,讓您可以程式設計方式取用中繼資料文件以及回應金鑰輪替,而不需要操作員介入。以下是如何實作這類功能的範例。

  1. 依本文件先前所述方法使用 [方案總管],加入組件 System.IdentityModel 的參考。

  2. 加入下列 using 指示詞至 Global.asax 檔案:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. 接著加入下列方法至 Global.asax 檔案:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    此處的邏輯相當簡單。ValidatingIssuerNameRegistry 是身分與存取工具用來記錄信任哪些授權單位,以及使用哪些金鑰來驗證所發出權杖之相關資訊的類別。WriteToConfig 是靜態方法,用來讀取中繼資料文件中的簽發者設定 (在此例中是從組態中擷取,由方法的第二行、工具第一次執行時儲存),並用來建立或更新所指定路徑中檔案的對應組態區段 (由方法第一行中的目前 AppDomain 建構)。

  4. 若要在應用程式週期中插入 RefreshValidationSettings(),請從 Application_Start() 叫用,如下所示。

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Application_Start 呼叫 RefreshValidationSettings 可以保證 web.config 是在安全時間進行修改,要是您在稍後的應用程式週期進行修改,可能會觸發重新整理。

Important重要事項
從應用程式自動重新整理驗證金鑰時,您需要套用一些預防措施。您需要減緩的主要威脅是 DNS 劫持,攻擊者會使用惡意程式碼將您指向惡意中繼資料文件並誘使您的應用程式信任錯誤的金鑰。

如果您未覆寫用於處理 HTTP 要求的 .NET 預設值,則由於中繼資料文件裝載於 HTTPS 端點,所以已減緩上述案例。DNS 劫持可將要求重新導向至惡意端點,但這些端點仍無法通過 HTTPS 伺服器驗證:因為未實際擁有裝載中繼資料文件的網域,所以攻擊者無法取得發出憑證,因此用戶端得以偵測到伺服器有問題,因而避免被誤導。

偶爾有些開發案例會要求您關閉 HTTPS 驗證 (通常透過 ServicePoint 類別)。如果您使用本節所示的自動中繼資料重新整理邏輯,則在將應用程式部署至生產環境前,請務必還原 HTTPS 驗證設定。

  1. 我們現在終於可以觀察應用程式執行動作了。按下 F5:隨即會開啟一個瀏覽器視窗,嘗試存取「建立 MVC 應用程式」一節中專案設定所指定的 URL。

    最初,您會收到憑證錯誤。這是預期的行為,請按一下 [繼續瀏覽此網站 (不建議)]。若是實際執行的應用程式,請勿忽略此錯誤,但在此逐步解說中是可以接受的。

    憑證錯誤 如果您注意網址列,可能會看到應用程式的 URL 短暫出現;但是應用程式前端的 FAM 模組會立即將此呼叫辨別為未獲驗證,而從組態讀取應執行動作,接著觸發將登入重新導向至 Azure AD 的動作。URL 網址列會換成授權單位的 URL,且系統會提示使用者透過 Azure AD UI 進行驗證。

    note附註
    如果您最初是使用 Microsoft 帳戶來登入管理入口網站,則稍早建立的新使用者帳戶將無法用來管理您的 Azure 訂閱。如果您在以新使用者身分登入應用程式後嘗試瀏覽回管理入口網站,則會收到錯誤訊息。您必須改用用以建立目錄租用戶的帳戶來登入管理入口網站。如果您最初使用 Azure AD 帳戶登入管理入口網站,而稍早建立的新使用者帳戶獲授與「全域管理員」角色,則此新使用者可以管理您的 Azure 訂閱。

    登入 AAD
  2. 輸入您在此逐步解說第一節中,於 Azure 租用戶建立之使用者的憑證。按下 [登入] 按鈕。

    您也許記得當初在 Azure AD 租用戶中建立使用者時,管理入口網站指派了一個暫時密碼給它。您必須使用該密碼進行驗證:但假設這種密碼本來就是暫時的,在第一次登入作業中,系統會要求您選擇適當的使用者密碼,才能繼續驗證流程。完成此步驟後,就會恢復正常的應用程式登入流程。

    應用程式首頁 驗證成功完成後,WIF 會處理來自連入驗證權杖的宣告,而我們在首頁控制器加入的簡單顯示程式碼會使用該權杖。現在開始,您可以在網站間瀏覽,不需再次驗證:每個回傳都會攜帶 SAM 模組處理的工作階段 Cookie。

  3. 若要觀察當您終止工作階段時會發生什麼事,請按一下右上角的 [登出] 連結。您會觀察到我們先前編碼的重新導向,最終進入下方檢視。

    登出 若要確認您是否已確實登出,請按一下其他任何 UI 元素:驗證週期會重新開始。

本文件的逐步解說部份向您說明對 Web 應用程式加入網頁登入時的必要步驟。文件的其餘部份則超出基本知識範圍,更深入討論一些重要主題,並涵蓋將您的應用程式移往下一層級所需執行的一些其他工作。

在本節中,您將學會如何修改應用程式的設定,以便在 Azure 網站中部署與執行該應用程式。應用程式的大部分仍維持不變:您只需留意要修改您應用程式的新位址和工作階段管理。

文件的這個部份需要您有個 Azure 網站可做為應用程式部署的目標。如果您已經有這樣的網站,則可以直接使用;如果沒有,請參考這份文件以了解如何建立和發佈 Azure 網站。如果您依照該文件中的教學課程進行,請在下載發行設定檔後立即停止:部署應用程式前,我們必須調整幾個項目。

在 Azure 管理入口網站中調整應用程式的設定

如果您還記得關於應用程式登錄的那一節,您應記得在 Azure AD UI 中定義應用程式的一個關鍵參數就是應用程式本身的 URL。到此為止的逐步解說步驟都假設本機 IIS Express 是應用程式的位置,但部署至 Azure 網站代表應用程式的 URL 會改變,而 Azure AD 中的設定必須反映這一點。

  1. 瀏覽回管理入口網站,選取左側的 [Active Directory] 索引標籤、按一下目錄租用戶、選擇 [應用程式] 標頭、按一下對應於您先前使用之應用程式的項目。按一下 [設定] 標頭,您會瀏覽至一個畫面,您可在此修改建立時所輸入的應用程式設定。針對此教學課程的目的,請忽略畫面上方區域並向下捲動至單一登入區段。

    單一登入
  2. 找到 [回覆 URL] 文字方塊,在此輸入目標 Azure 網站的位址 (例如 https://aadga.windowsazure.net/)。這可讓 Azure AD 在驗證成功後,傳回權杖至您的 Azure 網站位置 (而您稍早在非同系列文章中於開發期間使用的位置)。更新值後,點擊畫面底部命令列的 [儲存]。

note附註
您可能注意到 [應用程式識別碼 URI] 仍在使用您稍早在文件中建立的 localhost 值。

技術上來說,只要識別碼是 URI 形式且在目前目錄租用戶的所有應用程式中是唯一的,則針對此處討論的這類應用程式,可以使用任何值;這也是為什麼主要指示不包含更新該值。

不過為了方便管理,您可能會想修改 [應用程式識別碼 URI] 來承擔更能代表您應用程式的值。典型的範例是回覆 URL 值的衍生項目。

請注意,如果您變更 [應用程式識別碼 URI] 值,則在部署前您必須對應用程式套用更大規模的變更。稍後會提供更多詳細資訊。

準備在 Azure 網站中執行應用程式

網頁登入組態的主要部分均已可供雲端使用:您只需套用一個變更,這主要是因為 Azure 網站之功能的關係。

網頁登入程序會建立工作階段 Cookie,並在發出驗證要求後立即傳送。工作階段 Cookie 由 WIF 中介軟體建立,預設透過 DPAPI 簽署及加密 (如需背景資訊,請參閱此文件),用以避免用戶端濫用 (例如變更宣告清單以提升權限)。不過,Azure 網站中的 IIS 設定會阻止使用 DPAPI 來保護工作階段,因此您必須變更 WIF 保護相關 Cookie 的方式。.NET Framework 4.5 提供現成可用的替代方法,此方法運用 MachineKey (請參閱此處文件) 並可在 Azure 網站中毫無問題地運作。

身分與存取工具讓進行此項變更變得很簡單。

  1. 在 [方案總管] 中的專案上按一下滑鼠右鍵,選擇 [身分與存取...] 並選取 [組態] 索引標籤。您會看到如以下螢幕擷取畫面般效果的項目:

    識別和存取 Azure 網站
  2. 只需勾選 [啟用 Web 伺服陣列就緒 Cookie] 旗標並按下 [確定]。此工具將會負責加入 web.config 中的必要元素 (在實際操作中,會以 MachineKeySessionSecurityTokenHandler 取代預設類別 SessionSecurityTokenHandler) 以便切換為使用 MachineKey 作為 Cookie 保護方式。

    note附註
    如果在先前步驟中您已在 Azure 管理入口網站中變更 [應用程式識別碼 URI],則可透過此 UI 輕鬆套用這些變更至您的專案:只需將 [應用程式識別碼 URI] 值貼至上方兩個文字欄位中然後點擊 [確定] 即可。工具會將這些變更套用至組態檔案中的正確位置。

    您也可以選擇暫時關閉 ASP.NET 自訂錯誤訊息,只需在 web.config 檔案的 <system.web> 區段加入項目 <customErrors mode="Off" /> 即可。如果您在部署階段遇到問題,此功能可協助您疑難排解,但在移往生產環境前請記得再度開啟此項目:攻擊者可能會利用詳細錯誤訊息來探查您應用程式的缺口,而 customError 可以讓此狀況不發生。

這就是您在讓應用程式備妥來以 Azure 網站形式執行時,所需進行的工作。使用您的發佈設定來部署應用程式,然後開啟瀏覽器、瀏覽至您應用程式的 azurewebsite.net 位址,接著依照逐步解說之應用程式測試小節中的相同流程進行:假設我們已將所有自訂邏輯設計為與位置無關,您便可以在內部部署中執行與您經歷相同的操作。

身分與存取工具會自動產生必要的組態設定,讓您的應用程式能夠透過 WS-同盟與 Azure AD 租用戶整合。在最理想的情況下,您都不需要實際查看這些設定,但偶爾您會想改變預設操作行為,或需要疑難排解問題。在此類情況下,透過 WIF 組態設定進行會有幫助。

網頁登入流程中使用的 WIF 類別和方法在 MSDN 中都有詳細記載,此處提供身分與存取工具進行修改後的 web.config 註釋版本。為了讓您方便參考,我們也加入由發佈至 Azure 網站小節衍生的變更。

note附註
為求清楚起見,本文件包含完整的 Web.config 原始程式碼,但只有 WIF 相關區段加上註釋。

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

以上組態沒有註解。

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

在以上組態中,本區域載入的類別是為了讓 ASP.NET 能夠讀取和轉譯 WIF 所用組態區段,以便模型化 WS-同盟流程和驗證設定。

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

以上組態沒有註解。

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

在以上組態中,身分與存取工具會擷取 appSettings 項目,用於追蹤不會儲存在別處的重要設定 (例如中繼資料文件的位址,這將用在金鑰變換區段)。

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

在以上組態中,兩個 <location> 元素會切出 Web 應用程式中,不需驗證就能存取的兩個區域 (請見下文)。FederationMetadata 區段由身分與存取工具建立:此工具會建立用來描述應用程式的中繼資料文件,授權單位也能用來佈建應用程式。您在如何實作網頁登出的指示中自行加入 SignOut 區段。

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

在以上組態中,身分與存取工具預設會設定 ASP.NET 驗證和授權設定,讓 Web 應用程式中的每個部份 (上述例外情形除外) 都要求使用者經過驗證,之後才能提供要求服務。這通常適用於 LOB 應用程式,但開發人員可能有時會想保留能匿名存取的區域:如果您就是這種情形,請據以變更此處設定。

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

以上組態沒有註解。

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

在以上組態中,本區段中的項目會插入至實作核心通訊協定和工作階段處理功能的 SP.NET 管線 HTTPModule。WSFederationAuthenticationModule (FAM) 會強制使用 WS-同盟,其方法為驗證連入權杖以及根據通訊協定規格產生登入訊息給授權單位。SessionAuthenticationModule (SAM) 會與 FAM 協調以建立並驗證工作階段 Cookie。

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

以上組態沒有註解。

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

在以上組態中,<system.identityModel> 包裝所有 WIF 類別特定設定。它的第一個子元素 IdentityConfiguration 可提供與通訊協定無關的應用程式行為說明。AudienceUris 清單可提供 WIF 將在目前應用程式的連入權杖中視為可接受範圍的所有值;通常這些值會與應用程式的領域對應 (在 Azure AD 中則稱為應用程式識別碼 URI)。連入權杖必須宣告其預期收件者是此處所列的其中一個值,否則 WIF 會假設這是遭竊權杖並拒絕呼叫。

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

在以上組態中,ValidatingIssuerNameRegistry 元素包含可接受簽發者名稱-簽章檢查的索引鍵 Tuple。在此逐步解說中,設定會反映與您 Azure AD 租用戶關聯的值:此元素可保證沒有其他簽發者 (包括其他公司擁有的其他 Azure AD 租用戶) 可以獲得您應用程式的存取權。

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

在以上組態中,此元素會關閉 WIF 管線中的憑證驗證。此量值在 Azure AD 案例中為必要值 (假設使用自我簽署憑證):若未在本機憑證存放區安裝憑證本身,鏈結或對等驗證會失敗。請注意:這不會真的削弱 Azure AD 驗證的安全性,只要 ValidatingIssuerNameRegistry 可以確保使用的是正確憑證;但如果您在相同應用程式中使用 WIF 來信任其他簽發者,請小心這些設定也會延伸至那些簽發者。

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

此區段可讓您操作收集 WIF 用來處理連入安全性權杖的類別 (所謂的權杖處理常式)。這可用來影響個別處理常式的行為,或加入和移除處理常式型別。在此例中,工具移除了預設的工作階段處理常式 (其以 DPAPI 為根據,無法使用在 Azure 網站上),並換成能使用 MachineKey 的處理常式。

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

在以上組態中,<system.identityModel.services> 用於儲存 WS-同盟特定的參數。

具體而言,此處使用了 wsFederation 元素來記錄 Azure AD 租用戶的 WS-同盟登入端點、應用程式的領域 (應用程式識別碼 URI,會在登入時當成識別碼傳送),以及其他會影響 WIF 本機行為的旗標,例如當來自應用程式的 401 錯誤應一律觸發傳送登入訊息給授權單位 (passiveRedirectEnabled) 或是應允許清楚 HTTP 上的交易時。

此元素可用來指定許多通訊協定參數:以上只是可讓登入流程運作的最低需求。

本文件重點放在一個相當狹隘的工作,將 .NET 應用程式連接至 Azure AD 以透過 WS-同盟執行網頁登入。還有許多案例可供您探索:利用各種不同的開放式通訊協定、在各種現代平台上運用任何程式設計堆疊,或是直接在網路的通訊協定層級操作。

在部署應用程式至 Azure 的小節中,您已看到管理入口網站提供變更許多應用程式登錄設定的選項:在下一個逐步解說中您將能了解更多額外的控制項。此處僅會簡單介紹,當您選擇在通訊協定層級與 Azure AD 互動以進行網頁登入或其他受支援的流程時,應如何取得您需要的資訊。

  1. 在瀏覽器視窗中開啟 Azure 管理入口網站,瀏覽至 Azure AD 區段中的 [應用程式] 標頭。您會注意到畫面底部的命令列有一個項目:檢視端點。按一下這個項目。

    應用程式端點 對話方塊會列出您可透過程式設計方式,用來與 Azure AD 租用戶互動的所有端點。以下簡單介紹每個項目:

    • 同盟中繼資料文件: 用來將 Azure AD 租用戶描述為網頁登入授權單位之中繼資料文件的位置。正如您在逐步解說的自動重新整理金鑰相關小節中所見,本文包含 WS-同盟中繼資料參數,在相同套件中也包含 SAML 通訊協定中繼資料。如需詳細資訊,請參閱Federation Metadata

    • WS-同盟登入端點:所有 WS-同盟交易的進入點。這是您在逐步解說中同時用於登入和登出流程的端點。如需詳細資訊,請參閱WS-Federation Endpoint URL

    • SAML-P 登入端點: 用來在 SAML 通訊協定中實作登入流程的端點。如需詳細資訊,請參閱SAML Protocol Metadata and Endpoints

    • SAML-P 登出端點:用來在 SAML 通訊協定中實作登出流程的端點。如需詳細資訊,請參閱SAML Protocol Metadata and Endpoints

    • Azure AD Graph 端點:擷取目前 Azure AD 租用戶中儲存之目錄資訊的查詢必須使用 Graph API 語法,定址至此端點。如需詳細資訊,請參閱使用 Graph API 來查詢 Azure AD

    • OAuth2 權杖端點:此端點用於伺服器對伺服器驗證流程:例如,可以用來取得叫用 Graph 端點的存取權杖。如需詳細資訊,請參閱OAuth 2.0 (Preview Version)

社群新增項目

顯示:
© 2014 Microsoft