лучшая практика для реализации разрешений в системе?

Question

У меня есть приложение, которое содержит различные виды разрешений. Как упомянуто в (Role Bases Security) RBC , я сгруппировал пользователей по ролям и назначил различные разрешения ролям. (и разрешения в этом стиле:

public enum Permission {
     View = 1,
     Create =2,
     Edit =4,
     Delete =8,
     Print = 16
}

в простых системах все нормально, но когда система становится немного сложной, в систему приходят специальные разрешения, такие как:

• Просмотр только Его выставленных счетов
• Просмотреть все счета
• Редактировать просто Его Выставленные счета
• Редактировать все счета
• Создать счет на продажу
• Создать счет на покупку
• Создать Проформу
• Создать отчет о продажах по собственным счетам
• Создание ежедневного отчета о продажах
• Создать ежемесячный отчет о продажах -....

Как видите, в системе возникает разного рода разрешения (может увеличиться до 200 разных разрешений). Итак, проблемы:

• Я не могу поместить их все в одно перечисление . тогда использование двоичного шаблона (1,2,4,8, ..) не может быть использовано, поскольку в лучшем случае (int64) он поддерживает до 64 различных разрешений.
• большое перечисление (около 200 элементов) не так хорошо в кодировании

каковы ваши идеи в этом случае?

заранее спасибо: -)

Answer 1

Похоже, вам нужен уровень косвенности ...

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

Предположим, "Джейн" пытается просмотреть счет-фактуру. Тогда вам просто нужно проверить: есть ли у Джейн роль, у которой есть доступ View к какой-то категории, членом которой является этот счет?

Эта проверка может быть медленной, так как вам нужно проверить все роли Джейн по всем категориям счета. Но, по-видимому, вы можете кэшировать результат ... Или вы можете использовать подход, основанный на возможностях, где Джейн запрашивает у менеджера безопасности указатель (указатель) на счет с доступом View. Менеджер безопасности выполняет проверку и передает Джейн дескриптор, после чего она может использовать этот дескриптор для выполнения любых операций просмотра, которые поддерживает дескриптор, без дополнительных проверок безопасности.

Answer 2

Я согласен с Николь: похоже, вы выполняете то, что могло показаться хорошей оптимизацией, но у вас возникают проблемы с масштабированием.

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

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

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

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

Чтобы избежать комбинаторного взрыва разрешений, заранее разработайте сильную логику - запишите ее - и убедитесь, что вы охватили все свои базы.Если вы видите необходимость создания новых динамических разрешений, например, когда в вашу систему добавляются новые сущности, тогда следите - лучше это сделать с помощью шаблона посредника или менеджера, который может проверить ваши бизнес-правила перед выдачей защищенныхюридическое лицо.Здесь вы вступаете в сферу библиотек, таких как Drools, которые служат для представления бизнес-логики из вашего приложения, чтобы ее можно было обновлять в соответствии с меняющимися бизнес-требованиями.

Answer 3

Я не уверен, почему вы чувствуете, что вам нужно попытаться объединить все разрешения в единый флаг (или, как я понял из vales) перечисления.Запросы и разрешения могут быть представлены с использованием списков, а не одного значения ORed.Если вы используете подход списка, вы можете свободно создавать любое представление разрешения, которое вам нравится.Например, вы можете использовать перечисление без флагов или даже несколько перечислений для представления ваших разрешений.