使用Service Principal授予对Azure的访问权限

Question

我试图了解有关使用 Azure服务原则将授权委派给Azure BLOB的几点。

我如何配置Azure：

• 在Active Directory中创建和配置服务主体：我创建了一个应用程序，创建了一个密钥（密码），并设置了访问Azure存储所需的权限;

• 配置Azure存储的IAM：在存储帐户部分下，我选择了我的存储帐户，在IAM下我将我的帐户（我的登录帐户为XYZ@hotmail.com）分配给< em>存储BLOB数据贡献者角色。

我如何使用客户端App中的配置：

1. 使用上述配置;我的应用程序采用租户ID，客户端ID，客户端密钥等，并将授权请求发送到/authorize端点。
2. 然后弹出一个窗口并要求我登录（使用例如XYZ@hotmail.com），然后弹出一个同意屏幕，并要求我允许服务主体读取我的Azure存储。
3. 我批准后，我的客户端应用程序会收到OAuth2.0 code。
4. 然后我通过code端点与access_key交换/token。

Q1：这个access_key是否授予我的客户端应用程序与XYZ@hotmail.com或服务主体相同的权限？

使用获得的访问密钥，我可以读/写azure blob。

Q2：如果XYZ@hotmail.com没有读/写访问权限（即未分配存储BLOB数据贡献者角色），我的客户端应用程序将无法读/写对于blob，，无论服务主管的角色是什么。这是我感到困惑的地方，我的印象是我的客户端App正在承担服务主体，因此它将具有与服务主体相同的权限，而不是XYZ@hotmail.com。例如，XYZ @ hotmail.com可以具有 Contributor 角色（即读/写），而服务原则将分配 Reader 角色。在这种情况下，我将拥有对BLOB存储的完全访问权限，而我的客户端应用程序将只具有对BLOB存储的读取权限。但是，似乎客户端应用程序获得与XYZ@hotmail.com相同的权限。我在这里错过了什么？

Answer 1

  

Q1：这个access_key是否授予我的客户端应用程序相同的权限   作为XYZ@hotmail.com或服务负责人？

您获得的access_token具有委托权限，该权限属于XYZ@hotmail.com 。这是因为您使用了Authorization code grant flow。

  

我在这里缺少什么？

对于您的方案，我建议您使用client_credentials flow作为您的应用。

使用client_credentials流程，只有在AAD中配置的应用程序权限才能获得访问令牌。此外，此访问令牌实际上是您的AAD应用程序本身的一部分。如果您为服务主体分配角色，您将获得具有该角色权限的访问令牌。

如果您使用授权代码授予流程，您将获得用户的访问令牌，而不是服务主体。因此，访问令牌将拥有该用户的权限。