Я смотрю на реализацию Spring ACL для нашего проекта, который соответствует очень строгим и детальным требованиям безопасности. Я хочу знать, возможен ли определенный сценарий.
На основании документации ACL Spring любой объект (ACL_OBJECT_IDENTY) может быть разрешен для ACL_SID, и в документации говорится о том, что SID является «принципалом», т.е. текущим вошедшим в систему пользователем.
Итак, если у меня есть четыре отдела (D1, D2, D3, D4), назначенных двум менеджерам (M1, M2), где M1 может управлять D1 и D2, а M2 может управлять D3 и D4. Я могу легко реализовать, используя ACL.
Теперь у меня есть сценарий, например, где в отделах есть сотрудники, E1, E2 ... E8 (предположим по два в каждом отделе по порядку ... например, у D4 есть E7 и E8). Сотрудники представляют отчеты R *, и мне нужно защитить доступ для чтения к этим отчетам, чтобы:
1. Сам работник.
2. Руководители отдела работника.
3. Другие сотрудники отдела.
и доступ администратора к этим отчетам:
1. сам работник
2. Заведующие отделом работника.
Даже это возможно благодаря оригинальному пониманию ACL, где «принципал» ограничен пользователем, таким как E * или M *. такие как:
E1, E2.. E8
M1, M2..
и для каждого отчета мы можем создать ACL_ENTRY, например:
R1 read, write to E1 //E1 is author
R1 read, write to M1 //M1 is manager of D1, and E1 belongs to D1
R1 read to E2 //E2 belongs to D1
В этом сценарии я проверю, есть ли у E * или M * доступ к R1.
Все в порядке, но я чувствую, что это может стать слишком сложным для управления (записи ACL), если E входят и выходят из D, или если M добавляются / удаляются для управления D ..
Итак, вопрос таков: могу ли я использовать объект сущности в качестве принципала и использовать его для проверки разрешений, когда необходимо оценить разрешения. Соответственно, могу ли я добавить к ACL_SID следующее:
D1, D2, D3 and D4 //departmetnIds, not usersIds
А затем заменить ACL_ENTRIES на:
R1 read, write to E1 //E1 is author
R1 read to D1 // note D1 here
Таким образом, если я проверяю чтение на наличие E, я проверю, разрешен ли R1 для D.
ИЛИ, если я проверяю, есть ли у E «запись», тогда я могу проверить запись специально для E.
Примечание. Принимая во внимание приведенный выше пример, я знаю, что есть пробел, чтобы увидеть, есть ли у M разрешение на запись. Если мы используем D для разрешения разрешения для R1 вместо самого M, мы будем только получить «read» .. и если мы добавим «write» в ACL_ENTRIES для D, то все остальные E из M также получат «write» (где-как они не должны). Предполагая, что это проблема моего сценария, рассмотрите вопрос на более высоком уровне.
Опять вопрос: Всегда ли основной / SID в ACL_SID всегда должен быть userId / userName или это может быть что-то еще, что может интерпретироваться по-разному.
Заранее спасибо.
М. Скорее