Должен ли уровень бизнес-логики реализовывать авторизацию и аутентификацию?

У меня есть уровень бизнес-логики («репозиторий»), который представлен как набор интерфейсов .NET, поддерживаемых заменяемыми конкретными реализациями.

Первоначально у меня был этот бизнес-уровень, реализующий аутентификацию и авторизацию (authn / authz), то есть у меня были интерфейсы, такие как IUserIdentity и IUserRole, и все методы, которые обращались к конфиденциальным данным, принимали IUserIdentity и выполняли авторизацию, прежде чем разрешить действие.

Бизнес-уровень до этого момента был очень агностиком внешнего интерфейса ... но теперь, когда я пытаюсь интегрироваться в веб-сайт ASP.NET, я понял, что сам ASP.NET имеет встроенную богатую систему аутентификации / авторизации. через API членства и роли.

Итак, вопрос в том, следует ли мне удалить все authn / authz из уровня бизнес-логики и полагаться на веб-интерфейс для этого? Это сильно упростило бы задачу, но я не знаю, пожалею ли я позже о том, что убрал ее.

Альтернативный вариант - сохранить authn / authz в моей бизнес-логике, но интегрировать его с ASP.NET с помощью настраиваемых поставщиков членства / ролей. Однако это кажется действительно обременительным ... Мне все еще нужно выяснить, во сколько обойдется это.

Что бы вы сделали (или сделали) и почему?

Ответов (5)

Решение

Я думаю, что безопасность - это комплексная проблема, которая относится к аспектам. Я не знаю, есть ли у .NET аспекты, если только вы не используете Spring.NET.

Оставь это. Аутентификацию с помощью форм в ASP.NET очень легко настроить, а уровень бизнес-логики остается независимым от внешнего интерфейса.

Попробуйте отказаться от этого подхода и вместо этого попробуйте проверку подлинности с помощью форм . По сути, вы можете вызывать свои установленные методы из события Authenticate элемента управления Login.

Я предлагаю вам сохранить существующую логику и написать настраиваемого поставщика членства / роли вокруг существующих классов безопасности, если вы хотите использовать его напрямую, используя asp.net. Это должно быть проще, чем вы думаете.

http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx

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

Это также поможет вам использовать логику безопасности позже, скажем, когда вы создадите клиент Winform, который использует вашу бизнес-логику, или когда вы предоставите свою бизнес-логику в виде веб-сервисов.

Планируете ли вы использовать несколько интерфейсов (asp.net, winforms, мобильный?) Или открывать бизнес-уровень через (веб) сервисы? Тогда вам, вероятно, следует реализовать аутентификацию поверх бизнес-уровня.

Когда все, что вам нужно, - это предоставить / запретить доступ, вы можете использовать интегрированную безопасность в IIS и никогда не использовать для этого специальный код.

Вы также можете посмотреть на поставщика членства asp.net.

Я считаю, что безопасность на основе ролей должна быть на бизнес-уровне, куда ее помещает CSLA.