Azure Stack Hub 的識別提供者概觀

Azure Stack Hub 需要Microsoft Entra識別碼或Active Directory 同盟服務 (AD FS) ，由 Active Directory 作為識別提供者支援。 提供者的選擇是您第一次部署 Azure Stack Hub 時所做的一次性決定。 本文中的概念和授權詳細資料可協助您選擇適當的識別提供者。

您選擇的Microsoft Entra識別碼或 AD FS 取決於您部署 Azure Stack Hub 的模式：

• 當您以連線模式部署它時，可以使用Microsoft Entra識別碼或 AD FS。
• 當您在沒有網際網路連線的中斷連線模式下部署時，僅支援 AD FS。

如需您所擁有選項 (取決於您的 Azure Stack Hub 環境) 的詳細資訊，請參閱下列文章：

• Azure Stack Hub 開發工具組： 身分識別考慮。
• Azure Stack Hub 整合式系統：適用於 Azure Stack Hub 整合式系統的部署規劃決策。

重要

Azure AD Graph 即將淘汰，將于 2023 年 6 月 30 日淘汰。 如需詳細資訊，請參閱本節。

識別提供者的一般概念

後面幾節討論有關識別提供者的一般概念及其在 Azure Stack Hub 中的使用方式。

目錄租用戶和組織

目錄是保留「使用者」、「應用程式」、「群組」和「服務主體」相關資訊的容器。

目錄租用戶是一個「組織」，例如 Microsoft 或您自己的公司。

• Microsoft Entra識別碼支援多個租使用者，而且可以支援多個組織，每個組織都有自己的目錄中。 如果您使用Microsoft Entra識別碼並擁有多個租使用者，您可以將應用程式與使用者從一個租使用者存取權授與該相同目錄的其他租使用者。
• AD FS 僅支援單一租用戶，因此僅支援單一組織。

使用者和群組

使用者帳戶 (身分識別) 是標準帳戶，可使用使用者識別碼和密碼驗證個人。 群組可以包含使用者或其他群組。

您建立及管理使用者和群組的方式取決於使用的身分識別解決方案。

在 Azure Stack Hub 中，使用者帳戶：

• 以「使用者名稱@網域」格式建立。 雖然 AD FS 可將使用者帳戶對應到 Active Directory 執行個體，但 AD FS 不支援使用「\<網域>\<別名>」格式。
• 可以設定為使用多重要素驗證。
• 受限於它們首先註冊的目錄，也就是其組織目錄。
• 可以從內部部署目錄匯入。 如需詳細資訊，請參閱整合內部部署目錄與Microsoft Entra識別碼。

當您登入組織的使用者入口網站時，您會使用 https://portal.local.azurestack.external URL。 從不同於用來註冊 Azure Stack Hub 的網域登入 Azure Stack Hub 入口網站後，必須將用來註冊 Azure Stack Hub 的網域名稱附加至入口網站 url。 例如，如果使用 fabrikam.onmicrosoft.com 註冊了Azure Stack Hub，且登入的使用者帳戶是 admin@contoso.com，則用來登入使用者入口網站的 URL 會是：https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

來賓使用者

來賓使用者是其他目錄租用戶中的使用者帳戶，這些使用者已獲得您目錄中資源的存取權。 若要支援來賓使用者，您可以使用Microsoft Entra識別碼，並啟用多租使用者的支援。 若已啟用支援，您可以邀請來賓使用者存取您目錄租用戶中的資源，進而能夠與外部組織共同作業。

若要邀請來賓使用者，雲端操作員和使用者可以使用Microsoft Entra B2B 共同作業。 受邀的使用者可取得您目錄中文件、資源及應用程式的存取權，而您會保有對自己的資源和資源的控制權。

身為來賓使用者，您可以登入其他組織的目錄租用戶。 若要這麼做，您必須將該組織的目錄名稱附加至入口網站 URL。 例如，如果您隸屬於 Contoso 組織，而且想要登入 Fabrikam 目錄，您可使用 https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

應用程式

您可以註冊應用程式以Microsoft Entra識別碼或 AD FS，然後將應用程式提供給組織中的使用者。

應用程式包括：

• Web 應用程式：範例包括 Azure 入口網站和 Azure Resource Manager。 它們支援 Web API 呼叫。
• 原生用戶端：範例包括 Azure PowerShell、Visual Studio 和 Azure CLI。

應用程式可支援兩種租用戶：

• 單一租用戶：僅支援應用程式註冊所在相同目錄中的使用者和服務。

  注意

  因為 AD FS 僅支援單一目錄，所以您在 AD FS 拓撲中建立的應用程式會設計為單一租用戶應用程式。

• 多租用戶：支援由以下目錄中的使用者和服務使用：應用程式註冊所在的目錄，以及其他租用戶目錄。 使用多租使用者應用程式時，另一個租使用者目錄的使用者 (另一個Microsoft Entra租使用者) 可以登入您的應用程式。

  如需多租用戶的詳細資訊，請參閱啟用多租用戶。

  如需有關如何開發多租用戶應用程式的詳細資訊，請參閱多租用戶應用程式。

當您註冊應用程式時，會建立兩個物件：

• 應用程式物件：應用程式在所有租用戶中的全域代表。 此關聯性是與軟體應用程式的一對一關聯性，且只存在於首先註冊應用程式的目錄中。

• 服務主體物件：在首先註冊應用程式的目錄中針對應用程式所建立的認證。 服務主體也會建立於使用該應用程式的每個其他租用戶的目錄中。 此關聯性可以是與軟體應用程式的一對多關聯性。

若要深入瞭解應用程式和服務主體物件，請參閱Microsoft Entra識別碼中的應用程式和服務主體物件。

服務主體

服務主體是應用程式或服務的一組「認證」，可授與 Azure Stack Hub 中資源的存取權。 使用服務主體可區隔應用程式權限與應用程式使用者的權限。

服務主體會建立於使用應用程式的每個租用戶中。 服務主體會建立身分識別，以供登入及存取受到該租用戶保護的資源 (例如使用者)。

• 單一租用戶應用程式在其首先建立的目錄中只有一個服務主體。 此服務主體會建立並同意在應用程式註冊期間使用。
• 如果是多租用戶 Web 應用程式或 API，則會在使用者同意使用應用程式的每個租用戶中建立一個服務主體。

服務主體的認證可以是金鑰 (透過 Azure 入口網站產生) 或憑證。 憑證的使用很適合自動化，因為一般認為憑證比金鑰更安全。

注意

當您使用 AD FS 搭配 Azure Stack Hub 時，只有系統管理員可以建立服務主體。 使用 AD FS 時，服務主體需要憑證並透過特殊權限的端點 (PEP) 來建立。 如需詳細資訊，請參閱使用應用程式身分識別來存取資源。

若要了解 Azure Stack Hub 的服務主體，請參閱建立服務主體。

服務

在 Azure Stack Hub 中與識別提供者互動的服務，識別提供者會將其註冊為應用程式。 如同應用程式，註冊可讓服務向身分識別系統進行驗證。

所有 Azure 服務都會使用 OpenID Connect 通訊協定和 JSON Web 權杖 來建立其身分識別。 由於Microsoft Entra識別碼和 AD FS 一致地使用通訊協定，因此您可以使用Microsoft 驗證程式庫 (MSAL) ，以取得安全性權杖，以在連線的案例中驗證內部部署或 Azure () 。 透過 MSAL，您也可以使用Azure PowerShell和 Azure CLI 等工具進行跨雲端和內部部署資源管理。

身分識別和身分識別系統

Azure Stack Hub 的身分識別包括使用者帳戶、群組和服務主體。

當您安裝 Azure Stack Hub 時，有數個內建應用程式和服務會在目錄租用戶中自動向您的識別提供者註冊。 有些註冊的服務可用於管理。 其他服務則可供使用者使用。 預設註冊會提供核心服務身分識別，這類身分識別可彼此互動，以及與您稍後新增的身分識別互動。

如果您以多租使用者設定Microsoft Entra識別碼，某些應用程式會傳播至新的目錄。

驗證和授權

應用程式和使用者的驗證

對應用程式和使用者而言，Azure Stack Hub 的架構可以用四個層次來說明。 各層之間的互動可以使用不同類型的驗證。

層	各層之間的驗證
工具與用戶端，例如系統管理員入口網站	若要存取或修改 Azure Stack Hub 中的資源，工具和用戶端會使用 JSON Web 權杖 來呼叫 Azure Resource Manager。 Azure Resource Manager 會驗證 JSON Web 權杖並查看所核發權杖中的「宣告」，以評估使用者或服務主體在 Azure Stack Hub 中具有的授權層級。
Azure Resource Manager 與其核心服務	Azure Resource Manager 會與資源提供者通訊，以傳輸使用者的通訊。 傳輸會透過 Azure Resource Manager 範本使用「直接命令式」呼叫或「宣告式」呼叫。
資源提供者	傳遞至資源提供者的呼叫會以憑證型驗證進行保護。 Azure Resource Manager 和資源提供者而後會持續透過 API 通訊。 對於從 Azure Resource Manager 接收的每個呼叫，資源提供者會使用該憑證來驗證呼叫。
基礎結構和商務邏輯	資源提供者會使用其所選的驗證模式來與商務邏輯和基礎結構通訊。 Azure Stack Hub 隨附的預設資源提供者會使用 Windows 驗證來保護此通訊。

向 Azure Resource Manager 進行驗證

若要向識別提供者進行驗證並收到 JSON Web 權杖，您必須具有下列資訊：

1. 身分識別系統 (授權單位) 的 URL：可以觸達識別提供者的 URL。 例如： https://login.windows.net 。
2. Azure Resource Manager 的應用程式識別碼 URI：已向識別提供者註冊之 Azure Resource Manager 的唯一識別碼。 此識別碼也是每個 Azure Stack Hub 安裝中的唯一識別碼。
3. 認證：您用來向識別提供者驗證的認證。
4. Azure Resource Manager 的 URL：URL 是 Azure Resource Manager 服務的位置。 例如，https://management.azure.com 或 https://management.local.azurestack.external。

當主體 (用戶端、應用程式或使用者) 提出驗證要求以存取資源時，該要求必須包含：

• 主體的認證。
• 主體想要存取之資源的應用程式識別碼 URI。

認證會經由識別提供者驗證。 識別提供者也會驗證應用程式識別碼 URI 是否用於已註冊的應用程式，以及主體是否擁有正確權限可取得該資源的權杖。 如果要求有效，就會授與 JSON Web 權杖。

此權杖必須接著傳入對 Azure Resource Manager 的要求標頭中。 Azure Resource Manager 會執行下列作業 (沒有特定順序)：

• 驗證 issuer (iss) 宣告，以確認權杖來自正確的識別提供者。
• 驗證 audience (aud) 宣告，以確認權杖已簽發給 Azure Resource Manager。
• 驗證 JSON Web 權杖是否使用透過 OpenID 設定的憑證來簽署，而且為 Azure Resource Manager 所知。
• 檢閱「issued at」(iat) 和「expiration」(exp) 宣告，以確認權杖為作用中並可接受。

完成所有驗證時，Azure Resource Manager 會使用「object id」(oid) 和「groups」宣告來產生主體可以存取的資源清單。

注意

部署之後，不需要Microsoft Entra全域管理員許可權。 不過，某些作業可能需要全域管理員認證 (例如，需要獲派權限的資源提供者安裝程式指令碼或新功能)。 您可以暫時恢復帳戶的全域管理員權限，或使用擁有「預設提供者訂用帳戶」的個別全域管理員帳戶。

使用角色型存取控制

Azure Stack Hub 中的角色型存取控制 (RBAC) 與 Microsoft Azure 中的實作一致。 您可以藉由將適當的 RBAC 角色指派給使用者、群組及應用程式，來管理資源的存取權。 如需如何使用 RBAC 搭配 Azure Stack Hub 的相關資訊，請參閱下列文章：

• 在 Azure 入口網站中開始使用角色型存取控制。
• 使用角色型存取控制來管理 Azure 訂用帳戶資源的存取。
• 建立 Azure 角色型存取控制的自訂角色。
• 在 Azure Stack Hub 中管理角色型存取控制。

使用 Azure PowerShell 進行驗證

如需有關使用 Azure PowerShell 向 Azure Stack Hub 驗證的詳細資料，請參閱設定 Azure Stack Hub 使用者的 PowerShell 環境。

使用 Azure CLI 進行驗證

如需使用 Azure PowerShell 向 Azure Stack Hub 驗證的相關資訊，請參閱安裝和設定 Azure CLI 以便與 Azure Stack Hub 搭配使用。

Azure 原則

Azure 原則有助於強制執行組織標準及大規模評估合規性。 其合規性儀表板會提供彙總檢視，以評估環境的整體狀態，並能夠向下切入至每個資源和每個原則的細微性。 也可透過對現有資源進行大規模補救，以及自動對新資源進行補救來協助您的資源達到合規性。

Azure 原則的常見使用案例包括針對資源一致性、法規合規性、安全性、成本和管理來進行治理。 這些常見使用案例的原則定義已內建在您的 Azure 環境中，可協助您開始進行作業。

注意

Azure Stack Hub 目前不支援 Azure 原則。

Azure AD Graph

Microsoft Azure 已于 2020 年 6 月 30 日宣佈淘汰 Azure AD Graph，以及其淘汰日期 2023 年 6 月 30 日。 Microsoft 會透過電子郵件通知客戶這項變更。 如需詳細資訊，請參閱 Azure AD Graph 淘汰和 Powershell 模組淘汰部落 格。

下一節將說明此淘汰對 Azure Stack Hub 的影響。

Azure Stack Hub 小組會與 Azure Graph 小組密切合作，以確保您的系統視需要繼續在 2023 年 6 月 30 日後繼續運作，以確保順利轉換。 最重要的動作是確保您符合 Azure Stack Hub 服務原則的規範。 客戶會在 Azure Stack Hub 的管理員入口網站中收到警示，而且必須更新主目錄和所有上線的來賓目錄。

大部分的移轉本身都會由整合式系統更新體驗完成;客戶需要手動步驟，才能將新許可權授與這些應用程式，這需要與 Azure Stack Hub 環境搭配使用之每個Microsoft Entra目錄中的全域管理員許可權。 安裝這些變更的更新套件之後，系統管理入口網站中會引發警示，指示您使用多租使用者 UI 或 PowerShell 腳本完成此步驟。 這是您在上線其他目錄或資源提供者時所執行的相同作業;如需詳細資訊，請參閱 在 Azure Stack Hub 中設定多租使用者。

如果您使用 AD FS 作為 Azure Stack Hub 的身分識別系統，這些 Graph 變更不會直接影響您的系統。 不過，Azure CLI、Azure PowerShell等最新版的工具需要新的 Graph API，而且它們將無法運作。 請確定您只使用指定 Azure Stack Hub 組建明確支援的這些工具版本。

除了管理員入口網站中的警示之外，我們也會透過更新版本資訊傳達變更，並且會傳達哪些更新套件需要更新主目錄及所有上線的來賓目錄。

後續步驟

• 身分識別架構
• 資料中心整合 - 身分識別