Глава 20. Аутентификация клиентского приложения
Содержание
- 20.1. Файл
pg_hba.conf- 20.2. Файл сопоставления имён пользователей
- 20.3. Методы аутентификации
- 20.4. Аутентификация trust
- 20.5. Аутентификация password
- 20.6. Аутентификация GSSAPI
- 20.7. Аутентификация SSPI
- 20.8. Аутентификация ident
- 20.9. Аутентификация peer
- 20.10. Аутентификация LDAP
- 20.11. Аутентификация RADIUS
- 20.12. Аутентификация по сертификату
- 20.13. Аутентификация PAM
- 20.14. Аутентификация BSD
- 20.15. Авторизация/аутентификация по OAuth
- 20.16. Проблемы аутентификации
- 20.2. Файл сопоставления имён пользователей
При подключении к серверу базы данных, клиентское приложение указывает имя пользователя Postgres Pro, так же как и при обычном входе пользователя на компьютер с ОС Unix. При работе в среде SQL по имени пользователя определяется, какие у него есть права доступа к объектам базы данных (подробнее это описывается в Главе 21). Следовательно, важно указать на этом этапе, к каким базам пользователь имеет право подключиться.
Примечание
Как можно узнать из Главы 21, Postgres Pro управляет правами и привилегиями, используя так называемые «роли». В этой главе под пользователем мы подразумеваем «роль с привилегией LOGIN».
Аутентификация это процесс идентификации клиента сервером базы данных, а также определение того, может ли клиентское приложение (или пользователь запустивший приложение) подключиться с указанным именем пользователя.
Postgres Pro предлагает несколько различных методов аутентификации клиентов. Метод аутентификации конкретного клиентского соединения может основываться на адресе компьютера клиента, имени базы данных, имени пользователя.
Имена пользователей базы данных Postgres Pro не имеют прямой связи с пользователями операционной системы на которой запущен сервер. Если у всех пользователей базы данных заведена учётная запись в операционной системе сервера, то имеет смысл назначить им точно такие же имена для входа в Postgres Pro. Однако сервер, принимающий удалённые подключения, может иметь большое количество пользователей базы данных, у которых нет учётной записи в ОС. В таких случаях не требуется соответствие между именами пользователей базы данных и именами пользователей операционной системы.
Chapter 20. Client Authentication
Table of Contents
- 20.1. The
pg_hba.confFile- 20.2. User Name Maps
- 20.3. Authentication Methods
- 20.4. Trust Authentication
- 20.5. Password Authentication
- 20.6. GSSAPI Authentication
- 20.7. SSPI Authentication
- 20.8. Ident Authentication
- 20.9. Peer Authentication
- 20.10. LDAP Authentication
- 20.11. RADIUS Authentication
- 20.12. Certificate Authentication
- 20.13. PAM Authentication
- 20.14. BSD Authentication
- 20.15. OAuth Authorization/Authentication
- 20.16. Authentication Problems
- 20.2. User Name Maps
When a client application connects to the database server, it specifies which Postgres Pro database user name it wants to connect as, much the same way one logs into a Unix computer as a particular user. Within the SQL environment the active database user name determines access privileges to database objects — see Chapter 21 for more information. Therefore, it is essential to restrict which database users can connect.
Note
As explained in Chapter 21, Postgres Pro actually does privilege management in terms of “roles”. In this chapter, we consistently use database user to mean “role with the LOGIN privilege”.
Authentication is the process by which the database server establishes the identity of the client, and by extension determines whether the client application (or the user who runs the client application) is permitted to connect with the database user name that was requested.
Postgres Pro offers a number of different client authentication methods. The method used to authenticate a particular client connection can be selected on the basis of (client) host address, database, and user.
Postgres Pro database user names are logically separate from user names of the operating system in which the server runs. If all the users of a particular server also have accounts on the server's machine, it makes sense to assign database user names that match their operating system user names. However, a server that accepts remote connections might have many database users who have no local operating system account, and in such cases there need be no connection between database user names and OS user names.
