Я работаю над большим веб-приложением Java EE с функционалом CRM, и мы ищем подход к безопасности / библиотека / решение / все, что угодно.Базовая защита на основе ролей не будет работать, поскольку управление доступом должно основываться на иерархии ролей и , но при желании их можно настраивать для каждого документа.Поскольку будет храниться конфиденциальная и конфиденциальная информация, необходимо, чтобы система безопасности работала должным образом.
Пример: Чтобы использовать универмаг, можно создать полку сталкеров складеровсообщает, что другие акционеры могут прочитать , только если они находятся в том же отделе.Теперь их менеджер отдела может читать / писать / обновлять / удалять все отчеты, написанные биржевиками, и писать отчеты, которые все другие руководители отделов могут читать, но не видят отчеты менеджеров магазинов и т. Д., Которые районные менеджеры могут отправлять и т.д.Теперь сложности: люди на более высоких уровнях могут сделать вещи видимыми для людей на более низких уровнях, либо для отдельных лиц (отдел пишет документ нескольким конкретным акционерам), либо для пользователей ниже (менеджер магазина пишет памятку всему магазину) или любому другому.перестановка вы можете себе представить.Кроме того, отдельные лица могут создавать отчеты, которые их коллеги не могут видеть, или они могут выбрать предоставление доступа для хранения запасов в других округах и т. Д.
Мы рассматриваем ACL с одним разрешением на организацию, но беспокоимся о большом количествезаписи, которые будут создавать.Даже если бы только отчет был доступен для чтения всем остальным в отделе из 30 человек и каждому человеку над ним [в цепочке команд], создание отдельного отчета потребовало бы ~ 40 записей!С 1 отчетом в неделю на пользователя, что составляет 2000 разрешений на пользователя в год.1 500 пользователей - это более 3 000 000 разрешений в год.
Кажется, что подход на основе правил будет неплохим, но я не видел ни одного блога или статьи, в которых бы упоминался этот подход, поэтому мы сомневаемся в этом.
Мы также рассматриваем некоторый гибрид доморощенного производства ACL / правила, в котором вы могли бы предоставить разрешение для идентификатора отдела с дискриминатором «менеджер» или «кладовщики» и т. Д. Для выбора, но беспокоитесь о том, что проверяете все возможные разрешения.(вы можете получить разрешение специально от другого пользователя, у вас есть разрешение в качестве члена вашего департамента, вы можете получить разрешение в качестве члена магазина или района) звучит как склонный к ошибкам нудный кошмар.
Каков наилучший подход для нашего приложения?