Azure 轉送驗證和授權
有兩種方式可以驗證和授權對 Azure 轉送資源的存取:Microsoft Entra ID 和共用存取簽章 (SAS)。 本文詳述使用這兩種安全性機制。
Microsoft Entra ID
Azure 轉送資源的 Microsoft Entra 整合,提供 Azure 角色型存取控制 (Azure RBAC),可細微控制用戶端的資源存取。 您可以使用 Azure RBAC 將許可權授與安全性主體,其可以是使用者、群組或應用程式服務主體。 安全性主體是由 Microsoft Entra ID 進行驗證,以傳回 OAuth 2.0 權杖。 權杖可以用來授權 Azure 轉送資源的存取要求。
如需使用 Microsoft Entra ID 進行驗證的詳細資訊,請參閱下列文章:
重要
使用由 Microsoft Entra ID 傳回的 OAuth 2.0 權杖來授權使用者或應用程式,可透過共用存取簽章 (SAS) 提供卓越的安全性與易用性。 透過 Microsoft Entra ID 即不需要冒著潛在安全性弱點的風險,將權杖儲存在程式碼中。 建議您盡可能將 Microsoft Entra ID 與 Azure 轉送應用程式搭配使用。
內建角色
對於 Azure 轉送來說,透過 Azure 入口網站和 Azure 資源管理 API 來管理的命名空間和所有相關資源,皆已使用 Azure RBAC 模型來加以保護。 Azure 提供下列 Azure 內建角色,以授權轉送命名空間的存取:
角色 | 描述 |
---|---|
Azure 轉送擁有者 | 使用此角色來授與 Azure 轉送資源的「完整」存取權。 |
Azure 轉送接聽程式 | 使用此角色來授與 Azure 轉送資源的「接聽和實體讀取」存取權。 |
Azure 轉送寄件者 | 使用此角色來授與 Azure 轉送資源的「傳送和實體讀取」存取權。 |
共用存取簽章
應用程式可以使用共用存取簽章 (SAS) 驗證向 Azure 轉送進行驗證。 SAS 驗證可讓應用程式使用轉送命名空間中所設定的存取金鑰,向 Azure 轉送服務進行驗證。 您可以接著使用此金鑰來產生共用存取簽章權杖,以便用戶端用來向轉送服務進行驗證。
SAS 驗證可讓您授與使用者具有特定權限之 Azure 轉送資源的存取權。 SAS 驗證牽涉到在資源上設定具有相關權限的密碼編譯金鑰。 接著用戶端可以藉由提出 SAS 權杖 (其中包含正在存取的資源 URI 及利用設定金鑰簽署的到期日) 存取該資源。
您可以在轉送命名空間上設定 SAS 的金鑰。 不同於服務匯流排傳訊,轉送混合式連線支援未經授權或匿名的寄件者。 您可以在建立實體時啟用匿名存取,如下列入口網站中的螢幕擷取畫面所示︰
若要使用 SAS,您可以在轉送命名空間上,設定包含下列屬性的 SharedAccessAuthorizationRule 物件:
- KeyName 。
- PrimaryKey 是用來簽署/驗證 SAS 權杖的密碼編譯金鑰。
- SecondaryKey 是用來簽署/驗證 SAS 權杖的密碼編譯金鑰。
- 權限 表示接聽、傳送或管理授與權限的集合。
在命名空間層級設定的授權規則可以授與命名空間中所有轉送連線的存取權給具備使用對應金鑰簽署之權杖的用戶端。 在轉送命名空間上最多可以設定 12 條這類授權規則。 根據預設,具備所有權限的 SharedAccessAuthorizationRule 會在初次佈建時針對每個命名空間進行設定。
若要存取實體,用戶端需要使用特定 SharedAccessAuthorizationRule產生的 SAS 權杖。 SAS 權杖乃是使用資源字串的 HMAC-SHA256 所產生,該字串由宣告存取的資源 URI 以及具備與授權規則相關聯之密碼編譯金鑰的過期所組成。
Azure 轉送的 SAS 驗證支援包含在 Azure .NET SDK 2.0 版或更新版本中。 SAS 包括 SharedAccessAuthorizationRule的支援。 所有接受連接字串做為參數的 API 包括 SAS 連接字串的支援。
範例
- 混合式連線:.NET、JAVA 和 JavaScript
- WCF 轉送:.NET
下一步
- 如需 SAS 的詳細資料,請繼續閱讀使用共用存取簽章的服務匯流排驗證。
- 如需混合式連線功能的詳細資訊,請參閱 Azure 轉送混合式連線通訊協定指南。
- 如需服務匯流排傳訊驗證和授權的相關對應資訊,請參閱服務匯流排驗證和授權。