服務導向應用程式架構 (Service-Oriented Architecture) 在現代已是大型應用程式或企業系統的顯學，為了要達成服務導向架構，各家應用程式平台無不使出渾身解數，開發一套又一套的驗證與授權機制，它們都強調整合以及單一簽入 (Single Sign On) 的能力，並且可以將使用者資訊散布給各個應用程式，藉以識別使用者身份及進行授權，這對企業內部來說，只要高層命令一下達，基本上就可以很順利的推動，但對於外部系統或是資訊來自組織外部 (如社群網站) 時，單一簽入的能力就會受到很大的挑戰，因為外部系統的驗證機制未必會與企業內部所使用的相符，而多半是各自開發的，所以若要與外部應用程式或服務串接時，除非雙方有談定訊息交換的規範，否則不太可能一套涵蓋全部的範圍。
在一個與網際網路構連的環境中，只要是會開放資訊給外部的資源，基本上都不太可能會獨善其身，一定多少要和網路標準有關聯，驗證 (Authentication) 這件事當然也不例外，但網際網路發展至今，與驗證有關的開放式協定卻相對較少，隨著企業應用以及各類型的網路應用開始出現大量相互連結的需求時，尋求一個開放、大家可遵循的驗證提供協定已成為最需迫切解決的問題，所以才慢慢有像 Open ID 和 OAuth (Open Authentication) 的驗證協定出現，它們可以允許開發人員透過協定的通訊方式，由驗證資訊提供者 (Authentication Provider) 進行身份驗證後，核發票證 (Claim) 給使用者，而使用者再將票證傳送給應用程式進行檢查，以確認票證確實屬於該使用者，最後進行授權的動作。
而在社群網站 (如 Facebook) 以及主要網路服務供應商 (如 Google) 的推廣之下，開放式驗證協定已經被多數的網路應用程式所採用，像是要存取 Facebook 的資源時，應用程式必須要使用 OAuth 協定，並經過使用者授權後，才可以存取使用者授權範圍內的資源；而 Google Account 本身也有 Open ID 協定的支援，可讓應用程式利用 Google Acount 提供登入機制，而不需再自行維護會員帳戶資料表。現在也愈來愈多網站服務提供由社群網站帳戶登入的機制 (例如 stackoverflow.com)。
不過若要一次支援這麼多 OAuth 或 Open ID 的提供者，在程式開發上也不是那麼容易，首先，各家雖然都支援相同的協定，但對於動作要求則不太一致 (如訊息編碼)，開發人員又要為不同的提供者撰寫不同的邏輯，這樣會讓開發人員的工作量增加不少。另外，以企業的角度來看，他們要的可能就不是與社群網站結合，而是與合作夥伴結合，像是合作夥伴可使用他們自己的帳戶登入到企業的應用程式中進行資料的查詢或存取等動作，而企業間的資料交換也無法像 OAuth 或 Open ID 單純，可能要進一步驗證更多的資訊才可以授權。若有一個可以作為中間者的服務可替代開發人員實作這些功能的話，對企業或開發人員來說都是個不錯的選擇，而微軟的 Windows Azure AppFabric Access Control Services 2.0 就是要提供這樣的中間者服務。
Windows Azure AppFabric Access Control Services 2.0：
Windows Azure AppFabric Access Control Services 2.0 (以下簡稱 ACS 2.0) 是 Windows Azure AppFabric 上負責處理使用者驗證的驗證提供者之一，它除了繼續提供 ACS 1.0 的企業內部驗證機制外，在 ACS 2.0 則新增了下列功能：
- 支援外部驗證提供者 (Identity Provider)，目前包含 Google、Facebook、Yahoo 以及 Windows Live ID (預設支援) 等四種 Web 驗證提供者，以及以 ADFS 2.0 建置的 WS-Federation 驗證提供者。
- 支援 Open ID、OAuth 2.0 (Draft 13)、OAuth WRAP 0.9、WS-Federation 與 WS-Trust 等通訊協定。
- 支援 SAML 2.0、SAML 1.1 與 SWT (Simple Web Token) 等訊息交換規範。
- ACS管理服務支援 OData 協定，同時 ACS 1.0 的工具不再支援 ACS 2.0。
- ACS 2.0 可支援 Windows Identity Foundation 的工具。
在 ACS 2.0 中，應用程式被稱為 Relying Party Application，可以是 Web Application 或是 Web Service，而所有的應用程式都要先在 ACS 2.0 管理介面中註冊後，由 ACS 2.0 在使用者登入時核發 Issue Token (即 Claim) 給使用者，再由使用者交給應用程式檢查，整個應用程式的驗證流程如下圖：
基本上，原有 ACS 1.0 的程式碼是不太需要改變，但若想使用 ACS 2.0，則必須要先在 Windows Azure 的管理介面中，建立一個新的服務命名空間，或是將原本的命名空間刪除後重建 (但這樣的話原本的帳戶就要全部重建)，在管理介面中可以看到目前命名空間支援的是 ACS 1.0 或 2.0：
在建構好支援 ACS 2.0 的命名空間後，按下工具列中的 Access Control Service 按鈕，即會被帶到 ACS 2.0 的管理介面中：
在這個管理介面內，可設定要支援的 Identity Provider、設定應用程式、設定角色、設定 ACS 1.0 帳戶、設定管理服務帳戶等功能。
ACS 2.0 除了管理工具的變更外，它最大的特色之一就是可以和 Windows Identity Foundation (WIF) 整合，Identity Foundation 的工具可以直接存取由 ACS 2.0 產生的 Metadata 資訊，以簡化開發人員使用 ACS 2.0 時所需要做的一些組態工作，而且會寫到的程式碼幾乎很少，所有的驗證工作都被 WIF 做完了。
ACS 2.0 已於 MIX 2011 中宣布正式開放服務，因此對它有興趣且有 Windows Azure Platform 帳戶的使用者，可以直接到 Management Portal 中建立一個新的 ACS 2.0 命名空間，然後體驗它的驗證便利性吧！
NOTE
新版的 Windows Azure Platform Training Kit (April 2011) 中提供了
ACS 2.0 的 Lab 可實際體驗。