Що означає "Користувач не повинен приймати рішення про те, чи це Адміністратор чи ні. Привілеї чи система безпеки повинні ".

Приклад, використаний у запитанні, передає мінімальну кількість даних щодо функції, що стосується найкращого способу визначення того, користувач є адміністратором чи ні. Одна поширена відповідь:

user.isAdmin()

Це підштовхнуло коментар, який повторювався кілька разів і багато разів голосувався:

Користувач не повинен вирішувати, чи це Адміністратор чи ні. Привілеї чи система безпеки повинні. Що те, що щільно поєднане з класом, не означає, що це гарна ідея зробити його частиною цього класу.

Я відповів,

Користувач нічого не вирішує. Об'єкт / таблиця користувача зберігає дані про кожного користувача. Фактичні користувачі не можуть змінити все про себе.

Але це не було результативним. Очевидно, що існує основна різниця в точці зору, яка ускладнює спілкування. Чи може хтось мені пояснити, чому user.isAdmin () поганий, і намалював короткий ескіз того, що це виглядає як зроблено "правильно"?

Дійсно, я не бачу переваги відокремлення безпеки від системи, яку вона захищає. Будь-який текст безпеки говорить про те, що безпеку потрібно розробляти в системі з самого початку і розглядати на кожному етапі розвитку, розгортання, обслуговування та навіть до кінця терміну експлуатації. Це не те, що можна затягнути на боці. Але 17 голосів на цей коментар поки що говорять про те, що я пропускаю щось важливе.

Подумайте про Користувача як про ключ, а дозволи - як про значення.

Різні контексти можуть мати різні дозволи для кожного користувача. Оскільки дозволи мають відповідність контексту, вам доведеться змінити користувача для кожного контексту. Тож краще покласти цю логіку десь в іншому місці (наприклад, контекстний клас) і просто шукати дозволи, де це потрібно.

Побічним ефектом є те, що це може зробити вашу систему більш захищеною, оскільки ви не можете забути очистити прапор адміністратора на місцях, де це не актуально.

Цей коментар був погано сформульований.

Справа не в тому, чи "вирішує" об'єкт користувача, чи це адміністратор, пробний користувач, суперпользователь або щось інше або не в чомусь звичайному. Очевидно, вона не вирішує жодної з цих речей, це робить програмна система в цілому, як ви її впровадили. Справа в тому, чи " клас " користувача повинен представляти ролі головного, що представляють його об'єкти, чи це відповідальність іншого класу.

Я б не вирішив сформулювати оригінальний коментар таким чином, як він був написаний, але він визначає потенційно законну проблему.

Зокрема, проблеми, які вимагають розділення ордера, - це автентифікація та авторизація .

Під автентифікацією розуміється процес входу та отримання ідентичності. Це те, як системи знають, хто ви є , і використовуєте їх для таких речей, як персоналізація, право власності на об'єкти тощо.

Авторизація стосується того, що вам дозволено робити , і це (як правило) не визначається тим, хто ви є . Натомість це визначається якоюсь політикою безпеки, наприклад ролями чи дозволами, які не цікавляться такими речами, як ваше ім’я чи електронна адреса.

Ці два можуть змінюватися ортогонально один до одного. Наприклад, ви можете змінити модель аутентифікації, додавши провайдерів OpenID / OpenAuth. І ви можете змінити політику безпеки, додавши нову роль або перейшовши з RBAC на ABAC.

Якщо все це відноситься до одного класу чи абстракції, то ваш код безпеки, який є одним з ваших найважливіших інструментів для зменшення ризику , стає, за іронією долі, високим ризиком.

Я працював із системами, де автентифікація та авторизація були занадто щільно поєднані. В одній системі було дві паралельні бази даних користувачів, кожна для одного типу "ролі". Людина або команда, яка розробила це, очевидно, ніколи не вважали, що один фізичний користувач може бути в обох ролях, або що можуть бути певні дії, спільні для декількох ролей, або що можуть виникнути проблеми зі зіткненнями User ID. Це, безумовно, екстремальний приклад, але працювати з цим було / неймовірно болісно.

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();
}

Він по суті еквівалентний методу Rails before_filter, який надає приклад перевірки цього типу дозволів у реальному світі.

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

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin () передбачає єдине значення "Адміністратор" у кожному контексті системи , що користувач у кожній частині системи є адміністратором.

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

Зазвичай ця ситуація вимагає дослідження вимог. Рідко, якщо коли-небудь, клієнт захоче відносини, які насправді представляє User.isAdmin (), тож я б вагався реалізувати будь-яке таке рішення без уточнення.

Плакат просто мав на увазі інший і складніший дизайн. На мою думку, User.isAdmin()це добре . Навіть якщо ви пізніше представите якусь складну модель дозволів, я бачу мало підстав рухатися User.isAdmin(). Пізніше, можливо, ви захочете розділити клас користувача на об’єкт, що представляє зареєстрованого користувача, і статичний об'єкт, що представляє дані про користувача. А може і не. Збережіть завтра на завтра.

Насправді не проблема ...

Я не бачу проблем з User.isAdmin(). Я, звичайно, вважаю за краще щось подібне PermissionManager.userHasPermission(user, permissions.ADMIN), що в святому імені SRP робить код менш зрозумілим і не додає нічого цінного.

Я думаю, що SRP дещо тлумачиться буквально. Я думаю, що це добре, навіть класу краще мати багатий інтерфейс. SRP просто означає, що об'єкт повинен делегувати колабораторам все, що не підпадає під його єдину відповідальність. Якщо в ролі адміністратора користувача є щось більше, ніж булеве поле, це може дуже добре мати об’єкт користувача делегувати PermissionsManager. Але це не означає, що користувачеві це також не дуже зручна ідея зберегти його isAdminметод. Насправді це означає, що коли ваша програма закінчується з простого на складний, вам потрібно буде змінити код, який використовує об’єкт User. IOW, ваш клієнт не повинен знати, що потрібно насправді, щоб відповісти на запитання, чи є користувач адміністратором чи ні.

... але чому ти насправді хочеш знати?

При цьому мені здається, що вам рідко потрібно знати, чи користувач є адміністратором, крім того, щоб мати можливість відповісти на якесь інше питання, наприклад, чи дозволено користувачеві виконувати якусь конкретну дію, скажімо, як оновлення віджета. Якщо це так, я вважаю за краще використовувати такий метод на Віджеті, як isUpdatableBy(User user):

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

Таким чином віджет несе відповідальність за те, щоб знати, яким критеріям повинно бути задоволено оновлення користувачем, а користувач несе відповідальність за те, чи він адміністратор. Цей дизайн чітко повідомляє про свої наміри та полегшує перехід до більш складної бізнес-логіки, якщо і коли настане цей час.

[Редагувати]

Проблема НЕ маючи User.isAdmin()і використовуючиPermissionManager.userHasPermission(...)

Я думав, що додам свою відповідь, щоб пояснити, чому я віддаю перевагу виклику методу на об’єкті користувача, аніж виклику методу на об'єкт PermissionManager, якщо я хочу знати, чи користувач є адміністратором (чи має роль адміністратора).

Я думаю, що справедливо припустити, що ви завжди будете залежати від класу користувача, де б вам не було задавати питання , це адміністратор цього користувача? Це залежність, якої ви не можете позбутися. Але якщо вам потрібно передати користувачеві інший об'єкт, щоб задати питання про нього, це створює нову залежність від цього об’єкта поверх тієї, яку ви вже маєте у Користувача. Якщо запитання задають багато, це багато місць, де ви створюєте додаткову залежність, і це може бути багато місць, які вам доведеться змінити, якщо цього вимагатиме будь-яка із залежностей.

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

Наполягаючи на відсутності у користувача isAdminметоду, побоюючись створити залежність класу користувача від підсистеми дозволів, на мій погляд, схоже на те, щоб витратити долар, щоб заробити ні копійки. Звичайно, ви уникаєте однієї залежності в класі користувача, але ціною створення її в кожному місці, де вам потрібно задати питання. Не хороший торг.

Ця дискусія нагадала мені допис у блозі Еріка Ліпперта, який був мені відомий у подібній дискусії про дизайн класу, безпеку та правильність.

Чому стільки рамкових класів запечатано?

Зокрема, Ерік піднімає питання:

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 { ... }: такий клас може мати саме той код вище в ньому.) Введення шкідливого бінарного файлу на місце не є звичайним вектором атаки і має набагато більше потенціалу для хаосу, ніж малозрозуміла бібліотека користувачів - тоді знову ж таки, це могла бути помилка Privilege Escalation, яка відкриває двері справжнім шенанігам. Нарешті, якщо зловмисний бінарний або об’єктний об'єкт знайшов свій час у процесі виконання, уявити "Привілей або систему безпеки" замінено аналогічно.

Але враховуючи серце Еріка, якщо ви ввели код користувача у певний тип вразливої ​​системи, можливо, ви просто програли гру.

О, і щоб бути точним для запису, я погоджуюся з постулатом у запитанні: «Користувач не повинен вирішувати, Адмініструє він чи ні. Привілеї або система безпеки повинні. " User.IsAdminМетод - погана ідея, якщо ви запускаєте код у системі, ви не залишаєтесь під 100% контролем коду - замість цього слід робити Permissions.IsAdmin(User user).

Тут проблема:

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

Або ви належним чином налаштували свою безпеку, і в цьому випадку привілейований метод повинен перевірити, чи має абонент достатньо повноважень - у такому випадку перевірка є зайвою. Або ви не маєте і довіряєте непривілейованому класу, щоб приймати власні рішення щодо безпеки.