Каков наилучший механизм реализации гранулярной безопасности (то есть авторизации) в приложении ASP.NET MVC?

Предположим, что высокоскоростному разработчику было поручено создать банковское приложение, к которому будут обращаться многие люди. Каждый человек хотел бы получить доступ к своей собственной учетной записи, но не хотел бы, чтобы другие могли получить к ней доступ. Я хотел бы узнать наилучшую практику ограничения доступа в приложении MVC, чтобы доступ к ней мог получить только пользователь, которому принадлежит эта информация (или администратор).

Атрибут Authorize позволяет нам ограничивать роль. Хотя это отправная точка, кажется, что любой аутентифицированный пользователь может получить доступ к любой другой пользовательской информации.

ActionFilters, похоже, предлагают возможность для более детального контроля и, вероятно, могут быть использованы для выполнения задачи. Однако неясно, будут ли они рекомендуемым методом.

Любые рекомендации или идеи приветствуются.

Ответ 1

ActionFilter, вероятно, является хорошей отправной точкой, но в зависимости от вашей архитектуры вы можете подумать, достаточно ли защищена защита периметра.

Если вы по существу создаете однослойное приложение ASP.NET MVC (и для этого могут быть вполне разумные причины), ActionFilter обеспечит защиту, которая будет достаточно хорошей, и в то же время очень просто применить.

С другой стороны, если ваше приложение является многоуровневым приложением, защита в глубину более подходит. В этом случае вам следует рассмотреть возможность применения логики авторизации в модели домена или, возможно, даже на уровне доступа к данным. Это гарантирует, что если вы когда-либо разрабатываете другое приложение на основе той же модели домена (например, веб-службы), логика авторизации все равно будет применяться.

Независимо от того, что вы делаете, я настоятельно рекомендую вам основать фактическую реализацию авторизации на IPrincipal.

В более конкретной заметке, о чем вы спрашиваете, лучше всего смоделировать с помощью авторизации на основе ACL: установите ACL для каждого профиля пользователя, который по умолчанию предоставляет доступ только к самому пользователю и администратору. Если вам когда-либо понадобится развернуть приложение, чтобы разрешить делегированный доступ к профилям других пользователей (я не знаю, является ли это даже отдаленно реалистичным в вашем конкретном случае), вы можете просто сделать это, добавив новую запись в ACL.

В таком случае оценка доступа включает в себя получение ACL для запрошенного ресурса и проверку того, включен ли текущий пользователь (IPrincipal) в этот ACL. Такая операция, скорее всего, будет включать операции вне процесса (поиск ACL в базе данных), поэтому включение ее в неявную часть приложения, скрывая ее за ActionFilter, похоже, может потенциально скрыть некоторые проблемы с производительностью. В таком случае я бы подумал о том, чтобы сделать модель авторизации немного более эксплицитной/видимой.

Ответ 2

Согласно моему мнению, если у вас есть однослойное приложение, то авторизация - лучший вариант, а actionfilter намного лучше и проще в использовании. Но если ваше приложение является многоуровневым, то вы используете список управления доступом US USER [ACL].

Ответ 3

Я думаю, что у вас все в порядке, подход ActionFilter звучит один.

Я бы создал набор настраиваемых фильтров действий, унаследованных от AuthorizeAttribute.

В дополнение к смежности атрибута Authorize вы можете применить политику более строгого владельца только.

НТН,

Dan

Ответ 4

Если вы когда-либо захотите вытеснить авторизацию, вы можете взглянуть на XACML-реализации.