Question

我已经创建了.NET Core 2.0 API并将其发布到Azure。我有一个API管理（APIM）实例，该实例位于该API的前面，并完成了它所做的所有奇妙的事情。但是，有一件事我似乎无法全神贯注或找不到任何文档。操作授权。（不要与身份验证相混淆，我已经很好地工作了。）

我的API是具有CRUD操作的简单RESTful服务。让我们以读取操作为例：

GET /api/owner/{ownerid}/thing/{thingid}

在这种情况下，我想做的就是授予用户在特定所有者内读取内容的权限。同一用户可能没有其他所有者的读取权限。如果用户具有权限，200 OK;否则为403 Forbidden。

完全保留 carte blanche ，有什么建议可以实现呢？我假设APIM中每个操作的入站策略将在哪里执行？如果可以，怎么办？

更新1

我被告知可能在各个操作级别使用相同的validate-jwt策略以附加到根源的validate-jwt策略。这个想法是，当操作策略检查特定声明时，根策略将验证用户的身份。这似乎很好用，但这是正确的方法，还是只是一种破解？

更新2

要使validate-jwt选项起作用，权限模型需要与角色和组保持一致；否则，它和建立您自己的自定义数据库一样工作，至少您可以从自己的规则中受益。最后，我将权限放入Azure存储帐户表（任何数据库都可以）中，并使用send-request（具有适当的缓存）基于当前操作和用户收集权限。它运作良好，但“感觉不对”。我很高兴与任何需要分享的细节。同时，如果有人有更好的主意，我将暂时不公开。

Answer 1

最终唯一的方法是在操作级别使用策略。您可以使用validate-jwt检查特定的声明，也可以检查作为请求的一部分传递给您的其他凭据。或者，您可以使用send-request来调用其他服务并要求用户权限。在APIM本身中，除了一些基本信息之外，没有地方可以存储任何与用户相关的数据，因此，此类授权信息必须来自APIM之外。

Answer 2

最后，似乎没有内置的解决方案。滚动自己的权限模型然后自己进行验证是解决问题的方法。

但是...

这仍然可以在APIM中完成。正如我在第二次更新中提到的那样，我能够使自定义解决方案起作用。完成此操作的方法是在“所有操作”级别使用入站策略来检索权限。（使用了一种缓存机制，以便不检索每个调用的权限。）然后，每个操作都根据传入的参数确定用户是否对该特定操作具有权限。（也缓存。）< / p>

结果是根API没有内置身份验证或授权，但APIM确实存在，并且观察到了适当的行为。

不过，首选还是RBAC方法。例如，假设在此角色定义中将各个操作视为服务：

{
  "Name": "{rolename}",
  "Id": "{roleid}",
  "IsCustom": true,
  "Description": "{roledescription}",
  "Actions":  [
    "GET {myapi}/owner/{ownerid}/*",
    "POST {myapi}/owner/{ownerid}/*",
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionid}"
  ]
}

如果可能的话，我们可以创建角色，在订阅级别将其分配给用户/组，然后将声明自动传递到APIM，在其中可以像其他任何声明一样对它们进行评估。

如何在Azure API管理中实现对操作的用户权限？

2 个答案: