Пользовательский ACL для безопасности на уровне строк

Я видел несколько реализаций ACL на уровне строк, использующих таблицу разрешений, имеющую такую ​​структуру, как

User_Id 
Subject_Class
Subject_Id
Permission_Id

где Permission_Id (Чтение, запись, обновление, удаление, утверждение и т. д.)

Мне было интересно, есть ли какая-либо польза от описания отношения (Relationship_Id) с данными вместо описания разрешения.

Идея, которую мы хотели бы описать, что пользователь является «Владельцем», «Утверждающим», «Рецензентом», «Общедоступным зрителем» и т. д.

Затем это отношение будет определять набор разрешений. Это может уменьшить размер разрешения.

Есть мысли по поводу этой методики?


person Daniel St-Jean    schedule 23.02.2015    source источник


Ответы (1)


Роли, как вы заметили, представляют собой комбинации разрешений. Если у вас есть набор разрешений размера n, у вас может быть 2^n комбинаций всех этих разрешений. Это означает, что если у вас есть 5 разрешений, вам потребуется 32 роли. Если у вас есть 10 разрешений, у вас будет 1024 роли!

Использование маршрута разрешений также кажется более простым для сопровождения — скажем, вы хотите удалить разрешения на доступ для группы пользователей. Вы просто сделаете простой запрос, чтобы удалить строки, которые предоставляют привилегии доступа этим пользователям. Но если бы у вас были роли, вам сначала нужно было бы найти все роли, включающие доступ, удалить их у конкретных пользователей и затем найти все роли, похожие на предыдущую роль каждого пользователя < em>минус разрешение на доступ и назначьте эти роли пользователям. Кажется, много работы.

person Michael Tontchev    schedule 05.05.2015