보안 엔티티 둘 중 하나로, OData 엔드 포인트

Question

내가이는 내가 여부를 확인할 수있는 지점에 유용 ClaimsAuthorizationManager.CheckAccess(...)

public class AuthorizationManager : ClaimsAuthorizationManager 
{ 
    public override bool CheckAccess(AuthorizationContext context) 
    { 
     var resource = context.Resource.First().Value; 
     var action = context.Action.First().Value; 

     return Policies.Validate(resource, action); 
    } 
} 

우선 다음과 같은 컨트롤러

namespace MyNamespace.Api.Controllers 
{ 
    [Authorize] 
    public class AccountController : ODataController 
    { 
     private Entities db = new Entities(); 

     // GET odata/Account 
     [Queryable] 
     [ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "Read", Resource = "Account")] 
     public IQueryable<Account> GetAccount() 
     { 
      return db.Accounts(); 
     } 

     ... 

    } 

} 

을 감안할 때 Current Principal일반적으로은 ReadAccount입니다. 그러나 어떤 사용자가 어떤 계정을 읽을 수 있는지 확인하고 싶다면 잃어 버릴 수 있습니다.

관리자가 아닌 모든 사용자가 자신의 계정 만 읽을 수 있어야하는 반면 관리자 인 모든 계정을 읽을 수 있어야하는 관리자 사용자가 있다고 가정 해 보겠습니다.

이전에 이와 같은 작업을 수행했는지 또는 몇 가지 힌트를 제공 했습니까?

Answer 1

샘플에서 요청한 계정처럼 동적 매개 변수를 전달할 수 없으므로 ClaimsPrincipalPermissionAttribute을 사용하지 않습니다.

은 (예를 들어 책 "프로 APS.NET 웹 API 보안"97 페이지 그들은 당신이 요청 Account을 통과 할 수 있도록 수동으로 구성되어 context 코드 new IdentityConfiguration().ClaimsAuthorizationManager.CheckAccess(context),하여 컨트롤러 액션 구현에서 AuthorizationManager를 호출하는 것이 좋습니다에서보세요)을 AuthorizationManager 구현에서 확인하려면 Resource으로 지정하십시오.

또한 pluralsight 교육 ".NET 4.5의 ID 및 액세스 제어 소개"를 살펴보십시오. 웹 API에서 클레임 기반 보안을 구현하는 방법에 대한 정보도 있습니다.

이제 보안에 대해 이야기하고 있습니다. 흥미가 있습니다.

내 경우 : 역할 관리자는 국가별로 할당되며, 모든 관리자는 자신이 액세스 할 수있는 국가와 관련된 엔티티 만 볼 수 있습니다.

업데이트 : 여러 프로젝트를 수행 한 후 클레임 기반 보안을 잊어 버렸습니다. 이는 보안 검사를하기가 매우 어렵 기 때문입니다. 오늘 나는 모든 보안 검사가 완료된 데코레이터 패턴을 사용합니다. 다음과 같은 OData 컨트롤러에서도 보안을 구현하는 것은 매우 쉬운 것처럼 보입니다. public IQueriable MyQuriableEntitySet { get{ return implementationWithoutSecurity.MyQuriableEntitySet.Where(e=>e.Country.Code = currentUser.AssignedTo.CountryCode || currentUser.IsSuperAdmin); } }