时间戳

首页 > 解决方案 > 如何根据 .NET Core 3.1 中的最佳实践与基于标头的标头交换基于声明的安全性？

c# - 如何根据 .NET Core 3.1 中的最佳实践与基于标头的标头交换基于声明的安全性？

问题描述

注意，它不等同于这个问题- 它太旧并且考虑其他版本/平台。

我们正在像这样设置授权策略。它有效，我为这个解决方案感到自豪。

options.AddPolicy("ClaimPolicy", config =>
{
  config.RequireAssertion(context =>
  {
    ClaimsPrincipal user = context.User;
    Claim awo = user.Claims.Single(a=>a.Type=="awo");
    bool authorized = user.IsInRoleAwo("management");
    return authorized;
  });
});

现在，需求发生了变化。AWO 值仍将被使用，但它不会作为访问令牌的一部分作为其中的声明。相反，它将作为请求的标头提供给我们。就个人而言，我认为这在直觉上是可疑的，但我无法用技术术语表达我的不情愿，除了它是非常规的并且允许请求​​者自由地操纵安全参数。我没有足够的说服力，不得不退缩。（不可否认，那些无法激发选择的人表明它不是那么好。）

新版本长这样。问题是我在其中找不到有关 hte 标头、请求或 HTTP 上下文的任何信息。有用于用户和资源的字段。而已。

options.AddPolicy("HeaderPolicy", config =>
{
  config.RequireAssertion(context =>
  {
    var resource = context.Resource;
    // now what?!
    return true;
  });
});

我希望也许我可以获取路线并从那里选择 AWO 值（因为它是 REST 路径的一部分。我在资源字段中找到了可以(Microsoft.AspNetCore.Routing.RouteEndpoint)context.Resource往返于那里的东西，我可以获得.RoutePattern.RawText给我。遗憾的是，这会产生实际的模式，即DemoApi/mixed/{awo}/data而不是传入的值。

我是否应该回过头来不使用标题向我传递用于Authorize选择策略的信息？或者是否有最佳实践方法来获取有关哪些标头是请求的一部分的信息（或至少了解包含传递参数的路径）？

我有一个建议，可以创建一个自定义中间件放在中间AddAuthentication()，Add Authorization可能还有一个自定义授权处理程序。我认为更高的复杂性是一个警告，我不知道这是否是一个明智（甚至可行）的解决方案。就我的谷歌搜索而言，没有博客讨论它。在MSDN上有一篇关于这方面的广泛文章，但它不处理 SPA/headers 案例，而且在我看来，它似乎提供了我已经实现的功能RequireAssertion(...)。还有一个关于应用API 密钥要求的建议，但在我看来，这比我们尝试实现的通过自动化代码流获得的访问令牌更安全。

标签： c#.net-coreauthorizationidentityserver4

解决方案

推荐阅读