Что означает «пользователь не должен решать, является ли он администратором или нет. Привилегии или Система безопасности должны ».

В примере, использованном в этом вопросе, передается минимальное количество данных для функции, которая помогает определить, является ли пользователь администратором или нет. Один общий ответ был:

user.isAdmin()

Это побудило комментарий, который был повторен несколько раз и проголосовал много раз:

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

Я ответил,

Пользователь ничего не решает. Пользовательский объект / таблица хранит данные о каждом пользователе. Реальные пользователи не могут ничего изменить в себе.

Но это не было продуктивным. Ясно, что есть принципиальное различие во взглядах, которое затрудняет общение Может кто-нибудь объяснить мне, почему user.isAdmin () плохой, и нарисовать краткий набросок того, как это выглядит «правильно»?

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

Думайте о Пользователе как о ключе, а о разрешениях как о значении.

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

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

Этот комментарий был плохо сформулирован.

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

Я бы не стал называть исходный комментарий так, как он был сформулирован, но он идентифицирует потенциально законную проблему.

В частности, проблемы, которые требуют разделения, - это аутентификация и авторизация .

Аутентификация относится к процессу входа в систему и получения личности. Это то, как системы узнают, кто вы , и используются для таких вещей, как персонализация, владение объектами и т. Д.

Авторизация относится к тому, что вам разрешено делать , и это (как правило) не определяется тем, кто вы есть . Вместо этого это определяется некоторой политикой безопасности, например ролями или разрешениями, которые не заботятся о таких вещах, как ваше имя или адрес электронной почты.

Эти два могут меняться ортогонально друг к другу. Например, вы можете изменить модель аутентификации, добавив поставщиков OpenID / OpenAuth. И вы можете изменить политику безопасности, добавив новую роль или сменив RBAC на ABAC.

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

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

Microsoft и Sun / Oracle (Java) называют совокупность информации об аутентификации и авторизации как принципала безопасности . Это не идеально, но работает достаточно хорошо. В .NET, к примеру, у вас есть IPrincipal, что инкапсулируетIIdentity - бывшую ЯВЛЯЮЩУЮСЯ политика (авторизация) объект , а последняя является идентичностью (аутентификация). Можно обоснованно ставить под сомнение решение поставить один внутри другого, но главное в том , что большая часть кода вы пишете будет только для одного из абстракций , который означает , что это легко проверить и реорганизовать.

Нет ничего плохого в User.IsAdminполе ... если только нет User.Nameполя. Это может указывать на то, что концепция «Пользователь» не определена должным образом, и, к сожалению, это очень распространенная ошибка среди разработчиков, которые немного не понимают, когда речь заходит о безопасности. Как правило, единственной вещью, которая должна совместно использоваться идентификаторами и политиками, является идентификатор пользователя, который, не случайно, является именно тем, как он реализован в моделях безопасности Windows и * nix.

Вполне допустимо создавать объекты-оболочки, которые инкапсулируют как идентичность, так и политику. Например, это облегчит создание экрана панели мониторинга, на котором вам необходимо отобразить «привет» сообщение в дополнение к различным виджетам или ссылкам, к которым у текущего пользователя есть доступ. Пока эта обертка просто оборачивает идентификационную информацию и информацию о политике и не претендует на владение ею. Другими словами, до тех пор, пока он не будет представлен как совокупный корень .

Упрощенная модель безопасности всегда кажется хорошей идеей, когда вы впервые разрабатываете новое приложение, из-за YAGNI и тому подобного, но она почти всегда заканчивается тем, что позже вас кусает, потому что, к удивлению, добавляются новые функции!

Итак, если вы знаете, что лучше для вас, вы будете хранить информацию об аутентификации и авторизации отдельно. Даже если «авторизация» прямо сейчас так же проста, как флаг «IsAdmin», вам все равно будет лучше, если он не входит в тот же класс или таблицу, что и информация аутентификации, так что если и когда ваша политика безопасности должна изменить, вам не нужно делать реконструктивные операции в ваших системах аутентификации, которая уже работает нормально.

Ну, по крайней мере, это нарушает принцип единой ответственности . Если бы произошли изменения (несколько уровней администратора, еще больше разных ролей?), Такой дизайн был бы довольно грязным и ужасным в обслуживании.

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

Я думаю, что проблема, возможно, плохо сформулированная, состоит в том, что это придает слишком большой вес Userклассу. Нет, проблема не связана с наличием метода User.isAdmin(), как было предложено в этих комментариях. В конце концов, если кто-то достаточно глубоко в вашем коде вводит вредоносный код для одного из ваших основных классов, у вас есть серьезные проблемы. С другой стороны, не имеет смысла Userрешать, является ли он администратором для каждого контекста. Представьте, что вы добавляете разные роли: модераторы для вашего форума, редакторы, которые могут публиковать посты на главной странице, авторы, которые могут писать контент для публикации в редакторах, и так далее. С подходом размещения его на Userобъекте вы получите слишком много методов и слишком много логики, живущей на том, Userчто не имеет прямого отношения к классу.

Вместо этого вы можете использовать перечисление различных типов разрешений и PermissionsManagerкласс. Возможно, у вас может быть такой метод, как PermissionsManager.userHasPermission(User, Permission)возвращение логического значения. На практике это может выглядеть так (в Java):

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

По сути, это эквивалентно методу before_filterметода Rails , который предоставляет пример такой проверки прав доступа в реальном мире.

Object.isX () используется для представления четкой связи между объектом и X, которая может быть выражена как логический результат, например:

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin () предполагает единственное значение «Администратор» в каждом контексте системы , что пользователь в каждой части системы является администратором.

Хотя это звучит достаточно просто, реальная программа почти никогда не будет соответствовать этой модели, но наверняка для пользователя будет требоваться администрирование ресурса [X], а не [Y], или для администраторов более различных типов (проект [проект] ] администратор против [системного] администратора).

Эта ситуация обычно требует изучения требований. Редко, если когда-либо, клиент захочет отношения, которые фактически представляет User.isAdmin (), поэтому я не решался бы реализовать любое такое решение без разъяснения.

Плакат просто имел в виду другой и более сложный дизайн. На мой взгляд, User.isAdmin()все в порядке . Даже если вы позже представите некоторую сложную модель разрешений, я не вижу особых причин для этого User.isAdmin(). Позже вы можете разделить класс User на объект, представляющий вошедшего в систему пользователя, и статический объект, представляющий данные о пользователе. Или вы не можете. Сохранить завтра на завтра.

Не действительно проблема ...

Я не вижу проблемы с User.isAdmin(). Я, конечно, предпочитаю что-то вроде этого PermissionManager.userHasPermission(user, permissions.ADMIN), что во святое имя SRP делает код менее понятным и не добавляет ничего ценного.

Я думаю, что SRP интерпретируется немного буквально некоторыми. Я думаю, что это хорошо, даже предпочтительнее для класса иметь богатый интерфейс. SRP просто означает, что объект должен делегировать сотрудникам все, что не попадает под его единственную ответственность. Если роль администратора пользователя является чем-то более сложным, чем логическое поле, вполне может иметь смысл делегировать объекту пользователя объект PermissionsManager. Но это не значит, что для пользователя не стоит также придерживаться своего isAdminметода. Фактически это означает, что когда ваше приложение переходит от простого к сложному, вам нужно изменить код, который использует объект User. Итак, вашему клиенту не нужно знать, что на самом деле требуется, чтобы ответить на вопрос, является ли пользователь администратором.

... но почему вы действительно хотите знать?

Тем не менее, мне кажется, что вам редко нужно знать, является ли пользователь администратором, кроме как для того, чтобы ответить на какой-то другой вопрос, например, разрешено ли пользователю выполнять какое-то конкретное действие, например, обновить виджет. Если это так, я бы предпочел иметь метод на Widget, например isUpdatableBy(User user):

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

Таким образом, виджет отвечает за знание того, какие критерии должны быть выполнены, чтобы пользователь обновлял его, а пользователь отвечает за знание, является ли он администратором. Этот дизайн четко сообщает о своих намерениях и облегчает переход к более сложной бизнес-логике, если и когда придет такое время.

[Редактировать]

Проблема не имея User.isAdmin()и используяPermissionManager.userHasPermission(...)

Я решил добавить свой ответ, чтобы объяснить, почему я предпочитаю вызывать метод объекта User, а не метод метода PermissionManager, если я хочу узнать, является ли пользователь администратором (или имеет роль администратора).

Я думаю, будет справедливо предположить, что вы всегда будете зависеть от класса User, где бы вам ни хотелось задать вопрос, является ли этот пользователь администратором? Это зависимость, от которой вы не можете избавиться. Но если вам нужно передать пользователя другому объекту, чтобы задать вопрос об этом, это создаст новую зависимость от этого объекта поверх того, который у вас уже есть у пользователя. Если вопрос часто задают, это много мест, где вы создаете дополнительную зависимость, и есть много мест, которые вам, возможно, придется изменить, если того требует любая из зависимостей.

Сравните это с перемещением зависимости в класс User. Теперь, внезапно, у вас есть система, в которой клиентский код (код, который должен задать вопрос - это пользователь-администратор ) не связан с реализацией того, как на этот вопрос получают ответ. Вы можете полностью изменить систему разрешений, и вам нужно всего лишь обновить один метод в одном классе, чтобы сделать это. Весь код клиента остается прежним.

Настаивать на том, чтобы isAdminу пользователя не было метода из-за боязни создать зависимость в классе User от подсистемы разрешений, на мой взгляд, все равно, что тратить доллар на копейки. Конечно, вы избегаете одной зависимости в классе User, но за счет ее создания в каждом месте, где вам нужно задать вопрос. Не выгодная сделка.

Эта дискуссия напомнила мне пост в блоге Эрика Липперта, на который мне обратили внимание в аналогичной дискуссии о дизайне класса, безопасности и корректности.

Почему так много базовых классов запечатаны?

В частности, Эрик поднимает вопрос:

4) Безопасный. весь смысл полиморфизма в том, что вы можете передавать объекты, похожие на животных, но на самом деле это жирафы. Здесь есть потенциальные проблемы с безопасностью.

Каждый раз, когда вы реализуете метод, который принимает экземпляр незапечатанного типа, вы ДОЛЖНЫ написать этот метод, который будет устойчивым перед лицом потенциально враждебных экземпляров этого типа. Вы не можете полагаться на любые инварианты, которые, как вы знаете, верны для ВАШИХ реализаций, потому что некоторые враждебные веб-страницы могут создавать подклассы для вашей реализации, переопределять виртуальные методы, чтобы делать вещи, которые портят вашу логику и передают ее. Каждый раз, когда я опечатываю класс Я могу написать методы, которые используют этот класс с уверенностью, что я знаю, что делает этот класс.

Это может показаться касательным, но я думаю, что это соответствует точке зрения других авторов о принципе единоличной ответственности SOLID . Рассмотрите следующий вредоносный класс как причину, чтобы не реализовывать метод или свойство.User.IsAdmin

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

Конечно, это немного натянуто: еще никто не предлагал создать IsAmdminвиртуальный метод, но это может произойти, если ваша архитектура пользователя / роли окажется странно сложной. (Или, возможно, нет. Учтите public class Admin : User { ... }: в таком классе может быть точно такой же код, что и выше.) Установка вредоносного двоичного файла не является распространенным вектором атаки и имеет гораздо больший потенциал для хаоса, чем неясная пользовательская библиотека - опять же, это Это может быть ошибка повышения привилегий, которая открывает дверь настоящим махинациям. Наконец, если вредоносный бинарный или объектный экземпляр попал во время выполнения, не так уж сложно представить, что «Система привилегий или безопасности» будет заменена подобным образом.

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

Да, и если быть точным для записи, я согласен с постулатом в вопросе: «Пользователь не должен решать, является ли он администратором или нет. Система привилегий или безопасности должна ». User.IsAdminМетод - плохая идея, если вы выполняете код в системе, вы не контролируете код на 100% - вы должны вместо этого делать это Permissions.IsAdmin(User user).

Проблема здесь в следующем:

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

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