本頁是否能提供幫助?
您對此內容的意見反應十分重要。 請告訴我們您的想法。
其他意見反應?
剩餘 1500 個字元
匯出 (0) 列印
全部展開

利用存取控制服務進行服務匯流排驗證與授權

Windows Azure 服務匯流排 支援使用 Windows Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS) 來進行 服務匯流排 操作的授權。

Windows Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS)

ACS 能促進驗證,意指它可建立呼叫者的身分識別。ACS 有兩種方法可建立呼叫者身分識別。它可使用傳統使用者名稱和密碼配置,根據服務身分識別 (或帳戶) 的命名空間範圍清單建立身分識別,或將建立身分識別的工作委派給外部身分識別提供者,例如 Active Directory Federation Services (ADFS)、Windows Live ID、Facebook、Google ID、Yahoo ID 或 OpenID。

建立身分識別後,ACS 就會具有 (或收到) 數個有關身分識別的「宣告」。這些宣告會產生有關人員 (或非人員帳戶) 的聲明,而這些聲明是由簽發宣告的身分識別提供者進行數位簽署,以向 ACS 保證這些宣告正確無誤或至少符合簽發者的管理規則。換言之,一組用於聲明代表性身分識別為「Microsoft Corporation 主席 Bill Gates」的宣告,由 Microsoft ADFS 閘道簽發時最值得信賴,而由第三方簽發時則比較不可信賴。一貫可供所有身分識別提供者使用而且也適用於 ACS 內建服務身分識別的宣告,包含提供者宣告 (識別提供者本身) 和 ‘nameidentifier’ 宣告,後者是指定之身分識別的提供者特定與獨有識別碼。

再者,ACS 可讓身分識別提供者所簽發的宣告對應至「信賴憑證者」所理解的宣告,進而促成授權。服務匯流排 是非常值得信賴的憑證者,表示其會依賴 ACS 來處理驗證和授權。宣告對應有兩個作用:第一個作用,它可讓來自各種不同宣告「術語」的宣告正規化,而成為服務所理解的一組宣告。第二個作用,此對應可以作為授權規則集。如果指定的身分識別並未對應至服務所理解的一組宣告,則身分識別便無法存取此服務。

驗證與授權一律透過用戶端傳送,而用戶端是唯一必須讓所有憑證者可在網路上看見的元件。舉例來說,公司防火牆外未公開的 ADFS 服務和 ACS 有可能一起使用,因為 ACS 和 ADFS 從未彼此直接交談。當用戶端想對受保護的資源執行作業 (例如將訊息傳送至 服務匯流排 佇列) 時,必須證實它已獲得授權這麼做。從 ACS 取得「權杖」即可獲得證實。權杖只是一組宣告的容器,並由簽發者進行數位簽署。如果已將 ACS 設定為使用外部身分識別提供者 (如 ADFS) 建立身分識別,則至少採用兩個權杖。第一個權杖是向身分識別提供者 (如 ADFS) 取得,可提供其中一種使用者的身分識別證明作為輸入。該權杖會接著傳給 ACS,以便進行評估、執行規則,以及對信賴憑證者發出權杖。

服務匯流排 與ACS

服務匯流排 與 ACS 具有特別關係,其中每個 服務匯流排 服務命名空間會與同名且尾碼為 “–sb” 的相符 ACS 服務命名空間配對。此種特別關係的原因在於 服務匯流排 和 ACS 管理其相互信任關係和關聯加密編譯密碼的方法。

服務匯流排 可與 ACS V1 以及 ACS V2 結盟。在 2011 年 9 月發行的 服務匯流排 之前建立的所有服務命名空間都會與 ACS V1 結盟,而在服務升級之後建立的所有服務命名空間則會與 ACS V2 結盟。本主題只涵蓋 ACS V2,這是目前的 ACS 服務版本。

在 “-sb” 內,ACS 服務命名空間 (選取 服務匯流排 服務命名空間,然後按一下功能區上的 ACS 圖示,可以從 Windows Azure 入口網站進行瀏覽) 是在「信賴憑證者應用程式」瀏覽之後的 “ServiceBus” 信賴憑證者定義。信賴憑證者定義具有對應至相符 服務匯流排 服務命名空間根目錄的「領域」值 (使用 ‘http’ 配置),並將權杖類型設定為 ‘SWT’,將權杖的到期時間設定為 1200 秒。此外,您無法透過入口網站或 API 管理或存取簽署金鑰。

與 “ServiceBus” 信賴憑證者定義關聯的是「服務匯流排 的預設規則群組」,含有可讓服務命名空間的「擁有者」作為服務命名空間之超級使用者的基本對應。此規則群組預設包含三個簡易規則,這三個規則可將「擁有者」服務身分識別的輸入 ‘nameidentifier’ 宣告對應至 服務匯流排 所理解的三個權限宣告:‘Send’ 適用於所有傳送作業、‘Listen’ 可開啟接聽程式或接收訊息,而 ‘Manage’ 可觀察或管理 服務匯流排 租用戶的狀態。服務匯流排 會忽略簽發權杖中包含的所有其他宣告。「擁有者」服務身分識別是 ACS 服務命名空間中的一般服務身分識別。建議您,您可以建立更多服務身分識別。事實上,使用「擁有者」身分識別應受限於執行系統管理工作。

信賴憑證者定義和範圍

當用戶端要求授權權杖,以便將訊息傳送至位於諸如 https://tenant.servicebus.windows.net/my/test 等位置的佇列時,此權杖要求會包含正規形式的目標位址以作為預計的目標領域。此「正規化」只是將一般 URI 配置使用於所有通訊協定。因此,一律透過使用 ‘http’ 配置 http://tenant.servicebus.windows.net/foo/bar 的領域 URI 來要求權杖,以便與位於 https://tenant.servicebus.windows.net/my/test 或 sb://tenant.servicebus.windows.net/my/test 的 服務匯流排 實體互動。所以,所有信賴憑證者定義也都必須將「正規化」URI 配置 ‘http’ 使用於領域 URI。

當要求抵達 ACS 時,ACS 會利用 ‘longest prefix match’ 比對領域 URI 與信賴憑證者定義,這表示已選取並執行信賴憑證者 (其「領域 URI」位址是要求權杖之位址的最長可用首碼)、信賴憑證者定義以及其關聯的規則定義。預設 ‘ServiceBus’ 信賴憑證者定義的範圍限定於整個對應 服務匯流排 服務命名空間,這表示其領域 URI (對應至 服務匯流排 服務命名空間根位址) 是 服務匯流排 服務命名空間上所有可能位址的首碼。因此,在此信賴憑證者定義上啟用的規則定義可授與整個 服務匯流排 服務命名空間的完整存取權。

針對位於諸如 https://tenant.servicebus.windows.net/my/test 等處的佇列建立一組限定範圍之授權規則的方法,就是透過 ACS 入口網站或 ACS 管理 API,建立新的信賴憑證者定義,並提供佇列位址或該位址的首碼作為新定義的領域 URI。在入口網站上,步驟如下:

  • 在 [信賴憑證者應用程式] 之下,按一下 [新增]。

  • 輸入部分顯示名稱,例如 MyTest

  • 輸入 http://tenant.servicebus.windows.net/MyTest 作為範圍的領域 URI。

  • 選擇 [SWT] 作為權杖格式。

  • 將 [加密原則] 設定為 [無]。

  • 將 [權杖存留期] 設定為 1200 秒。

  • 按一下 [儲存]

結果是此位址獨有的信賴憑證者定義。因為其領域 URI 是內建 ‘ServiceBus’ 信賴憑證者定義的尾碼,所以定義會自動繼承正確的簽署金鑰,而 服務匯流排 即可根據新的定義來信任簽發的權杖。不過,由於新的信賴憑證者定義到目前為止都沒有關聯的規則,所以沒有人能夠存取佇列,甚至「擁有者」也無法存取,因為即使信賴憑證者定義構成階層,其間的規則並未自動隱含繼承。

建立新定義之後,ACS 入口網站的 [規則群組] 區段中會有「<displayname> 的預設規則群組」。這個新群組預設是空的。若要允許存取佇列,則必須將規則新增至下一節說明的群組。此外,可以針對信賴憑證者定義啟用含有規則的現存規則群組。每一個規則群組均可視為可在信賴憑證者階層中任意處啟用的個別存取控制清單。若要啟用檔案系統之類的繼承 (例如,繼承 服務匯流排 服務命名空間根目錄的預設規則),只要在信賴憑證者定義上啟用對應的「ServiceBus 的預設規則群組」和任何其他規則群組 – 這需要勾選入口網站上信賴憑證者定義的 [規則群組] 區段中的正確方塊。在必須將一組通用存取規則套用於許多資源的情況下 (例如:一組平行資源 (如位於 http://tenant.servicebus.windows.net/my/test 和 http://tenant.servicebus.windows.net/my/zoo 的同層級佇列) 的通用規則,也可將信賴憑證者定義的範圍限定為共用服務命名空間分支,例如 http://tenant.servicebus.windows.net/my。

在其他情況下,案例可能會要求針對相同 服務匯流排 實體的各層面 (例如某主題之不同訂閱的不同權限),以不同方式管理存取控制。在這些情況下,有可能建立範圍限定於特定訂閱名稱 (例如 http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/) 的信賴憑證者定義,並且讓該定義保留僅套用至特定具名訂閱的規則。

定義規則

規則是定義於規則群組中,而且通常可將輸入宣告對應至輸出宣告。群組中的所有規則都可產生單一組合的結果,所以如果可產生三個不同輸出宣告之指定的輸入宣告集有三個相符規則,則簽發的授權權杖會包含全部三個宣告。對於 服務匯流排 而言,三個權限宣告如下:‘Send’ 適用於所有傳送作業、‘Listen’ 可開啟接聽程式或接收訊息,而 ‘Manage’ 可觀察或管理 服務匯流排 租用戶的狀態。精確來說,‘Send’、‘Listen’ 和 ‘Manage’ 是宣告類型 ‘net.windows.servicebus.action’ 的允許值。為 服務匯流排 建立規則時,必須將輸入宣告 (例如服務身分識別的 nameidentifier) 對應至所要的權限宣告。若要將在佇列上 ‘Send’ 的權限授與給服務身分識別 “contoso”,則規則定義會將簽發者的 nameidentifier 宣告 (值為 “contoso”) 對應至類型 ‘net.windows.servicebus.action’ (值為 ‘Send’) 的自訂輸出宣告。需要有三個不同規則,才能將三個權限宣告全部授與給服務身分識別。僅有三個權限宣告的目的在於限制定義規則時的複雜性。

使用權杖提供者

權杖提供者是 服務匯流排 的 .NET Managed API 中的泛型建構,能夠將認證的部分形式轉變成 ACS 服務所簽發的授權權杖,然後再傳遞至 服務匯流排 以執行所需的作業。TokenProvider 是一個抽象基底類別,含有三個在大多數基本案例中可透過 Factory 方法存取的具體實作:

  • 共用密碼 – 能夠根據在 ACS 的 服務匯流排 服務命名空間 “-sb” 協同命名空間中定義的服務身分識別 (以及與該身分識別關聯的共用金鑰) 來取得權杖。建立服務命名空間時所建立之預先佈建的服務身分識別稱為「擁有者」,您可透過管理入口網站取得其共用密碼。

  • 簡易 Web 權杖 (SWT) – 能夠根據先前取得的 SWT 權杖 (透過權杖提供者傳遞至 ACS) 來取得權杖。使用 WS-Trust/WS-Federation RST/RSTR 要求,即可將此權杖當做二進位權杖傳遞至 ACS。請參閱 ACS 文件,以取得如何設定 WS 同盟提供者的相關資訊。

  • SAML – 能夠根據先前取得的 SAML 權杖 (透過權杖提供者傳遞至 ACS) 來取得權杖。使用 WS-Trust/WS-Federation RST/RSTR 要求,即可將此權杖傳遞至 ACS。請參閱 ACS 文件,以取得如何設定 WS 同盟提供者的相關資訊。

服務匯流排 MessagingFactoryNamespaceManagerTransportClientEndpointBehavior API 可接受 TokenProvider 執行個體。需要權杖時便會呼叫權杖提供者,其中包含下列情況:長期連線的現有權杖超過其有效期 (預設值為 1200 秒) 而必須取得新權杖時。需要使用者互動的同盟案例,的確需要實作自訂權杖提供者。

舉例來說,能夠讓特定 Facebook 使用者將訊息傳送至特定佇列的自訂權杖提供者,必須透過 ACS 對使用者呈現適當的 Facebook UI 以建立 Facebook 身分識別、透過 ACS 重新導向以將 Facebook 權杖換成 服務匯流排 的 ACS 權杖,然後在要求重新導向至本機應用程式時擷取 ACS 權杖。服務匯流排 Codeplex 網站會包含愈來愈多可供自訂的權杖提供者範例。

社群新增項目

顯示:
© 2015 Microsoft