访问/保护 Restful 服务 oAuth2答案

【问题标题】：Accessing/Securing Restful service oAuth2访问/保护 Restful 服务 oAuth2
【发布时间】：2018-06-13 13:05:59
【问题描述】：

我正在尝试编写一个具有多个端点的 Restful 服务，例如

假设每个端点调用都由一个角色保护。

GetEmployees（角色/声明 = Employee.Readonly 或 Employee.Edit 或 Employee.Admin）
AddEmployee（角色/声明 = Employee.Edit 或 Employee.Admin）
UpdateEmployee（角色/声明 = Employee.Edit 或 Employee.Admin）
删除员工（角色/声明 = Employee.Admin）

使用隐式流程非常简单，只需检查角色声明即可。
我的困惑是客户凭证流，如何在这里将范围映射到角色？

【问题讨论】：

标签： c# asp.net-web-api oauth-2.0 identityserver4

【解决方案1】：

假设您对客户端凭据方法有以下情况：

var client = new TokenClient(
            BaseAddress + "/connect/token",
            "clientId",
            "clientSecret");

var result = client.RequestClientCredentialsAsync(scope: "my.api").Result;

var accessToken = result.AccessToken;

var client = new HttpClient();
client.SetBearerToken(accessToken);
var result = client.GetStringAsync("https://protectedapiaddress/api/data/getdata").Result;

BaseAddress 是您的 IDS 地址。

当然，您必须使用适当的流程（客户端凭据）在 IDS 客户端列表中注册您的客户端，范围是可选的，但我想您需要一个。

然后在 API 端你可以使用新的Policy-based authorization。

API方法：

[HttpGet]
[Authorize(Policy = "AdminUser")]
[Route("getdata")]
public Data GetData()
{
  // some code here
}

以及授权要求：

public class AdminUserRequirement : AuthorizationHandler<AdminUserRequirement>, IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, AdminUserRequirement requirement)
    {
        if (!context.User.HasClaim(<'Your rule'>))
        {
            context.Fail();
        }
        else
        {
            context.Succeed(requirement);
        }
        return Task.FromResult(0);
    }
}

在您将拥有的声明中

    {
       "scope" : "my.api"
       "clientId" : "clientId"
    }

等等。然后你就可以应用规则了。

编辑：忘了提 - 您必须在 Startup.cs 中注册策略

public void ConfigureServices(IServiceCollection services)
{
    services
            .AddMvcCore()
            .AddAuthorization(options =>
            {
                    options.AddPolicy("AdminUser",
                    policy => policy.Requirements.Add(new AdminUserRequirement()));
            });

    // More code here

}

【讨论】：

使用策略或角色只是语法的改变。范围“my.api”如何转化为策略？如果我们按照您的方式合并我的示例，我将有 3 种策略，即 ReadOnly、User、AdminUser。在需求类中，我将寻找确切的声明，但范围如何转化为策略？
我并不是说范围转化为策略。我只是说您将在声明中拥有范围和 clientid，并且由于使用客户端凭据流，您所拥有的就是这些，您可以在策略中使用它们来允许/拒绝访问。将策略视为更像自定义授权属性。是的 - 如果您采用这种方式，您将需要为每个不同的角色制定不同的政策。很多人不喜欢它，这是一种开销，但微软......