Должны ли проблемы безопасности присутствовать в модели предметной области?

Question

Я работаю над проектом Winforms (.NET 4), который свободно основан на MVVM. В целях безопасности приложение проходит проверку подлинности в Active Directory, а затем использует безопасность на основе ролей для определения разрешений на доступ к различным частям программы. Безопасность реализована с использованием атрибута PrincipalPermissionAttribute в большинстве мест, например:

<PrincipalPermissionAttribute(SecurityAction.Demand, Role:="Managers")> _
Public Sub Save() Implements IProductsViewModel.Save
    mUOW.Commit()
End Sub

Как вы, вероятно, можете сказать из реализации интерфейса, этот конкретный Sub находится в ViewModel. PrincipalPermissionAttribute проверяет, находится ли текущий пользователь (Thread.CurrentPrincipal) в роли диспетчера.

Что приводит к моему вопросу: следует ли проводить проверки безопасности (такие как выше) в модели предметной области?

У меня есть два противоречивых мнения, когда я думаю об этом сам:

1) Держите модель предметной области в неведении о многих других проблемах, чтобы уменьшить сложность и зависимость. (Сохраняйте безопасность, возможно, реализовано во ViewModel).

2) Модель предметной области, в некотором смысле, является местом, где «доллар здесь останавливается». Если я реализую безопасность в доменной модели, то я знаю, что даже если безопасность на другом уровне не срабатывает, доменная модель должна его поймать.

Итак, что вы скажете, безопасность в доменной модели или нет?

Answer 1

Существует 2 вида безопасности.

Тот, который является чисто техническим - что-то вроде «весь трафик должен проходить через https» или «только конкретная служба должна касаться базы данных» или «только конкретный процесс должен иметь возможность касаться файловой системы / реестра».

Второй, связанный с доменом. Что-то вроде «только пользователь с ролью Секретаря может получить доступ к истории платежей» или «Неавторизованные пользователи не должны иметь доступ к учетным данным».

Первый должен быть отделен от домена. Второй должен жить внутри домена.

Answer 2

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

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

Кроме того, предположим, что требование изменяется, тогда как кто-то в другой роли может теперь выполнить ту же операцию. Сохранение их всех на уровне сервиса означает, что вы также не меняете код, который должен реже обрабатываться. По крайней мере, в том, что я сделал, положительный вывод заключается в том, что чем ближе к ядру вы получаете, тем меньше вероятность изменения кода. Это означает, что вы также уменьшите изменение своего изменения, чтобы оно стало «волноваться» в других областях, которые вы не намеревались.

Что касается более широкой проблемы и ничего личного, мне не нравится идея добавления доступа к данным любого вида во ViewModel. ViewModel предназначен для представления модели, специфичной для реализации. Эти объекты должны быть в идеале максимально легкими. Например, если в продукт вносится изменение, оно будет проходить через службу, а затем в хранилище, где оно может быть зарегистрировано в единице работы, ожидая принятия.