20.6. Аутентификация GSSAPI
GSSAPI — стандартизированный протокол для безопасной аутентификации, определённый в RFC 2743. PostgreSQL поддерживает применение GSSAPI для аутентификации или шифрования соединения, а также для шифрования с аутентификацией. GSSAPI обеспечивает автоматическую проверку подлинности (единый вход) для систем, которые её поддерживают. Проверка подлинности реализуется безопасно, но данные, передаваемые через подключение к БД, будут защищены, только если используется шифрование GSSAPI или SSL.
Поддержка GSSAPI должна быть включена при сборке PostgreSQL; за дополнительными сведениями обратитесь к Главе 16.
При работе с Kerberos GSSAPI использует стандартные имена принципалов служб (аутентификационные идентификаторы) в формате имя_службы/имя_сервера@область
Подключающийся к серверу клиент должен знать имя принципала данного сервера. Обычно в компоненте имя_службы принципала фигурирует postgres, но параметр подключения krbsrvname в libpq позволяет задать и другое значение. В компоненте имя_сервера задаётся полностью определённое имя узла, к которому будет подключаться libpq. В качестве области выбирается предпочитаемая область, заданная в доступных клиенту файлах конфигурации Kerberos.
У клиента также должно быть назначенное ему имя принципала (и он должен иметь действительный билет для этого принципала). Чтобы GSSAPI проверил подлинность клиента, имя принципала клиента должно быть связано с именем пользователя базы PostgreSQL. Определить такие сопоставления можно в файле pg_ident.conf; например, pgusername@realm можно сопоставить с именем pgusername. Также возможно использовать в качестве имени роли в PostgreSQL полное имя принципала username@realm без какого-либо сопоставления.
PostgreSQL также может сопоставлять принципалы клиентов именам пользователей, просто убирая компонент области из имени принципала. Эта возможность оставлена для обратной совместимости, и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm значение 0. В простых конфигурациях с одной областью исключение области в сочетании с параметром krb_realm (который позволяет ограничить область пользователя одним значением, заданным в krb_realm parameter) будет безопасным, но менее гибким вариантом по сравнению с явным описанием сопоставлений в pg_ident.conf.
Размещение файла keytab на сервере задаётся параметром конфигурации krb_server_keyfile. По соображениям безопасности рекомендуется использовать отдельный файл для сервера PostgreSQL, а не разрешать серверу читать системный keytab. Предоставьте пользователю, от имени которого работает сервер PostgreSQL, право чтения этого файла (право записи давать не нужно). (См. также Раздел 18.1.)
Файл таблицы ключей генерируется с использованием ПО Kerberos; подробнее это описано в документации Kerberos. Следующий пример показывает, как его сгенерировать, используя программу kadmin в MIT-совместимой реализации Kerberos 5:
kadmin%addprinc -randkey postgres/server.my.domain.orgkadmin%ktadd -k krb5.keytab postgres/server.my.domain.org
Для метода аутентификации GSSAPI поддерживаются следующие параметры:
include_realmКогда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся
krb_realm. Более предпочтительный вариант — оставить значениеinclude_realmпо умолчанию (1) и задать вpg_ident.confявное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL.mapРазрешает сопоставление принципалов клиентов пользователям баз данных. За подробностями обратитесь к Разделу 20.2. Для принципала GSSAPI/Kerberos, такого как
username@EXAMPLE.COM(или более редкогоusername/hostbased@EXAMPLE.COM), именем пользователя в сопоставлении будетusername@EXAMPLE.COM(илиusername/hostbased@EXAMPLE.COM, соответственно), еслиinclude_realmне равно 0; в противном случае именем системного пользователя в сопоставлении будетusername(илиusername/hostbased).krb_realmУстанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.
В дополнение к этим параметрам, которые могут быть разными в разных записях pg_hba.conf, существует параметр конфигурации krb_caseins_users, действующий на уровне сервера. Если он равен true, принципалы клиентов сопоставляются с записями пользователей без учёта регистра. В значении krb_realm, если оно задано, регистр символов тоже не учитывается.
20.6. GSSAPI Authentication
GSSAPI is an industry-standard protocol for secure authentication defined in RFC 2743. PostgreSQL supports GSSAPI for authentication, communications encryption, or both. GSSAPI provides automatic authentication (single sign-on) for systems that support it. The authentication itself is secure. If GSSAPI encryption or SSL encryption is used, the data sent along the database connection will be encrypted; otherwise, it will not.
GSSAPI support has to be enabled when PostgreSQL is built; see Chapter 16 for more information.
When GSSAPI uses Kerberos, it uses a standard service principal (authentication identity) name in the format servicename/hostname@realm
When connecting, the client must know the principal name of the server it intends to connect to. The servicename part of the principal is ordinarily postgres, but another value can be selected via libpq's krbsrvname connection parameter. The hostname part is the fully qualified host name that libpq is told to connect to. The realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the client.
The client will also have a principal name for its own identity (and it must have a valid ticket for this principal). To use GSSAPI for authentication, the client principal must be associated with a PostgreSQL database user name. The pg_ident.conf configuration file can be used to map principals to user names; for example, pgusername@realm could be mapped to just pgusername. Alternatively, you can use the full username@realm principal as the role name in PostgreSQL without any mapping.
PostgreSQL also supports mapping client principals to user names by just stripping the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set include_realm to 0. For simple single-realm installations, doing that combined with setting the krb_realm parameter (which checks that the principal's realm matches exactly what is in the krb_realm parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping in pg_ident.conf.
The location of the server's keytab file is specified by the krb_server_keyfile configuration parameter. For security reasons, it is recommended to use a separate keytab just for the PostgreSQL server rather than allowing the server to read the system keytab file. Make sure that your server keytab file is readable (and preferably only readable, not writable) by the PostgreSQL server account. (See also Section 18.1.)
The keytab file is generated using the Kerberos software; see the Kerberos documentation for details. The following example shows doing this using the kadmin tool of MIT-compatible Kerberos 5 implementations:
kadmin%addprinc -randkey postgres/server.my.domain.orgkadmin%ktadd -k krb5.keytab postgres/server.my.domain.org
The following authentication options are supported for the GSSAPI authentication method:
include_realmIf set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (Section 20.2). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless
krb_realmis also used. It is recommended to leaveinclude_realmset to the default (1) and to provide an explicit mapping inpg_ident.confto convert principal names to PostgreSQL user names.mapAllows mapping from client principals to database user names. See Section 20.2 for details. For a GSSAPI/Kerberos principal, such as
username@EXAMPLE.COM(or, less commonly,username/hostbased@EXAMPLE.COM), the user name used for mapping isusername@EXAMPLE.COM(orusername/hostbased@EXAMPLE.COM, respectively), unlessinclude_realmhas been set to 0, in which caseusername(orusername/hostbased) is what is seen as the system user name when mapping.krb_realmSets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.
In addition to these settings, which can be different for different pg_hba.conf entries, there is the server-wide krb_caseins_users configuration parameter. If that is set to true, client principals are matched to user map entries case-insensitively. krb_realm, if set, is also matched case-insensitively.
