F.33. oauth_validator — Базовый валидатор токенов OAuth 2.0 для Tantor SE#

F.33. oauth_validator — Базовый валидатор токенов OAuth 2.0 для Tantor SE
F.33. oauth_validator — Базовый валидатор токенов OAuth 2.0 для Tantor SE
Назад НаверхПриложение F. Дополнительные поставляемые модули и расширенияНачало Далее

F.33. oauth_validator — Базовый валидатор токенов OAuth 2.0 для Tantor SE #

F.33.1. Обзор
F.33.2. Требования
F.33.3. Установка
F.33.4. Конфигурация
F.33.5. Логика проверки токена
F.33.6. Расширяемость

Версия: 1.0

F.33.1. Обзор #

Этот модуль реализует простой валидатор токенов OAuth 2.0 для встроенной поддержки потока авторизации устройства. Валидатор выполняет минимальную проверку, путем:

  • Извлечение полей sub (subject) и scope из полезной нагрузки JWT.

  • Сравнение областей действия токена с теми, которые требуются записью pg_hba.conf.

  • Сопоставление идентификатора аутентификации sub с ролью базы данных с использованием pg_ident.conf.

  • Разрешение или запрет доступа на основе сопоставления sub и области.

F.33.2. Требования #

  • Tantor SE версии 18 или выше, сконфигурированный с флагом --with-libcurl.

F.33.3. Установка #

  1. Добавьте валидатор в postgresql.conf, используя настройку oauth_validator_libraries: 

    oauth_validator_libraries='oauth_validator'

  2. Настройте файл pg_ident.conf. Например: 

    # MAPNAME    SYSTEM-USERNAME                           PG-USERNAME
oauthmap    "7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee"     "mydbuser"

  3. Настройте файл pg_hba.conf. Например: 

    local    all    all    oauth issuer="https://<address>/.well-known/openid-configuration" scope="openid postgres" map="oauthmap"

F.33.4. Конфигурация #

  • postgresql.conf должен содержать модуль валидатора в записи oauth_validator_libraries.

  • pg_hba.conf должен указывать oauth в качестве метода аутентификации и определять oauth_scope.

  • pg_ident.conf должен содержать сопоставления между значениями JWT sub и ролями Tantor SE.

F.33.4.1. Пример записи в pg_ident.conf #

# MAPNAME    SYSTEM-USERNAME                           PG-USERNAME
oauthmap    "7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee"     "mydbuser"

Если токен содержит значение sub “7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee”, и проверка проходит успешно, Tantor SE сопоставит его с ролью mydbuser с помощью записи oauthmap.

F.33.4.2. Пример записи в pg_hba.conf #

local    all    all    oauth issuer="https://<address>/.well-known/openid-configuration" scope="openid postgres" map="oauthmap"

F.33.5. Логика проверки токена #

Основная логика проверки реализована через функцию validate_token. Она выполняет следующие шаги:

  1. Анализ полезной нагрузки токена: Строка необработанного токена анализируется для извлечения его полезной нагрузки. Если токен имеет неверный формат или полезная нагрузка не может быть извлечена, проверка завершается неудачей.

  2. Извлечение утверждений JWT: Полезная нагрузка должна содержать оба:

    • sub: Субъект (используется для идентификации пользователя)

    • scope: Разделенный пробелами список областей, предоставленных токеном

    Если любое из полей отсутствует, проверка завершается неудачей.

  3. Сравнение областей: Области из записи oauth_scope в pg_hba.conf сравниваются с областями, предоставленными токеном. Если некоторые отсутствуют в токене, проверка завершается неудачей.

    В приведенном выше примере конфигурации проверка будет успешной, если токен содержит оба скоупа: openid и postgres.

  4. Установка результата авторизации: Флаг res->authorized устанавливается в true, если области совпадают; в противном случае он устанавливается в false.

  5. Назначение идентификационной информации для аутентификации: Значение sub присваивается res->authn_id, которое Tantor SE использует для идентификации аутентифицированного пользователя.

  6. Отображение идентификации аутентификации: Это значение sub затем сопоставляется вне этого модуля с записями в pg_ident.conf для определения фактической роли базы данных, которую пользователь имеет право принять.

    Если сопоставление не удается, проверка не проходит.

  7. В противном случае проверка проходит успешно, и клиент авторизован и успешно подключен к базе данных.

F.33.6. Расширяемость #

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

  • Проверка подписей токенов

  • Проверка истечения срока действия токена (exp)

  • Проверка аудитории (aud) или издателя (iss)

  • Динамическое получение ролей пользователя

Назад Наверх Далее
F.32. mchar — дополнительные типы данных для совместимости с Microsoft SQL Server (MS SQL) Начало F.34. online_analyze — сбор статистики сразу после INSERT/UPDATE/DELETE/SELECT