Маршрутизация бизнес-подразделений: детальный контроль доступа в ASP.NET MVC

Как следует структурировать маршруты ASP.NET MVC, чтобы обеспечить детальный контроль доступа на основе ролей к филиалам бизнеса?

Каждый бизнес-объект связан с филиалом либо сам по себе, либо через свои родительские объекты. Есть ли элегантный способ авторизации действий на основе пользовательских ролей для любого количества веток?

1. {ветка} в пути?

{branch}/{controller}/{action}/{id}

Действие:

[Authorize(Roles="Technician")]
public ActionResult BusinessWidgetAction(BusinessObject obj)
{
    // Authorize will test if User has Technician role in branch context
    // ...
}

2. Получить филиал от хозяйствующего субъекта?

{controller}/{action}/{id}

Действие:

public ActionResult BusinessWidgetAction(BusinessObject obj)
{
    if (!User.HasAccessTo("WidgetAction", obj.Branch))
        throw new HttpException(403, "No soup for you!"); // or redirect

    // ...
}

3. Или есть способ лучше?


person Petrus Theron    schedule 28.04.2010    source источник
comment
Глядя на ваш другой вопрос, я чувствую, что вам нужно пересмотреть то, как работает ваш доступ / безопасность. Я понимаю необходимость детального контроля, и мне кажется, что есть много ограничений, которые вам нужны - это для меня повод для переосмысления.   -  person Ahmad    schedule 29.04.2010
comment
@ Ахмад: Стоит ли мне смотреть на ACL?   -  person Petrus Theron    schedule 29.04.2010
comment
Не слишком уверен в ACL ... однако я использую custom membership provider, что поможет. Вы хотите authorize actions based on user-roles достаточно просто для поставщика членства по умолчанию, однако дополнительное ограничение for any number of branches - так это на самом деле отношение Роль- ›Ветви (например, Пользователь находится в роли администратора для некоторых ветвей) или Пользователь-› Ветви (не могу вспомнить пример ) отношение. Возможно, я что-то упускаю !!   -  person Ahmad    schedule 29.04.2010
comment
У меня есть таблицы для Branches (например, Кейптаун), Roles (например, Admin, Techie) и Users (Джон, Джилл, Питер). с UserRoles таблицей, которая отслеживает пользователя, ветку и роль, например. (Питер, Кейптаун, Techie). Мне нравится здесь ответ Рунеборга: stackoverflow.com/questions/1335315/   -  person Petrus Theron    schedule 29.04.2010
comment
Я уже использую настраиваемого поставщика членства и ролей.   -  person Petrus Theron    schedule 29.04.2010


Ответы (1)


В итоге я использовал одну и ту же кодовую базу для отдельных приложений и баз данных для каждой бизнес-отрасли. Это означает, что я должен обновлять каждый по отдельности, но допускает разветвление функций.

Я свернул свой собственный атрибут [BranchAuthorize(Roles = "Editor, Stock Keeper")], который проверяет роли аутентифицированного пользователя на соответствие требуемым ролям действия контроллера и отображает сообщение с подробным описанием требуемых ролей, если они не назначены.

Единый контроль доступа к филиалам потребует отдельной службы авторизации, но позволит централизованно управлять правами.

person Petrus Theron    schedule 03.01.2011