-
Notifications
You must be signed in to change notification settings - Fork 1
Authentication and authorization (ru)
Встроенный механизм аутентификации отсутствует. Это объясняется тем, что обычно RDBMS (и PostgreSQL не является исключением) поддерживают внутри себя лишь парольный способ аутентификации ролей, тогда как современные приложения требуют различных способов аутентификации, в том числе сложных многофакторных.
Тем не менее, при вызове методов, помеченных флагом true в поле set_username, выставляются указанные в конфигурации локальные переменные postgres, содержащие login и password, взятые из данных basic access authentication HTTP-сессии JSON-RPC. Содержимое этих локальных переменных может быть использовано для аутентификации и авторизации при исполнении SQL-кода методов.
В случае если флаг set_username выставлен, но данные basic access authentication HTTP-сессии не были переданы генерируется ошибка HTTP 401 (Unauthorized).
Настоятельно не рекомендуется передавать в HTTP-сессии по ненадёжному каналу настоящий пароль пользователя, так как пароль передаётся в открытом виде.
Описанный механизм может быть также использован для передачи в целях авторизации имени уже аутентифицированного другими способами пользователя.
Существует возможность использовать встроенный в СУБД механизм авторизации доступа к элементам схемы БД при помощи выставления роли пользователя, от имени которого исполняется код метода. Этот механизм включается опцией (!!!вписать!!!) конфигурационного файла. При этом для каждого вызова метода с флагом set_username исполнение команд внутри транзакции автоматически предваряется установлением текущей роли директивой:
SET LOCAL ROLE имя_пользователя;
Таким образом, транзакция исполняется с правами роли, название которой передано как имя пользователя HTTP-сессии. ВНИМАНИЕ! Данный механизм не содержит встроенной аутентификации роли! Переданный в HTTP-сессии пароль не проверяется!
Для разделения ролей разных БД обслуживаемых одной СУБД существует возможность указать опциональный префикс имён ролей. Например, переданный через HTTP basic auth логин "user123" при указанном в настройках pgator префиксе "pgator_system1." будет преобразован в роль БД "pgator_system1.user123" и вызовет выполнение такой директивы внутри транзакции метода:
SET LOCAL ROLE "pgator_system1.user123";
Использование префиксов позволяет использовать одинаковые (с точки зрения прикладного софта) имена ролей в разных БД одной СУБД.
Удобно организовать аутентификацию на сайте с помощью «токенов». Токен хранит на стороне клиента информацию об имени пользователя, защищённую от изменения хэшированием логина с использованием известного только серверу секрета. Такой способ аутентификации удобен для пользователей, универсален и существенно снижает нагрузку на БД.
Токены (в разных видах и под разными названиями) реализованы во многих веб-библиотеках, несложно их реализовать и вручную. Но чтобы данный способ работал потребуется создать в таблице методов общедоступный метод аутентификации. Например:
boolean auth.password( login, password ) - аутентификация по логину и паролю, возвращает успешность или не успешность аутентификации
Механизм работы с методом таков: вновь пришедший пользователь сайта вводит свои имя и пароль, они передаются в этот метод, метод проверяет правильность имени и пароля, после чего имя пользователя сохраняется в браузере пользователя (например, в cookie или в web storage) в защищённом от изменения токене.
В дальнейшем при работе с этим пользователем достаточно без каких-либо запросов к БД проверять токен пользователя на валидность и передавать взятое из токена имя пользователя в HTTP-сессию pgator с каждым JSON-RPC запросом. Так БД получает имя аутентифицированного пользователя, которое может быть использовано для авторизации внутри БД любым удобным способом.
В будущем вам будет легко расширить эту схему другими способами аутентификации, например «auth.cert» или «auth.biometrics.retina».