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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Вы также можете обратиться к провайдеру членства asp.net.