Блог

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

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

Мой фундаментальный вопрос таков: могу ли я быть в исключительном случае (т. Е. в том, где включение безопасности является разумным) или я не понимаю чего-то фундаментального в абстрагировании безопасности?

Редактировать:

tl; dr (из ответов, насколько я их понимаю): аутентификация (кто вы) является в значительной степени сквозной проблемой и должна быть абстрагирована, тогда как авторизация (что вы можете сделать) — это бизнес-логика. Отсутствие такого словарного запаса и использование только термина «безопасность» (или, возможно, неспособность оценить различие между ними) приводят к моему замешательству.

Безопасность разделена на две части; аутентификация и авторизация. Аутентификация — довольно специфический вариант использования. Как вы определяете, что пользователь является надежным из набора ненадежных пользователей. Я думаю, что это сквозной вопрос; вам нужно не допускать пользователей, не прошедших проверку подлинности, к вашей системе или к подмножеству вашей системы.

Авторизация (может ли пользователь что-то сделать) — это в значительной степени бизнес-правило. Это может быть (и часто бывает) очень специфичным и разным для каждого варианта использования. Кто определяет, какие роли что могут делать? Ну, бизнес делает. Никто другой не может ответить на этот вопрос за вас.

В Csla.Net 4 framework, именно так обрабатывается авторизация; как специализированное бизнес-правило. Вы даже не ограничены «пользователь входит в роль» или «у пользователя есть разрешение». Вы можете создать более сложные правила «пользователь может редактировать это поле, если этап рабочего процесса не прошел этот конкретный этап».

Я полагаю, что исключительным случаем было бы, если бы ваша бизнес-логика представляла СОБОЙ какие-либо службы безопасности, тогда да. Однако я думаю, что ваша проблема может заключаться в том, что вы путаете авторизацию пользователя с аутентификацией.

Конечно, с аутентификацией должен быть связан набор правил, но конечным результатом должна быть идентификация пользователя и создание сеанса.

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

Типичным примером может быть то, что аутентификация возвращает пользовательский объект и сохраняет его в сеансе. Пользователь имеет от 1 до многих ролей. Роль может иметь от 1 до многих привилегий. Методом бизнес-логики может быть SendEmail. Этот метод запрашивает у пользовательского объекта определенную привилегию, если она существует, сделайте что-нибудь, если нет, сделайте что-нибудь еще.

РЕДАКТИРОВАТЬ: Безопасность, на мой взгляд, всегда должна быть сквозной проблемой, когда речь заходит о пользователе, однако, если ваша бизнес-логика включает свойства объектов, которые не являются пользователем, CRUD этих объектов или администрирование других пользователей, тогда это соответствует вашим бизнес-требованиям и, следовательно, является бизнес-логикой.