계층 정책/난 그냥 ASP.NET 핵심 아이덴티티로 시작하고있어 다음과 같은 요구 사항이 정의

Question

ASP.NET 코어 정체성에 대한 요구 사항 : 다음과 같은 기본 핸들러와

public sealed class IsCustomerUserRequirement : IAuthorizationRequirement 

public sealed class IsSuperUserRequirement : IAuthorizationRequirement 

:

public class IsCustomerUserHandler : AuthorizationHandler<IsCustomerUserRequirement> 
{ 
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IsCustomerUserRequirement requirement) 
    { 
     if (context.User.HasClaim(_ => _.Type == "customer")) 
     { 
      context.Succeed(requirement); 
     } 

     return Task.CompletedTask; 
    } 
} 

public class IsSuperUserHandler : AuthorizationHandler<IsSuperUserRequirement> 
{ 
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IsSuperUserRequirement requirement) 
    { 
     if (context.User.IsInRole("super_user")) 
     { 
      context.Succeed(requirement); 
     } 

     return Task.CompletedTask; 
    } 
} 

 services 
      .AddAuthorization(options => 
      { 
       options.AddPolicy("MustBeSuperUser", policy => policy.Requirements.Add(new IsSuperUserRequirement())); 
       options.AddPolicy("CustomersOnly", policy => policy.Requirements.Add(new IsCustomerUserRequirement())); 
      }); 

을 그리고을 사용하여 적용

나는 그 기본 방침 안에이를 넣을 수 있습니다, 잘 작동합니다.

내 요구 사항 슈퍼 사용자를 허용 할 수있다, 또한 만 지역 고객에 액세스 할customer 주장하지 않고 super_user 역할을하지만 와 원칙을 주장한다.

나는 현재 수동으로 확인하기 위해 핸들러를 변경하여이 구현 한 :

protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IsCustomerUserRequirement requirement) 
    { 
     if (context.User.HasClaim(_ => _.Type == Claims.Customer) || 
      context.User.IsInRole(Roles.SuperUser)) 
     { 
      context.Succeed(requirement); 
     } 

     return Task.CompletedTask; 
    } 

내 문제 내가 요점 것 같은이 느낌입니다. 앞으로는 각 처리기에서 수퍼 유저 수표를 반복 할 필요가 없도록 이것을 정의하는 더 좋은 방법이 있습니까?

---

더 큰 그림은 IdentityServer4 (ASP.NET Identity-backed)를 사용하여 인증 한 다음 몇 가지 JWT 기반 클레임 (하나의 클레임, 두 가지 역할)을 사용하여 사용자를 더욱 식별합니다. 응용 프로그램 별 역할/권한 구조 및 Identity Server와 관련이없는 사용자 정의 미들웨어 등이 있습니다. 이 주제에 대해 모범 사례가 있다면 무엇이 있을까요?

Answer 1

"이 점이 누락 된 것 같습니다." - 예, 포인트가 누락되었습니다. 역할 기반 인증 : 사용자는 고객 또는 수퍼 유저가 될 수 있습니다.

대신 새 모델은 사용자가 무언가에 대한 클레임을 갖고 있으며이를 사용하여 권한을 부여하는 클레임 ​​기반 권한 부여입니다. 따라서 이상적으로 수퍼 유저는 고객이받는 것과 동일한 요구를 받게되고 그런 식으로 리소스에 대한 액세스가 허용됩니다. 그런 주장은 또한 customer이라고 부르지는 않지만, 오히려 사용자의 속성 인 것입니다.

클레임에 따라 역할 기반 인증 모델을 계속 사용할 수는 있지만 은으로 혼합해서는 안됩니다. 네가 알아 차렸으니, 결국 조금 이상해진다.

다른 조건을 사용하여 정책을 성공시키는 데는 여러 가지 방법이 있습니다.

options.AddPolicy("MustBeSuperUser", policy => policy.RequireRole("super_user")); 
options.AddPolicy("CustomersOnly", policy => policy.RequireRole("customer", "super_user")); 

그 방법의 CustomersOnly 정책이 모두 customer 및 super_user 역할에 의해 성취 될 것입니다 : 당신이 역할 만 (대신의 customer 주장을)를 사용한다면, 당신은 단순히 내장 된 방법을 사용할 수 있습니다.

고객에게 역할을 사용하지 않으므로 여기에서 요구 사항 구현을 따라야합니다.인증 요구 사항이 작동하는 방식은 동일한 요구 사항 유형에 대해 여러 개의 처리기를 가질 수 있으며 그 중 하나만 성공해야한다는 것입니다 (아무도 이 실패한 경우).

따라서 IsSuperUserHandler에서 여러 요구 사항을 처리 할 수 ​​있습니다. 이 작품을 만들기 위해 AuthorizationHandler<T> 구현을 따를 수 :

public class IsSuperUserHandler : IAuthorizationHandler 
{ 
    public virtual async Task HandleAsync(AuthorizationHandlerContext context) 
    { 
     foreach (var req in context.Requirements) 
     { 
      if (req is IsSuperUserRequirement || req is IsCustomerUserRequirement) 
      { 
       if (context.User.IsInRole("super_user")) 
        context.Succeed(req); 
      } 
     } 
    } 
} 

그래서 당신의 IsSuperUserHandler 지금 IsSuperUserRequirement과 IsCustomerUserRequirement 모두 승인 처리기입니다. 따라서 IsCustomerUserRequirement이 필요한 CustomersOnly 정책은 수퍼 유저에게도 적용됩니다.