共用方式為

版本資訊

  • 發行項

更新日期：2015 年 6 月 19 日

適用對象：Azure

本主題描述Microsoft Azure Active Directory 存取控制 (每個版本的新功能，也稱為 存取控制 Service 或 ACS) 、說明產品每個版本與其前置版本有何不同，並強調可能會影響針對舊版撰寫之程式碼的任何重大變更。

  • 2015 年 3 月 – 將 ACS 命名空間移轉至 Google OpenID Connect

  • 2014 年 6 月 – Google 身分識別提供者支援

  • 2013 年 7 月份更新版本資訊

  • 2012 年 12 月份更新版本資訊

  • 2012 年 9 月份更新版本資訊

  • 2012 年 6 月份更新版本資訊

  • 2012 年 5 月份更新版本資訊

  • 2012 年 1 月份更新版本資訊

  • 2011 年 7 月更新版本資訊

2015 年 3 月 – 將 ACS 命名空間移轉至 Google OpenID Connect

ACS 已實作一項功能，可協助 ACS 命名空間擁有者將其 Google 身分識別提供者組態從 OpenID 2.0 移轉至 OpenID Connect。 客戶必須在 2015 年 6 月 1 日前，將其 ACS 命名空間移轉至 OpenID Connect，並在 2017 年 1 月 1 日前移轉其後端程式碼，以使用 OpenID Connect 識別碼。 若未在前述期限之前執行適當的動作，將會導致您的應用程式中斷。 如需詳細指引，請參閱將 ACS 命名空間移轉至 Google OpenID 連線。

2014 年 6 月 – Google 身分識別提供者支援

從 2014 年 5 月 19 日起，新的 ACS 命名空間無法使用 Google 作為身分識別提供者。 使用 Google 且在 2014 年 5 月 19 日前註冊的 ACS 命名空間不受影響。 這項新限制之所以存在的原因是 Google 正在分階段停止支援 ACS 所依賴的 OpenID 2.0，並已關閉新應用程式的註冊。 使用 Google 的現有 ACS 命名空間將繼續運作，直到 2015 年 4 月 20 日為止。 如果您的應用程式需要 Google 帳戶的支援，建議您直接向它們註冊您的應用程式。

如果使用者嘗試使用其 Google 帳戶登入新的 ACS 命名空間，系統會將他們重新導向到 HTTP 400 錯誤頁面。

New ACS namespace and Google error

2013 年 7 月份更新版本資訊

為了增加所有使用者之 ACS 的可用性和效能，ACS 已針對每個命名空間實作每秒 30 個權杖要求的限制。 如果命名空間已超出此限制一段延長的期間，ACS 會在間隔的持續時間內拒絕命名空間的權杖要求，並傳回 HTTP 429 / ACS90055「要求太多」錯誤。 如需詳細資訊，請參閱 ACS 服務限制 和 ACS 錯誤碼。

2012 年 12 月份更新版本資訊

新功能

ACS 的 2012 年 12 月更新包含下列新功能：

支援使用 WS-同盟通訊協定的同盟單一登出

使用 ACS 來啟用單一登入的 Web 應用程式， (SSO) 搭配使用WS-Federation通訊協定的識別提供者，現在可以利用單一登出功能。 當使用者登出 Web 應用程式時，ACS 可以自動將使用者登出識別提供者，以及從使用相同識別提供者的其他信賴憑證者應用程式登出。

此功能適用于WS-Federation識別提供者，包括 Active Directory 同盟服務 2.0 和 Windows Live ID (Microsoft 帳戶) 。 若要啟用單一登出，ACS 會針對WS-Federation通訊協定端點執行下列工作：

  • ACS 會辨識來自識別提供者 的 wsignoutcleanup1.0 訊息，並藉由將 wsignoutcleanup1.0 訊息傳送至信賴憑證者應用程式來回應。

  • ACS 會辨識來自信賴憑證者應用程式的 wsignout1.0 和 wreply 訊息，並藉由將 wsignout1.0 訊息傳送至識別提供者和 wsignoutcleanup1.0 訊息來回應信賴憑證者應用程式。

如需詳細資訊，請參閱程式碼範例：ASP.NET MVC 4 與WIF 中 ASP.NET同盟登出和被動驗證。

中斷 ACS 1.0 支援

本版本已中斷支援存取控制服務 1.0，包括從存取控制服務 1.0 至存取控制服務 2.0 的移轉支援。

在新的 Azure 管理入口網站中流覽至存取控制命名空間

新的Azure 管理入口網站 (https://manage.WindowsAzure.com) 包含您建立和管理存取控制命名空間的熟悉 ACS 管理入口網站路由。

若要瀏覽至 ACS 管理入口網站：

  1. 移至Microsoft Azure管理入口網站 (https://manage.WindowsAzure.com) 登入，然後按一下 [Active Directory]。 (疑難排解提示： 「Active Directory」專案遺失或無法使用)

  2. 按一下存取控制命名空間，然後按一下 [管理]。

若要建立存取控制命名空間，請依序按一下 [新增]、[應用程式服務]、[存取控制] 和 [快速建立]。 (或是先按一下 [新增] 再按一下 [存取控制命名空間])。

如需 Microsoft Azure 管理入口網站中 ACS 管理工作的說明，請按一下 [Active Directory]，然後按一下 [說明 (?)]。 (或按一下 Active Directory、按一下 [存取控制命名空間]，然後按一下 [說明])。

流覽至服務匯流排的存取控制命名空間

當您在 中建立服務匯流排命名空間時，入口網站會自動為服務匯流排建立存取控制命名空間。

若要設定和管理服務匯流排的存取控制命名空間：

  1. 登入 [Azure 管理入口網站]。

  2. 按一下 [服務匯流排]，然後選取服務匯流排。

  3. 按一下 [便捷鍵]，然後按一下 [開啟 ACS 管理入口網站]。

若要確認存取控制命名空間與服務匯流排相關聯，請參閱存取控制服務頁面頂端的 [服務命名空間] 欄位。 命名空間名稱由包含 "-sb" 尾碼的服務匯流排名稱所組成。

如需詳細資訊，請參閱如何：管理服務匯流排存取控制命名空間。

適用於檢視 WS-同盟身分識別提供者金鑰、隱藏密碼的 ACS 管理入口網站增強功能

這個版本包含一對在 ACS 2.0 管理入口網站中檢視和使用憑證、金鑰和密碼相關的增強功能：

  • 現在可在 [編輯 WS-同盟身分識別提供者] 區段中看到簽署憑證 – 先前，在 ACS 管理入口網站中看不見從 WS-同盟中繼資料匯入且用來驗證該身分識別提供者簽發之權杖簽章的憑證。 [編輯 WS-同盟身分識別提供者] 區段現在可顯示已匯入憑證的相關資訊，包括其到期日和狀態。 現在可使用新的 [儲存時從 WS-同盟中繼資料 URL 重新匯入資料] 核取方塊重新整理這些憑證。

  • 目前預設會隱藏密碼和對稱簽署金鑰 – 為防止意外洩露密碼和對稱金鑰，入口網站中所有的 [編輯] 畫面目前均預設隱藏這些值。 若要刻意顯示密碼或對稱金鑰的值 (例如，以便複製到應用程式)，現在必須按下 [顯示密碼] 或 [顯示金鑰] 按鈕。

能夠將目錄租使用者與存取控制命名空間同盟

Azure Active Directory租使用者現在可作為存取控制命名空間中的識別提供者。 這可讓許多案例，例如讓您的 Web 應用程式接受來自目錄租使用者的組織身分識別，以及來自 Facebook、Google、Yahoo！、Microsoft 帳戶或任何其他 OpenID 提供者的社交提供者的取用者身分識別。 您可以在本文中找到有關如何實作案例的詳細指示：在ACS 命名空間中將Azure Active Directory租使用者布建為識別提供者。

信賴憑證者應用程式的 SAML 2.0 通訊協定支援 (開發人員預覽版本)

ACS 現在支援 SAML 2.0 通訊協定，可將權杖發行至信賴憑證者應用程式。 已發行 SAML 2.0 通訊協定支援作為開發人員預覽版本，這表示 SAML 2.0 通訊協定實作的詳細資料仍可能變更。 如需詳細資訊，請參閱開發人員預覽：SAMLProtocol。

已知問題

在 2012 年 12 月，Microsoft Azure Active Directory 存取控制 (也稱為 存取控制 Service 或 ACS) 更新，已識別下列已知問題：

Azure Co-Administrators現在可以管理存取控制命名空間。 不過，需要採取動作，才能將既有的共同管理員傳播至預先存在的存取控制命名空間。

在 2012 年 11 月更新之前，我們已解決此問題：根據預設，只有主要 Azure 服務管理員可以管理在訂用帳戶中建立的存取控制命名空間。 如果 Azure 共同管理員嘗試存取存取控制命名空間的 ACS 管理入口網站，他們會收到下列其中一個 ACS 錯誤碼：

  • ACS50000：發出權杖時發生錯誤。

  • ACS60000：使用簽發者 'uri：WindowsLiveID' 處理信賴憑證者的規則時發生錯誤

  • ACS60001：在規則處理期間不會產生任何輸出宣告。

針對任何 Azure 服務管理員或共同管理員所建立的新存取控制命名空間，現在已解決此問題。 不過，若客戶擁有修正前存在的命名空間，則需要執行下列因應措施才能將共同管理員資料傳播到命名空間：

  1. 使用服務管理員或帳戶管理員認證登入Azure 入口網站 (https://windows.azure.com/) 。

  2. 使用 如何為 Azure 訂用帳戶新增和移除Co-Administrators 中的指引，移除並重新新增共同管理員 (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

  3. 使用共同管理員認證，登出再登入 Azure 入口網站。 接著，您將能夠管理存取控制命名空間。

2012 年 9 月份更新版本資訊

在 2012 年 9 月，Microsoft Azure Active Directory 存取控制 (也稱為 存取控制 Service 或 ACS) 收到包含下列變更的更新：

ACS 產生的 WS-同盟中繼資料中發佈的 entityID 現在一致維持小寫

存取控制命名空間所發行WS-Federation中繼資料中的 「entityID」 屬性現在一律為小寫。 在舊版本中，它會使用在 Azure 入口網站中建立命名空間時所輸入的字母大小寫。 「entityID」 屬性會識別信賴憑證者應用程式的存取控制命名空間，以下是 屬性的範例：

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

需要這項變更，才能解決 ACS 核發令牌中存取控制命名空間的字母大小寫 (一律為小寫) 不符合信賴憑證者所匯入之存取控制命名空間的字母大小寫問題。 使用 Windows Identity Foundation 的信賴憑證者不受區分大小寫問題影響。

上傳至 ACS 的 X.509 憑證現在有 4096 位元的公開金鑰大小限制

透過 ACS 管理入口網站或管理服務上傳至存取控制命名空間的所有 X.509 憑證現在都必須有公開金鑰大小，其大小不超過 4096 位。 這包括使用於權杖簽署、權杖加密和權杖解密的憑證。

在 Windows 中可檢查憑證的公開金鑰大小，方法是開啟憑證 (.CER) 檔案，選取 [詳細資料] 索引標籤，然後檢查 [公開金鑰] 欄位的值。 使用安全 sha256RSA 簽章演算法的憑證將具有 2048 位元公開金鑰。

金鑰大小大於 4096 位元的任何現有憑證都會繼續使用 ACS，但除非以相容憑證取代這些憑證，否則無法在 ACS 中重新儲存它們。

些微變更 ACS 使用 X.509 憑證簽署權杖時所使用的「主要金鑰」選取演算法

在 ACS 管理入口網站和管理服務中，權杖簽署憑證有一個「設為主要」欄位，選取該欄位會導致 ACS 使用該憑證來簽署權杖。 在此版本中，如果沒有設定的權杖簽署憑證已核取 [進行主要] 欄位，存取控制命名空間將會使用具有最早有效開始日期的現有非主要權杖簽署憑證來簽署權杖。 如果存在無效或已到期的主要憑證，ACS 仍然不會使用非主要權杖簽署憑證來簽署權杖。

JWT Beta：使用全域命名空間憑證或金鑰簽署 JWT 權杖時變更簽署行為

在 2012 年 6 月發行 JSON Web Token (JWT) 格式的 Beta 版支援時，ACS 使用下列優先順序來決定應使用哪個金鑰來簽署發行給各信賴憑證者應用程式的每個 JWT 權杖：

  • 指派給信賴憑證者的對稱簽署金鑰 (若有的話)

  • 指派給信賴憑證者的 X.509 簽署憑證 (若有的話)

  • 指派給存取控制命名空間的對稱簽署金鑰

  • 指派給存取控制命名空間的 X.509 簽署憑證

從這一版開始，不再支援整個命名空間對稱金鑰來簽署 JWT 權杖。 以下是簽署 JWT 權杖的新優先順序：

  • 指派給信賴憑證者的對稱簽署金鑰 (若有的話)

  • 指派給信賴憑證者的 X.509 簽署憑證 (若有的話)

  • 指派給存取控制命名空間的 X.509 簽署憑證

2012 年 6 月份更新版本資訊

ACS 在 2012 年 6 月收到包含下列新功能的更新：

JWT 格式現在適用於信賴憑證者應用程式 (Beta 版)

此更新引進了 ACS 中 JSON Web 權杖 (JWT) BETA 格式的支援。 JWT 是輕量型、JSON 編碼的權杖格式，可使用 X.509 憑證或對稱金鑰簽署，而且 ACS 可以透過下列任何通訊協定向信賴憑證者應用程式發出：

  • OAuth 2.0

  • WS-同盟

  • WS-Trust

JWT 權杖格式現在是 ACS 管理入口網站 [信賴憑證者應用程式] 區段中的可選取選項，也可以透過 ACS 管理服務進行設定。

若要深入瞭解 JWT 權杖格式，請參閱 JSON Web 權杖規格。 未來將提供配備 JWT 權杖功能的 ACS 程式碼範例。

重要

JWT 支援在 ACS 中標示為「Beta」，這表示 JWT 實作的所有詳細資料都可能會變更。 我們鼓勵開發人員體驗此權杖格式。 但是 JWT 不得使用於生產服務中，因為行為可能會改變，而不另行通知。

2012 年 5 月份更新版本資訊

ACS 在 2012 年 5 月初期收到包含下列變更的更新：

透過管理服務公開的實體 ID 屬性變更

ACS 管理服務目前會針對它支援的每個實體類型公開識別碼屬性，如 ACS 管理服務 API 參考中所述。 這些識別碼屬性會自動由 ACS 設定及管理。

在此服務更新中，ACS 會移轉至不同的資料庫架構，因此，透過管理服務公開的識別碼將會變更所有實體類型。

這並不尋常，而且通常不建議應用程式儲存或取得這些硬式編碼相依性的 ID，以便透過管理服務查詢特定實體。 反之，建議使用 Name 屬性查詢 RelyingParty、ServiceIdentity、RuleGroup 和 Issuer 實體類型，並使用上層實體 ID 查詢其他實體類型 (例如，規則案例中的 RuleGroupId，或身分識別提供者案例中的 IssuerId)。

用於規則處理的資料庫定序變更

為了擴充國際語言的支援並改善安全性，此版本的 ACS 會更新用來比較SQL_Latin1_General_CP1_CI_AS輸入宣告與Latin1_General_100_BIN2的基礎SQL資料庫定序。 這項變更可讓 ACS 支援其他字元集和字元集的組合。 SQL_Latin1_General_CP1_CI_AS 不支援依賴輸入宣告 (包含具有多個字元集的字串) 的應用程式，可能因此新定序而看見不同或其他宣告。 建議要利用此新功能的客戶驗證其應用程式是否與新的 SQL 定序相容。

2012 年 1 月份更新版本資訊

ACS 2012 年 1 月 25 日收到包含下列變更的更新：

  • 適用於驗證要求失敗的 ACS 錯誤回應變更

  • 適用於驗證要求失敗的 OAuth 2.0 錯誤碼變更

適用於驗證要求失敗的 ACS 錯誤回應變更

在舊版中，當用戶端以不存在的簽發者進行驗證時，ACS 會以不同的錯誤碼回應 (錯誤碼：ACS50026) 或不正確的認證 (錯誤碼：ACS50006) 。 先前之所以會產生這些錯誤碼，是因為用戶端嘗試使用無效的服務身分識別名稱進行驗證，或使用無效的身分識別提供者所簽發的 SWT 或 SAML 權杖進行驗證。

ACS 會在 SWT、SAML 和使用者名稱/密碼的案例中，傳回 ACS50008、ACS50009 或 ACS50012 的錯誤碼。 如需詳細資訊，請參閱下表：

驗證回應 之前 After

不存在的簽發者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml、 OR

ACS50012 AuthenticationFailed

不正確的認證

ACS50006 InvalidSignature

適用於驗證要求失敗的 OAuth 2.0 錯誤碼變更

此外，在舊版中，當用戶端向不存在的簽發者進行驗證時，ACS 會以不同的 OAuth 2.0 錯誤碼回應， (invalid_client) 或不正確的認證 (invalid_grant) 。 此行為也已更新，而且 ACS 會在 OAuth 2.0 要求格式不正確時傳回invalid_request，invalid_client 如果用戶端驗證失敗或針對驗證提供的判斷提示格式不正確或無效，則invalid_grant如果授權碼格式不正確或無效。 如需詳細資訊，請參閱下表：

驗證回應 範例 之前 After

不存在的簽發者

invalid_client

invalid_client

不正確的認證

SWT 使用不正確的金鑰簽署。用戶端識別碼和認證確實符合 ACS 中設定的認證。

invalid_grant

驗證失敗

Audience URI 驗證失敗。憑證驗證失敗。來自服務身分識別的宣告包含自我發行的宣告。

invalid_grant

宣告格式不正確

SWT 缺少簽章。SAML 宣告不是有效的 XML。

invalid_request

授權碼格式不正確

invalid_grant

invalid_grant

授權碼無效

invalid_grant

OAuth2 要求格式不正確

invalid_request

invalid_request

2011 年 7 月更新版本資訊

ACS 2.0 2011 年 7 月更新的版本資訊包含下列專案：

  • 必要條件

  • 新功能

  • 變更

  • 已知問題

  • 已知問題

必要條件

所有存取控制命名空間都會自動收到 2011 年 7 月更新。 此更新不會變更新客戶或現有客戶的 ACS 必要條件。 如需目前 ACS 必要條件的詳細資訊，請參閱 ACS 必要條件。

新功能

ACS 的 2011 年 7 月更新包含下列新功能：

1. 規則現在最多可支援兩個輸入宣告

ACS 規則引擎現在支援新的規則類型，允許設定最多兩個輸入宣告，而不是只設定一個輸入宣告。 具有兩個輸入宣告的規則，可用來減少執行複雜使用者授權功能時所需的整體規則數量。

在 ACS 管理入口網站中，按一下規則編輯器中的 [ 新增第二個輸入宣告 ]，即可在新規則中指定第二個輸入宣告。 在管理服務中，則可使用 ConditionalRule 實體類型設定具有兩個輸入宣告的規則。 具有一個輸入宣告的規則仍是透過 Rule 實體類型設定的，以符合回溯相容性。

如需具有兩個輸入宣告之規則的詳細資訊，請參閱 規則群組和規則。

2. 11 種語言的當地語系化

ACS 管理入口網站和信賴憑證者應用程式的 ACS 裝載登入頁面現在支援十一種語言的當地語系化，包括英文、法文、德文、義大利文、日文、韓文、俄文、西班牙文、葡萄牙文 (巴西) 、簡體中文和繁體中文。 另外也提供 [英文 (國際)] 選項，使用替代的日期格式來設定及顯示金鑰的有效日期/到期日。 顯示於這些使用者介面的書寫語言可透過下列三種方式之一進行變更：

  • 語言選取器 – 在 ACS 管理入口網站中，可以使用出現在入口網站右上角的新語言選取器功能表，立即變更顯示的語言。

  • URL – ACS 管理入口網站中顯示的語言可以藉由將 「lang」 參數新增至要求 URL 的結尾來變更。 此參數的合法值為對應於支援語言的 ISO 639-1/3166 語言代碼。 舉例來說，合法值包括 en、de、es、fr、it、ja、ko、ru、pt-br、zh-cn 與 zh-tw。 以下是 ACS 管理入口網站 URL 的範例，其參數會將顯示的語言設定為法文：

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • 網頁瀏覽器喜好 設定 – 如果 「lang」 URL 參數或語言選取器從未用來設定語言喜好設定，則 ACS 管理入口網站和 ACS 裝載的登入頁面將會根據網頁瀏覽器設定中設定的語言喜好設定來決定要顯示的預設語言。

變更

以下是此版本中值得注意的服務行為變更：

1. 現在，所有 OAuth 2.0 回應的編碼皆為 UTF-8

在 ACS 的初始版本中，OAuth 2.0 端點的所有 HTTP 回應的字元編碼設定為 US-ASCII。 在 2011 年 7 月份的更新中，所有 HTTP 回應的字元編碼現在皆設定為 UTF-8，以支援擴充的字元集。

已知問題

以下是此版本的已知問題：

規則編輯器無法顯示與身分識別提供者無關的自訂簽發者

目前，ACS 管理入口網站中的規則編輯器只能顯示與識別提供者或 ACS 相關聯的宣告簽發者。 如果載入的規則參照的簽發者並未對應任一情況，將顯示下列錯誤：

  • ACS80001：此規則已設定為使用管理入口網站不支援的宣告簽發者類型。 請使用管理服務來檢視並編輯此規則。

有兩個支援的案例可讓簽發者在沒有 ACS 中的相關聯識別提供者的情況下存在：

  • 在 OAuth 2.0 委派案例中，簽發者記錄是使用 ACS 管理服務在存取控制命名空間中建立，而且此簽發者沒有相關聯的識別提供者。

  • 建立簽發者是為了透過 OAuth WRAP 通訊協定在權杖要求中判斷提示宣告，同時使用相同命名的服務識別向 ACS 進行驗證。

配額

在此版本中，ACS 不會限制識別提供者數目、信賴憑證者應用程式、規則群組、規則、服務識別、宣告類型、委派記錄、簽發者、金鑰，以及可為指定存取控制命名空間建立的位址。

服務限制

如需服務限制的詳細資訊，請參閱 ACS 服務限制。