Контроль доступа к частям системы, а также к определенным частям информации

Question

Это сложный вопрос, мы говорили об этом некоторое время (дни) и не нашли убедительно хорошего решения. Это ситуация:

• У нас есть пользователи и группы. Пользователь может принадлежать ко многим группам (отношение многие ко многим)
• Существуют определенные части сайта, которые требуют контроля доступа, но:
• Существуют определенные ряды определенных таблиц, которые требуют контроля доступа, т.е. определенный пользователь (или определенная группа) не должен иметь возможность удалять определенную строку, но другие строки в той же таблице могут иметь другие настройки разрешений для этого пользователя (или группы)

Есть ли простой способ сделать это? Мы что-то упустили?

Нам нужно реализовать это на python (если это поможет).

Answer 1

Эта проблема не нова; это в основном общая проблема авторизации и прав доступа / контроля.

Чтобы избежать необходимости моделировать и поддерживать полный график того, какие объекты каждый пользователь может получить доступ к каждому возможному способу, вы должны принять решение (на основе того, что делает ваше приложение) о том, как начать царствовать в мультипликативной шкале факторы. Итак, во-первых: где пользователи получают свои права? Если каждому пользователю назначены индивидуальные права, вы столкнетесь с серьезной трудоемкой задачей управления для тех, кто должен добавлять пользователей, изменять пользователей и т. Д.

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

Теперь, как эти права выглядят? Вероятно, по-прежнему нецелесообразно назначать права на целевой объект по объектам. Таким образом, возможно, права следует рассматривать как набор абстрактных «карт доступа». Объекты в системе могут быть помечены как требующие «синего» доступа для чтения, «красного» доступа для обновления и «черного» доступа для удаления. Эти абстрактные права могут быть расположены в некоторой топологии, такой, что наличие «черного» доступа означает, что у вас неявно также есть «красный» и «синий», или, может быть, они все не связаны; Вам решать, как ваше приложение должно работать. (Также обратите внимание, что вам может потребоваться учитывать, что для типов объектов & mdash; таблицы, если вам нравится & mdash; могут понадобиться свои собственные правила доступа, по крайней мере, для "create".

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

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

Answer 2

1) создать таблицу с правами, т.е. удалить, обновить и т. Д.

2) создайте в таблице прав трехстороннюю сводную таблицу, к какой таблице вы хотите получить доступ на уровне строк, и к какой таблице содержится единица прав доступа (группа или пользователь).

3) проверьте связь в сводной таблице, прежде чем разрешить продолжить операцию.

Ваша таблица прав может выглядеть так:

ID   RIGHT
1    DELETE
2    UPDATE

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

ID  TITLE           CONTENT
1   blog entry 1    This is a blog entry
2   blog entry 2    This is another blog entry

и ваша таблица пользователей может быть:

ID   NAME
1    Bob
2    Alice

Тогда сводная таблица будет выглядеть как

ID USER_ID RIGHT_ID BLOG_ID
1  1       2        1
2  2       1        1
3  2       2        1
4  2       1        2
5  2       2        2

Это означает, что Боб может обновлять только запись в блоге 1, но Алиса может обновить или удалить любую запись в блоге

РЕДАКТИРОВАТЬ: Если вы хотите, чтобы право исходило от пользователя или группы, то вам нужны две сводные таблицы для каждой таблицы; один для пользователей и один для групп. Вам также придется запросить базу данных, чтобы проверить права на уровне пользователя и права на уровне группы, прежде чем разрешить или запретить операцию

EDIT2: это сложнее, чем решение Дэвида, но не требует, чтобы вы заранее составляли классы access_classes: вы можете смешивать и сопоставлять любые разрешения на уровне группы и пользователя, которые вы хотите, и это то, что вы хотите сделать.

Answer 3

Добавьте дополнительный столбец «категория» или «тип» к таблице (таблицам), который будет классифицировать строки (или, если хотите, сгруппировать / кластеризовать их) - и затем создать сводную таблицу, которая определяет управление доступом между ( rowCategory, userGroup). Таким образом, для каждой строки по ее категории вы можете определить, какие группы пользователей имеют доступ (и какой тип доступа).

Answer 4

Трудно быть конкретным, не зная больше о вашей настройке и о том, почему именно вам нужно, чтобы разные пользователи имели разные разрешения для разных строк.Но, как правило, я бы сказал, что всякий раз, когда вы обращаетесь к любым данным в базе данных в вашем коде, вам должна предшествовать проверка авторизации, которая проверяет текущего пользователя и группу и вставляемую / обновляемую / удаленную / etc строку.и решает, должна ли операция быть разрешена или нет.Рассмотрите проектирование вашей системы в инкапсулированном виде - например, вы можете поместить все функции, которые непосредственно обращаются к базе данных, в один модуль и убедиться, что каждая из них содержит соответствующую проверку авторизации.(Наличие всех их в одном файле снижает вероятность того, что вы пропустите один файл)

Может быть полезно добавить в таблицу столбец permission_class и создать другую таблицу, в которой указано, какие пользователи или группы имеют какиеклассы разрешений.Тогда ваша проверка авторизации просто должна принять значение класса разрешений для текущей строки и посмотреть, содержит ли таблица разрешений связь между этим классом разрешений и текущим пользователем или какой-либо из его / ее групп.