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

Question

Я пишу приложение depsktop (на Java), которое взаимодействует с базой данных, в которой хранятся в основном документы с требованиями, но у меня есть небольшая дилемма.Конкретно проблема с управлением пользовательским доступом.

Чтобы проиллюстрировать это, я храню все детали структуры папок в одной таблице.Однако я хотел бы создать механизм групп пользователей, аналогичный системам Linux / Unix, где вы можете добавлять / мод / только папки, для которых у вас есть разрешения.Конечно, я могу назначать разрешения базы данных только таблице или столбцам, а не отдельным строкам, представляющим папки, к которым у них есть доступ.

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

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

Последний вариант - триггеры, хотя база данных, которую я должен поддерживать (mysql), не делает этомне легко отказаться.Я также надеялся, учитывая частоту доступа, избежать триггеров из-за дополнительных вычислений и более низкой производительности.

Ни один из них не идеален, но у меня заканчиваются идеи.

Рекомендации?

Answer 1

В PostgreSQL это довольно распространенный подход к вашей дилемме. Хотя я не пробовал это в MySQL, это может стоить рассмотреть.

При этом вполне может быть предпочтительнее управлять этим в вашем приложении, а не в MySQL. Читайте дальше.

<ч />

Вы можете использовать комбинацию permission tables, views и функции user().

Например, скажем, у вас есть таблица с именем Document:

Document_ID | Name | Content
------------+------+--------
1234        | Doc1 | Bla bla
2345        | Doc2 | Bla bla
3456        | Doc3 | Bla bla
------------+------+--------

И у вас была таблица разрешений с именем Document_User.

Document_ID | User
------------+------+--------
1234        | smith@'%'
2345        | smith@'%'
3456        | smith@'%'
1234        | jones@'%'
2345        | jones@'%'
1234        | white@'%'
------------+------+--------

Из приведенной выше структуры очевидно, что User Smith имеет доступ ко всем трем документам, User Jones имеет доступ к первым двум, а User White имеет доступ только к первому.

Наконец, создайте вид, подобный этому:

CREATE VIEW 
SQL SECURITY DEFINER
    `User_Document`
AS
    SELECT *
    FROM `Document`
    WHERE Document_ID IN 
        (SELECT Document_ID FROM Document_User WHERE User = USER())

Текущий вошедший в систему пользователь увидит набор записей в таблице User_Document, которые представляют собой только те записи, которые он имеет право просматривать.

Answer 2

Насколько безопасным должно быть это приложение?

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

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

Answer 3

Не следует связывать права и разрешения БД с правами и разрешениями пользователя. Пользовательский код должен проходить через DAL или сервисный уровень, который реализует функциональность ограничения доступа. Где вы храните информацию о правах, во многом зависит от вашего механизма аутентификации. Если у вас есть существующая система аутентификации пользователей, такая как активный каталог или LDAP, вы можете интегрировать в нее либо аутентификацию и авторизацию, либо интегрировать только аутентификацию и выдавать авторизацию в БД.

По сути, для вашей модели это выглядит так, как будто у вас должна быть таблица для аутентифицированных сущностей, таблицы для пользователей и групп, в которых есть FK, а затем таблица разрешений, которая имеет отношения FK в таблице сущностей auth.

Answer 4

Почему вы не управляете доступом в самом приложении, если вы полагаетесь на rdbms? Вы можете просто сравнить таблицу пользователей с таблицами и уровнями доступа и проконсультироваться с ней перед доступом.