本文章是由機器翻譯。

ASP.NET Web API

透過 Windows Azure AD 與 Microsoft OWIN 元件保護 ASP.NET Web API 的安全

Vittorio Bertocci

隨著 Web API 的作用變得更加突出,所以不會需要確保你可以使用它滿懷信心地在高價值方案中,可能會暴露敏感性資料和操作。

業界清楚地集中保護依賴于 OAuth 2.0 標準的其餘部分 Api 的一個解。在實踐中,不過,這不會提供詳細的指導,在專案一級應做哪些工作。此外,現有的類和安全通信的 Microsoft.NET 框架中的工具旨在與特定的應用程式類型 (回發基於 Web UX 應用程式) 一起工作。他們不是一個很適合 Web Api 和他們啟用的多用戶端方案。因此,確保 Web API 一直相當手工活動。它並不一定是不安全的但在解決方案之間差別很大,需要太多的自訂代碼。

Visual Studio2013年的發行版本,你可以留下的。此版本引入了創新ASP.NET工裝和安全中介軟體從 Microsoft.NET (浩然) 元件,使保護您的 Web API 簡單打開 Web 介面。ASP.NET的新工具和範本讓您配置一個直接,外包到 Windows Azure 活動目錄 (AD) 的身份驗證的 Web API 專案排放所需的代碼的本地專案中和在 Windows Azure AD 中的相應條目。

在這篇文章,我就會顯示你如何利用這些新的Visual Studio2013年功能來創建簡單的 Web API 由 Windows Azure 廣告保護。我還會向您如何創建測試用戶端,以便您可以看到在行動中的 API。我也會看看在幕後,可以作為一個起始點,如果你想更深入的探索更多高級的方面的這種情況下會發生什麼。

憑據請

身份驗證歸結為消息發送到伺服器,以包括某種形式的憑據,可以驗證他的身份或檢索他的屬性時要求調用方。然後,伺服器的授權使用這一資訊 — — 確定是否訪問應授予和在什麼條件。

資源往往卸載大多數到外部服務提供者,俗稱為權威或身份標識提供程式的身份驗證功能。這些供應商照顧重型任務如入職,分配憑據,處理使用者生命週期流動 (如密碼恢復),提供一個使用者介面為使用者身份驗證,在多個協定、 多個身份驗證因數管理、 欺詐檢測和更多憑據驗證。

與這些職能走,剩下的唯一的身份驗證任務是驗證身份驗證成功在選擇的權力。這通常涉及檢查安全權杖,由頒發機構到後成功的身份驗證的調用方的資料片段。

安全權杖通常是根據特定的格式,由一個鍵,會毫不含糊地確定頒發機構,並包含一些資料的獨特關係的目標資源的權杖進行數位簽章精心製作的。資源接收請求時,它會查找一個伴隨的權杖。如果它找到一個滿足必需的驗證屬性,則調用方進行身份驗證。

在該級別的詳細資訊,該模式為所以一般它可以描述很多不同的身份驗證方法。我會通過將其應用到這種情況下將高級別角色指派給具體的實體。

該資源資源將會是我需要確保ASP.NETWeb API 2 專案。您可以與更細細微性應用的身份驗證要求。例如,您可以定義行動,以確保安全和離開他人接受匿名呼叫者的一個子集。

管理局我將把配置要卸載它到 Windows Azure AD,平臺即服務 (PaaS) 提供給每個 Windows Azure 訂閱伺服器上的身份驗證需要的 Web API。Windows Azure AD 專門用於支援基於雲計算的應用程式工作負載。該服務存儲有關使用者 (屬性和憑據) 和組織結構的資訊。如果你如此選擇,或住在雲上樓宇基礎設施無需完全,您可以與您的 Windows 伺服器活動目錄中,同步其資料。

幾乎每個線上的 Microsoft 服務 (Office 365、 Intune 和 Windows Azure) 充分利用了 Windows Azure 廣告為其身份驗證和目錄需要。開放標準和對共同協定的支援,您可以連接到 Windows Azure 廣告從幾乎任何應用程式 (Web UX,Web API,本機用戶端、 伺服器到伺服器,等等) 和平臺。我會演示如何在 Windows Azure AD 中註冊您的應用程式,充分利用其 OAuth 2.0 終結點。

權杖格式及驗證 OAuth 2.0 規範並不授權任何特定的標記格式,但是 JSON Web 權杖 (JWT) 格式 (bit.ly/14EhlE8) 為其餘的情景已成為事實上的標準。Windows Azure AD 和 Microsoft 浩然元件支援的智威湯遜格式 OAuth 2.0 流動。我提到這主要是為了提供一些背景。智威湯遜採集和驗證的技巧的是所有的得到照顧,中介軟體和權杖格式是透明的應用程式代碼。

用戶端當資源依賴于管理局來處理的身份驗證時,它有效地從用戶端解耦。使用者 (和用戶端應用程式) 如何獲得權杖將成為使用者和權力機構之間的事。這是偉大的代碼可維護性,但如果你想要看看您在行動中的 API,您仍然需要設置用戶端。您將學習如何在 Windows Azure AD 中註冊 Web API 的本機用戶端,以及如何使用 Windows Azure AD 身份驗證庫 (ADAL) 針對 Windows Azure 廣告啟用.NET 豐富的用戶端應用程式使用者進行身份驗證並獲得權杖,確保對 Web API 的調用。

圖 1 我要生成的解決方案的各個元素。Don擔心,如果你不了解的一些標籤在此時:一切都將推出走通過解決方案的發展。


圖 1 端到端解決方案的體系結構

創建 Web API 專案

若要創建 Web API 專案,在Visual Studio2013年中使用的新ASP.NET工具和範本。打開Visual Studio並創建一個新的ASP.NETWeb 應用程式專案。在新專案對話方塊中,選擇 Web API 範本。按一下更改身份驗證按鈕。

則會顯示與您可以為 Web API 外框, 選擇的身份驗證樣式中所示圖 2。選擇組織的帳戶,您就可以使用 Windows Azure 廣告作為權威機構。(對所有的選項的詳細資訊,請參閱 bit.ly/1bhWngl.)這裡的目標是收集關於您的 Web api 是從身份管理角度來看,重要的特性的資訊,確定哪個 Windows Azure AD 實例 (俗稱"租客") 您應該配置處理身份驗證。


圖 2 組織帳戶身份驗證對話方塊

第一下拉清單確定是否只是一個 Windows Azure AD 租客 (典型的業務線應用程式) 或多個 Windows Azure AD 租戶 (正如你期望從軟體作為服務 [SaaS] 應用程式) 應使用該應用程式。如果在您的公司或多個組織的員工將使用您的應用程式,如果該應用程式將由來自許多公司的使用者訪問,您通常會選擇單一的組織。儘管如此,這些兩個備選方案目前只支援ASP.NETWebForms 和ASP.NETMVC 應用程式。目前,Web API 專案範本支援只有單一的組織選項。

域文字方塊用於標識哪個 Windows Azure AD 租客應該註冊您的應用程式。它通常是與您的 Windows Azure 訂閱關聯的企業目錄,但您具有管理認證的任何目錄會 (還有更多的後面)。在創建時,每個 Windows Azure AD 租客有一個,在表單 yourorganization.onmicrosoft.com 的關聯的三級域。一般情況下,您會將租客向您已經擁有的一個或多個域相關聯。在示例中的圖 2,我用我自己的功能變數名稱, cloudidentity.net

存取層級下拉清單指定應用程式應該具有對該目錄的存取權限。預設值,單一登入,可以讓您的應用程式的目錄的問題標記。這是一個簡單的確認應用程式已註冊。當局不會發出未註冊的應用程式,即使進行了成功的身份驗證權杖。

其他存取層級包括"讀取目錄資料"和"讀取和寫入目錄資料,"其中分別啟用應用程式查詢目錄並修改其內容。這是通過圖形 API,基於 REST 的程式設計介面設計,讓應用程式從任何平臺與 HTTP 堆疊委派訪問到的目錄。我會呆在一起的預設存取層級單一登入並不表明 Web API 專案中的關係圖。然而,是非常強大的功能的 Windows Azure 的廣告。對 Windows Azure AD Graph API 的詳細資訊,請參閱 bit.ly/1aByRLS

之後您輸入到您的 Windows Azure AD 租客相關聯的域,請按一下確定以生成專案。該工具將執行兩個任務:

  1. 它將向所選的 Windows Azure AD 租客伸出,並添加一個條目描述正在創建的應用程式。
  2. 它將發出一個 Web API 專案的代碼,在從 Microsoft 浩然有機肥添加必要的安全中介軟體­敗訴處理 Windows Azure AD 身份驗證和生成必要的初始化代碼來驗證傳入權杖根據選擇的 Windows Azure AD 租客。

第一項任務通過 Graph API 執行 (Visual Studio是本身的圖形 API 的用戶端)。若要添加的條目描述您要創建的目錄的應用程式,它需要證明您具有必要的許可權的目錄中寫入該目錄從獲得權杖。這就是為什麼,一旦您按一下了確定,Visual Studio您提供您在中看到的身份驗證提示圖 3


圖 3 帳戶登錄身份驗證提示

你需要做的就是為目錄輸入管理員憑據。該工具將驗證您具有必要的許可權來執行所需的操作。當您按一下確定時,Visual Studio聯繫 Windows Azure 的廣告,並將創建的專案檔案。

您現在已準備好執行指定 Windows Azure AD 租客的唯一調用方訪問的完全配置 Web API。讓我們看一看。

轉到解決方案資源管理器窗格中,你會看到一個名為 Startup.cs 檔在根目錄中。如果您從上個月的問題中讀取HowardDierking"越來越開始與武士刀專案"(msdn.microsoft.com/magazine/dn451439),你已經知道此檔中的類在應用程式啟動時被調用。在這種情況下,執行很簡單:

public partial class Startup
{
  public void Configuration(IAppBuilder app)
  {
    ConfigureAuth(app);
  }
}

因為它是標準的您會希望找到一些 App_Start 解決方案資料夾下的類中定義的 ConfigureAuth 方法。它是實際的 Startup.Auth.cs 檔。這裡是它看起來像:

public partial class Startup
{
  public void ConfigureAuth(IAppBuilder app)
  {
    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
      new WindowsAzureActiveDirectoryBearerAuthenticationOptions
      {
        Audience = ConfigurationManager.AppSettings["ida:Audience"],
        Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
      });
  }
}

這款應用程式。使用 * 命名約定表明該方法將一個中介軟體實現添加到浩然管道。在這種情況下,添加中介軟體檢查傳入的請求是否授權 HTTP 標頭包含一個安全權杖。這是你如何確保安全 OAuth 2.0 持票人權杖規範的請求 (請參閱 bit.ly/W4OqA3)。如果它找到一個標記,它是通過標準檢查數目的驗證:是該權杖當局發出的打算嗎?它已在運輸途中被篡改嗎?它已過期是嗎?

如果權杖看上去不錯,中介軟體專案中一個主體,其內容將主要分配給當前使用者和分保控制到管道中的下一個元素。如果權杖不通過檢查,中介軟體發送回相應的錯誤代碼。

如果沒有標記,中介軟體只允許調用而無需創建一個主體去。授權邏輯,通常在授權篩選器的形式,使用存在或缺席的主體 (和它的內容) 來決定是否請求或訪問被拒絕。

傳遞給中介軟體中,WindowsAzureActiveDirectoryBearerAuthenticationOptions 的單個參數提供設置用於確定標記的有效性。它在專案創建期間捕獲的原始值,並將它們存儲在 web.config 檔中。觀眾值是由該 Web API 聞名到 Windows Azure AD 的識別碼。攜帶不同的聽眾任何標記是為另一個資源和應予以拒絕。

租客屬性指示用於外包的身份驗證,Windows Azure AD 租客。中介軟體使用該資訊來訪問,租客和讀取 (例如,哪些鍵應該可用於驗證的權杖簽名) 的所有其他屬性,確定一個權杖的有效性。

那些幾個自動生成的程式碼都有需要對 Windows Azure AD 與調用方進行身份驗證。剩下的 Web API 專案上做的唯一事情是裝飾用 [授權] 您想要保護的方法。將它添加到 ValuesController 中的所有方法。(為了簡單起見,我正與範本附帶的預設控制器)。

現在,你如何驗證 Web API 的行為方式按您的意思?最簡單的方法是創建一個測試用戶端。

註冊本機用戶端

正如 Windows Azure 的廣告不會為沒有已註冊的 Web Api 發出權杖,Windows Azure 要求所有用戶端請求的標記以及註冊。要為特定的 Web API 獲得權杖,註冊的用戶端必須也有顯式授予訪問 Windows Azure AD 中的 Web API。甚至在任何使用者嘗試身份驗證之前,這種設計階段設置必須到位。現在我會教你怎麼使用 Windows Azure 門戶來註冊一個用戶端應用程式和創建的、 它關係到您創建的 Web API 的許可權。

通過訪問 Windows Azure 門戶啟動。我要對我先前使用的同一帳戶進行身份驗證。為了節省時間,我會直接定位到 Windows Azure 門戶為我 Windows Azure AD 租客。您通過將您的租客域添加到通常的入口網站位址,在我的案例 HTTP://manage.windowsazure.com/cloudidentity 獲取該 URL。淨。

導航到租客特定 URL 是比狩獵"標誌使用您組織的帳戶"框中,從一般的登錄頁面更快。請注意,如果 Windows Azure AD,你工作不是一個管理員或 co-管理您的 Windows Azure 訂閱,你就會想要登錄到入口網站,使用您通常的憑據 (Microsoft 帳戶或其他組織的實體)。

一旦門戶荷載,Active Directory 的圖示從清單中選擇可用的服務,請按一下您的目錄,然後在應用程式選項卡。您將看到所有的應用程式創建的包括為新的 Web API 專案條目的清單。要創建一個新條目,請按一下從命令列上的頁面底部的添加按鈕。你會看到在所示的對話方塊圖 4。技術上,您可以定義只是任何種類的應用程式,這將有效的用戶端,為您的 Web API。選擇一個本機用戶端應用程式和移動到下一個螢幕。


圖 4 的第一步在 Windows Azure Active Directory 門戶上添加應用程式精靈

下一個和最後一個螢幕會要求您輸入應用程式的重定向 URI。此 URI 是只是一個識別碼在 OAuth 2.0 權杖採集流動期間用來發出信號到調用方的身份驗證過程的互動部分已經結束。其餘的權杖採集過程將進行無需使用者輸入。取決於平臺,您開發本機用戶端,您可能必須處理不同的約束。例如,Windows 應用程式商店將會要求您使用 ms app: / / 協定架構,如果您想要使用某些功能 (請參閱詳細資訊在 bit.ly/13KrM6i)。

在這種情況下,我會寫一個經典的.NET 桌面應用,這種情況發生,相當寬容。會做任何有效的 URI。我用 HTTPs://cloud­的身份。net/myWebAPItestclient 以確保我會記住此用戶端的是什麼。

只要我完成的應用程式項,我看到中顯示的網頁圖 5


圖 5 快速啟動頁

更新您的代碼部分提供你需要時您編寫用戶端應用程式的資訊。這包括用於重定向 URI 設置和用戶端 ID (簡單的識別碼),你需要時手工創建權杖請求向權力機構。

對 Web Api 部分的配置訪問提供一個連結到入口網站的區域,您可以指定用戶端應該有權訪問的 API。如果您按照該連結,然後你就會在應用程式屬性頁中所示圖 6。在底部,您將看到下拉清單,使您可以指定您希望您的用戶端來訪問 Web API。注意到下拉清單中列出的應用程式,您定義和內置的 Api,具體而言,Windows Azure 廣告圖 API。


圖 6 在 Windows Azure Active Directory 入口網站上的本機用戶端應用程式屬性頁

選擇 Web API 專案條目和命中保存。那,一切都準備好了在 Windows Azure AD 用戶端獲取權杖為您的服務中。如你需要的一些資料也將顯示離開瀏覽器打開到該頁面。

創建一個簡單的用戶端專案和測試 Web API

你終於準備好創建測試用戶端並為經過身份驗證的 Web API 兜一圈。您可以創建幾乎任何用戶端類型,在任何平臺上提供一個 HTTP 堆疊。為了簡化並維持權杖的任務,Microsoft 提供了 ADAL,這使得它易於安全信任­ticate 對 Active Directory (Windows Azure 和 Windows 伺服器) 而無需成為專家的身份驗證協定。

Microsoft.NET 框架的庫已被釋放,在 Windows 應用商店開發者預覽。(有關如何實現此方案與 Windows 應用程式商店的教程,請參見 bit.ly/17YtYVg.)最終,將針對所有主要用戶端平臺的版本。

因為.NET 版本已經普遍可用,就會使用它在這裡。除了跨不同的堆疊的句法差異,在這裡,您將學習將很容易適用于其他平臺和應用程式類型。如果你不能再等,請記住在這裡描述的場景中的所有通信遵循開放標準和詳細的記錄。你可以很容易地編寫代碼的權杖請求邏輯。有關使用 Windows Phone 8 的示例,請參見 bit.ly/YatATk

該專案是為新的Windows Presentation Foundation(WPF) 應用程式內相同的解決方案,但您可以選擇任何想用一個使用者以對話模式運行的專案類型。創建專案後,我將添加一個按鈕和一個 click 事件處理來觸發 Web API 呼叫邏輯。

ADAL NuGet 包作為分發。將其添加到該用戶端專案,只需從Visual Studio中的工具功能表中打開的封裝管理員主控台,鍵入安裝包 Microsoft.IdentityModel.Clients.ActiveDirectory-1.0.0 版。現在添加代碼,在圖 7 的 click 事件處理常式。

圖 7 添加 Click 事件處理常式代碼

private async void btnCall_Click(object sender, RoutedEventArgs e)
{
  // Get token
  AuthenticationContext ac = new AuthenticationContext(
    "https://login.windows.
net/cloudidentity.
net");
  AuthenticationResult ar =
    ac.AcquireToken("https://cloudidentity.
net/WindowsAzureADWebAPITest",
    "a4836f83-0f69-48ed-aa2b-88d0aed69652",
    new Uri("https://cloudidentity.
net/myWebAPItestclient"));
  // Call Web API
  string authHeader = ar.CreateAuthorizationHeader();
  HttpClient client = new HttpClient();
  HttpRequestMessage request = new HttpRequestMessage(
    HttpMethod.Get, "https://localhost:44353/api/Values");
  request.Headers.TryAddWithoutValidation("Authorization", authHeader);
  HttpResponseMessage response = await client.SendAsync(request);
  string responseString = await response.Content.ReadAsStringAsync();
  MessageBox.Show(responseString);
}

Don擔心,如果代碼看起來令人生畏。它將是清楚地一分鐘

第一行初始化新的 AuthenticationCoNtext。在應用程式的代碼中,一個 AuthenticationCoNtext 實例表示要使用的權力。在這種情況下,權力是由 URI HTTPs://login.windows 代表我 Windows Azure AD 租客。淨額 / [mydomain]。將使用相同的邏輯連接到上處所目錄通過傳遞其活動目錄驗證服務 (AD FS) 伺服器的位址 (請參閱 bit.ly/1d553F0 的詳細資訊)。

第二行要求 AuthenticationCoNtext 權杖。有很多方法的手工創建權杖的請求 — — 每個方案和應用程式的類型要求不同的參數。在這種情況下,想要指定一個權杖想為其的資源是我 Web API。所以我通過其 Windows Azure AD 條目的識別碼。這是作為觀眾在 Web API 專案中使用相同的值。然後,因為它是請求該權杖的本機用戶端,我需要從我離開在瀏覽器中打開應用程式佈建頁中的用戶端 ID 和重定向 URI 我客戶的傳遞。

這是所有我需要怎樣才能獲得權杖。剩下的代碼將該標記放在正確的 HTTP 標頭 OAuth 2.0 規範,並執行的實際調用。

現在給解決方案兜一圈。更改後要立即啟動的所有專案的解決方案,請按 F5。儘快執行命中對 AcquireToken 的調用,你就會得到身份驗證對話方塊中所示圖 8。ADAL 照顧聯繫的右端點和呈現而無需編寫任何 UI 代碼中彈出的對話方塊中由伺服器提供的身份驗證經驗。


圖 8 Active Directory 身份驗證庫的身份驗證對話方塊

當我從我目錄租客提供的任何有效的使用者憑據時,回來拿一個權杖。後面的代碼向 Web API 請求標頭中的權杖。安全中介軟體對它進行驗證。因為所有的驗證參數都是一個匹配,它會發送回的 HTTP 狀態碼 200 的結果,成功地結束這種情況下的概念證明。

只是為了消遣,請再次按一下按鈕。你會看到這一次你離開一個權杖回正確,而不會提示。這是因為 ADAL 具有內置的權杖緩存,用於跟蹤權杖。它甚至照顧默默地刷新過期的權杖,只要有可能。

要從這裡去哪裡

我幾乎不抓了抓的你可以完成與 Web API,Microsoft 浩然元件,Windows Azure AD 表面和 ADAL。頒發由 Windows Azure AD 的標記不是簡單的身份驗證的證明。他們攜帶豐富的使用者資訊,您可以輕鬆地從使用者的主體和尖端的授權邏輯用於訪問。身份驗證過程可以遠遠超出的使用者名和密碼在此處顯示。

從多個身份驗證因素對無縫單點登錄在聯合方案中的可能性是無止境的。與圖形 API 的整合可以讓你訪問一個功能的寶庫。您可以查詢超出了當前經過身份驗證的使用者,從簡單的人民選擇器功能先進的組織結構進行爬網的資訊的目錄。

這些功能可以將添加到基於雲計算的 Web Api 的功能。直到現在,你不得不運行它們房地公司防火牆後面。您還可以使用類似的代碼與 Windows 伺服器 Active Directory,雲和房地上對稱性的功能最明顯的例子之一。

當然,您也可以發佈 Web API 對 Windows Azure 而無需更改一行代碼 — — 身份驗證功能將繼續工作。您將需要更改的唯一是對用戶端專案。服務的 URL 將根據新的應用程式位置更改。然而,獲取權杖的邏輯可以保持完全相同的因為資源識別碼沒有綁在該資源的物理位址。

Vittorio Bertocci  是一個主要程式管理器上的 Windows Azure 的廣告團隊,他看起來之後的開發人員體驗。Bertocci 是眾所周知的開發人員社區為他十年之久佈道活動有關的身份和發展通過他的書,他會話在重大會議上,他的博客 (cloudidentity.com) 和 Twitter 飼料 (twitter.com/vibronet)。

衷心感谢以下 Microsoft 技术专家对本文的审阅:HowardDierking和丹尼爾 · 羅斯
HowardDierking是在 Windows Azure 框架和工具,團隊的專案經理他的工作重點在哪裡ASP.NET、 NuGet 和 Web Api。以前,Dierking擔任 MSDN 雜誌的主編,並為 Microsoft 學習也跑,開發人員認證計畫。他花了 10 年前微軟作為一個開發人員和應用程式具有焦點建築師分散式系統。

丹尼爾 · 羅斯是目前正在ASP.NETWeb API 的 Windows Azure 應用程式平臺團隊的高級專案經理。ASP.NET上工作之前他曾對 WCF,開始第一次發貨在.NET Framework 3.0 時。他的激情包括取悅顧客,使框架簡單和便於使用。