авторизации PostgreSQL с ODBC Access связанных таблиц

Question

Для нетерпеливых - я могу резюмировать этот вопрос как:

Какой практический подход может быть использован для привлечения на основе ролей привилегий в PostgreSQL при использовании Access Front End, что использует ODBC-связанные таблицы?

И теперь для более полной версии:

Я унаследовал неприятную задачу модернизации доступа 2000/PG 7 приложения Access 2013/PG 9. Я новичок в PostgreSQL, но использовал Oracle и Microsoft Access довольно немного.
EDIT: на рабочем сервере работает PostgreSQL на Mac OS X Lion. Мой тест машина работает PostgreSQL на Oracle Linux 7.

Это Access БД ссылки на таблицы в базе данных PG через ODBC, соединяясь с использованием одного PG входом роли (application_user). Каждый пользователь подключается к этой учетной записи, и только условия в Формах/VBA ограничивают права пользователя. Если, однако, пользователь может попасть в навигационную панель - они могут напрямую обращаться к связанным таблицам и обойти все ограничения безопасности. Во время обновления этой базы данных я хотел бы посмотреть, смогу ли я ее затянуть.

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

Глядя на потребности безопасности базы данных - я могу думать только о пяти ролях, которые понадобятся.

• Order Entry
• запись клиента
• Заказ и запись клиента
• не только для чтения
• Не авторизован - Нет доступа

я могу настроить их как групповые роли в PGSQL и каждая таблица с необходимым ACL для каждой роли.

Что мне не хватает, так как я могу перейти от единственной логин-роли (application_user) ко всем перечисленным выше ролям?

Моя первая мысль была установить application_user (роль входа в систему) не имеют роли групп (в основном в результате «Не Авторизованный - Нет доступа»), а затем использовать вызов функции PL/PgSQL authorize(Username, MD5PassWord), чтобы разрешить и поднять роль. Функция проверяет, соответствует ли поставленный MD5 хэш хеш MD5, хранящийся в таблице пользователей, и если это так - он выдаст SET SESSION ROLE для соответствующей роли группы.
Если это сработает, это позволит мне отслеживать имена пользователей, которые входят в систему, а затем использовать функцию pg_backend_pid(), я могу связать ее с пользователем для бизнес-логики или ведения журнала или что-то еще.Это также означает, что мне не нужно беспокоиться, если какой-либо пользователь входит в связанную таблицу, потому что их доступ будет ограничен какой-либо ролью, которую они в настоящее время разрешают в этом сеансе базы данных.

Итак, я взломал сценарий plpgsql, установил его владельца OrderCustomerEntryGroup и дал ему SECURITY DEFINER прав.

DECLARE 
    v_Status integer; 
BEGIN 
    v_Status := 0; 
    IF pin_username = 'username' AND MD5('foo') = pin_pwmd5 THEN 
     SET SESSION AUTHORIZATION OrderEntryGroup; 
     v_Status := 1; 
    END IF; 
    RETURN v_Status; 
END; 

только проблема, однако, с моей реализации является то, что

SELECT authenticate('username',MD5('foo')); 

дает:

ERROR: cannot set parameter "session_authorization" within security-definer function 
SQL state: 42501 
Context: SQL statement "SET SESSION AUTHORIZATION OrderEntryGroup" 
PL/pgSQL function authenticate(character varying,text) line 7 at SQL statement 

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

Так что я спрашиваю .. Что мне не хватает, чтобы сделать свой подход (простое решение) работы, или есть лучший способ сделать это, что не будет включать в себя разорвана существующий доступ к базе данных?

Answer 1

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

Если вам не нужно настраивать отдельные идентификаторы пользователей/пароли для каждого пользователя сети, вам следует исследовать с помощью интегрированной проверки подлинности Windows (SSPI), как описано в другом вопросе here. Вам все равно необходимо определить пользователей (в дополнение к группам/ролям) на уровне базы данных, но вам все равно придется выполнять большую часть этой работы.