匯出 (0) 列印
全部展開

版本資訊

發佈時間: 2011年4月

更新日期: 2015年3月

適用於: Azure

本主題說明每個 Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS) 版本的新功能、解釋每個產品版本與其前身的差異,並強調任何可能影響針對舊版撰寫之程式碼的重大變更。

從 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 錯誤頁面。

新 ACS 命名空間和 Google 錯誤

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

新功能

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

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

使用 ACS 來達到使用 WS-同盟通訊協定向身分識別提供者進行單一登入 (SSO) 的 Web 應用程式,現在可利用單一登出功能。當使用者登出 Web 應用程式時,ACS 會自動讓使用者登出身分識別提供者,並從使用相同身分識別提供者的其他信賴憑證者應用程式中登出。

此功能專為 WS-同盟身分識別提供者啟用,包括 Active Directory Federation Services 2.0 和 Windows Live ID (Microsoft 帳戶)。為了啟用單一登出,ACS 會對 WS-同盟通訊協定端點執行下列工作:

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

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

如需詳細資訊,請參閱 程式碼範例:具有同盟登出功能的 ASP.NET MVC 4WIF 中 ASP.NET 的被動驗證 (英文)。

中斷 ACS 1.0 支援

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

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

新的 Azure 管理入口網站 (http://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 重新匯入資料] 核取方塊重新整理這些憑證。

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

同盟 Directory 租用戶與 存取控制命名空間的能力

Azure Active Directory 租用戶現在可作為 存取控制命名空間中的身分識別提供者。這適用於許多案例,例如,讓 Web 應用程式接受 Directory 租用戶的組織身分識別,以及接受社交提供者 (例如 Facebook、Google、Yahoo!、Microsoft 帳戶或任何其他 OpenID 提供者) 的消費者身分識別。您可以在這篇貼文將 Azure Active Directory 租用戶佈建為 ACS 命名空間中的身分識別提供者 (英文) 中找到如何實作案例的詳細指示。

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

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

已知問題

在 2012 年 12 月份的 Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS) 更新中,已發現下列已知問題:

Azure 共同管理員現在可以管理 存取控制命名空間。但需要採取行動,才能將預先存在的共同管理員傳播至預先存在的 存取控制命名空間。

在 2012 年 11 月份更新之前,我們解決了一個問題,也就是依據預設,只有主要 Azure 服務管理員可管理在訂閱中建立的 存取控制命名空間。如果 Azure 共同管理員嘗試存取 存取控制命名空間的 ACS 管理入口網站,他們將會收到下列其中一個 ACS 錯誤碼:

  • ACS50000:簽發權杖時發生錯誤。

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

  • ACS60001:在處理規則期間沒有產生輸出宣告。

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

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

  2. 使用如何加入及移除 Azure 訂用帳戶的共同管理員 (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx) 中的指導方針,移除和重新加入共同管理員。

  3. 使用共同管理員認證,登出再登入 Azure 入口網站。然後您便可管理 存取控制命名空間。

在 2012 年 9 月,Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS) 收到的更新包含下列變更:

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

存取控制命名空間 發佈的 WS-同盟中繼資料中的 "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 收到的更新包含下列新功能:

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

此更新在 ACS中引進 JSON Web Token (JWT) BETA 格式支援。JWT 是一種可使用 X.509 憑證或對稱金鑰簽署的輕量型、JSON 編碼的權杖格式,並可透過下列任何通訊協定,由 ACS 發行給信賴憑證者應用程式:

  • OAuth 2.0

  • WS-同盟

  • WS-Trust

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

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

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

在 2012 年 5 月上旬,ACS 收到的更新包含下列變更:

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

ACS 管理服務目前會為其支援的每一種實體類型公開 ID 屬性,如 ACS 管理服務 API 參照所述。這些 ID 屬性是由 ACS 自動設定與管理。

在此服務更新中,ACS 正移轉至不同的資料庫結構描述,因此所有實體類型都會變更經由管理服務所公開的這些 ID。

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

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

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

在 2012 年 1 月 25 日,ACS 2.0 收到的更新包含下列變更:

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

ACS 會在 SWT、SAML 和使用者名稱/密碼的情況下,針對失敗的驗證分別傳回錯誤碼 ACS50008、ACS50009 或 ACS50012。如需詳細資訊,請參閱下表:

 

驗證回應 之前

不存在的簽發者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml 或

ACS50012 AuthenticationFailed

不正確的認證

ACS50006 InvalidSignature

此外在前一版中,當用戶端驗證不存在的簽發者 (invalid_client) 或不正確的認證 (invalid_grant) 時,ACS 會回應不同的 OAuth 2.0 錯誤碼。此行為也已經更新,而且 ACS 將在 OAuth 2.0 要求格式不正確時傳回 invalid_request;如果用戶端驗證失敗,或為驗證提供的宣告格式不正確或無效時傳回 invalid_client;而在授權碼格式不正確或無效時傳回 invalid_grant。如需詳細資訊,請參閱下表:

 

驗證回應 範例 之前

不存在的簽發者

invalid_client

invalid_client

不正確的認證

SWT 使用了不正確的 key.Client id 進行簽署,而且認證不符合 ACS 中設定的認證。

invalid_grant

驗證失敗

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

invalid_grant

宣告格式不正確

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

invalid_request

授權碼格式不正確

invalid_grant

invalid_grant

授權碼無效

invalid_grant

OAuth2 要求格式不正確

invalid_request

invalid_request

ACS 2.0 的 2011 年 7 月份更新版本資訊包含下列項目:

所有 存取控制命名空間都會自動收到 2011 年 7 月份更新。此更新並未變更新客戶或現有客戶使用 ACS 的先決條件。如需現行 ACS 先決條件的詳細資訊,請參閱 ACS 必要條件

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

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

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

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

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

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

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

  • 語言選取器 - 在 ACS 管理入口網站中,顯示語言可透過入口網站右上角中出現的新增語言選取器功能表立即變更。

  • URL - 顯示於 ACS 管理入口網站中的語言,可在將ang?參數新增至要求 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 的初始版本中,US-ASCII 是為所有來自 OAuth 2.0 端點的 HTTP 回應所設定的字元編碼。在 2011 年 7 月份的更新中,所有 HTTP 回應的字元編碼現在皆設定為 UTF-8,以支援擴充的字元集。

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

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

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

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

在以下兩種支援的案例中,可以存在 ACS 中沒有相關聯身分識別提供者的簽發者:

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

  • 為了透過 OAuth WRAP 通訊協定在權杖要求中判斷宣告而建立簽發者時,同時使用一致具名的服務身分識別來驗證 ACS。

由此版本開始,ACS 對於能夠為給定的 存取控制命名空間 建立的身分識別提供者、信賴憑證者應用程式、規則群組、規則、服務身分識別、宣告類型、委派記錄、簽發者、金鑰與位址等,都不再有數量上的限制。

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

社群新增項目

新增
顯示:
© 2015 Microsoft