3

Учитывая следующий контроллерЗакрепление Сущности с авторизацией Claims Based в Web Api 2 OData Endpoint

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(); 
     } 

     ... 

    } 

} 

Я переопределять значение 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); 
    } 
} 

Это полезно только до точки, где я могу проверить, действительно ли Не рекомендуется Current PrincipalReadAccount. Однако, если я хочу проверить, какие учетные записи определенному пользователю разрешено читать, я теряюсь.

Предположим, у меня есть пользователь Менеджера, который должен иметь возможность читать все Учетные записи, для которых он является менеджером, в то время как пользователь, не являющийся менеджером, должен иметь возможность читать только свою собственную учетную запись.

Есть ли наилучшая практика для этого или вы сделали что-то подобное ранее и даете мне несколько намеков на поиск?

ответ

3

Я не использую ClaimsPrincipalPermissionAttribute, потому что я не могу передать им какие-либо динамические параметры, как запрошенная учетная запись из вашего образца.

Посмотрите на книгу «Pro APS.NET Web API безопасности» стр 97. Они предлагают вызвать AuthorizationManager от вашей реализации действий контроллера с помощью кода new IdentityConfiguration().ClaimsAuthorizationManager.CheckAccess(context), где context строится вручную, так что вы можете передать Account просил (например,) как Resource, чтобы проверить его в вашей AuthorizationManager реализации.

Также ознакомьтесь с учебным пособием по множественным вычислениям «Введение в идентификацию и контроль доступа в .NET 4.5». Также есть информация о том, как внедрить защиту на основе требований в веб-API.

Теперь я занимаюсь реализацией безопасности, о которой вы говорите, и я тоже заинтересован в этом вопросе.

Мое дело: роль Администратор назначается страной, каждый Администратор может видеть объекты, относящиеся только к странам, к которым у них есть доступ.

ОБНОВЛЕНИЕ: после нескольких проектов я забыл о безопасности на основе требований, поскольку это чрезвычайно сложный способ сделать проверки безопасности. Сегодня я использую шаблон декоратора, где выполняются все проверки безопасности. По-видимому, очень просто реализовать безопасность даже в контроллерах OData: public IQueriable MyQuriableEntitySet { get{ return implementationWithoutSecurity.MyQuriableEntitySet.Where(e=>e.Country.Code = currentUser.AssignedTo.CountryCode || currentUser.IsSuperAdmin); } }

+0

Great :) More reading. Говорят, что печатная индустрия умирает, но я прошу не согласиться. Конечно, есть Kindle, но я предпочитаю печатные копии. –

Смежные вопросы