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

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

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

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

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

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

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

7
asp.net design design-patterns

5 ответов

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

5

сохранить ее. Проверка подлинности форм в ASP.NET очень легко настроить, и ваш уровень бизнес-логики остается фронтальным агностиком.

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

1

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

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

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

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

1

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

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

вы также можете заглянуть в asp.net поставщик членства.

0

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

0