Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Розділ 19. Аутентифікація клієнта.
Коли клієнтський додаток з’єднується з сервером бази даних, він задає, котрий із користувачів бази даних хоче зєднатися, так само, як при вході в систему Unix, як окремий користувач. Всередині середовища SQL активний користувач бази даних визначає привілеї доступу до об’єктів бази даних - більше про це в Розділі 20. Тому важливо задати, які користувачі можуть встановлювати зєднання.
Зауваження: Як пояснюється в Розділі 20, PostgreSQL працює з управління привілеями, відштовхуючись від ролей. В цій частині, ми сприймаємо користувача бази даних як роль привілеєм LOGIN.
Аутентифікація – це процес яким сервер бази даних встановлює ідентичність клієнта і визначає, чи клієнтські додатки (або користувач) можуть з’єднуватись за допомогою заданого імені користувача.
PostgreSQL пропонує декілька різних методів аутентифікації. Метод, що використовується для аутентифікації окремого клієнтського зєднання може вибиратись на базі адреси хоста, бази даних і користувача.
Імена користувачів бази даних PostgreSQL логічно відєднані від імен користувачів операційної системи, на якій запускається сервер. Якщо всі користувачі одного сервера мають облікові записи на серверній машині, можна присвоїти користувачам БД імена, що відповідають записам операційної системи. Але сервер, що приймає віддалені зєднання може мати багато користувачів бази даних, які не мають локального облікового запису, що вимагає не з’єднувати імена користувачів БД та ОС.
19.1. файл pg_hba.conf
Аутентифікація клієнта контролюється файлом конфігурації, який зазвичай називається pg_hba.conf і зберігається в каталозі даних кластера. (HBA заснований на ідентифікації хоста). По замовчуванню цей файл встановлюється, коли каталог даних ініціалізується в initdb. Можливо встановлювати цей файл будь-де, дивіться параметр hba_file.
Загальний формат файлу pg_hba.conf – це набір записів, один на рядок. Пусті рядки ігноруються, як і будь- який текст після #. Записи не можна розділяти на декілька рядків. Запис формується із деякого числа полів, які роз’єднані пробілами і табуляціями. Поля можуть містити пусте місце, якщо їх значення взяте в апострофи. Взяті в апострофи ключові слова стають звичайними змінними.
Кожний запис задає тип зєднання, ранг ІР-адреси клієнта, імя бази даних, імя користувача, і метод аутентифікації, що використовується для зєднання з цими параметрам. Перший запис використовується для забезпечення аутентифікації. Нема проходження чи відновлення – якщо запис вибрано, а уатентифікація не вдалась, решта запитів недоступні. Якщо нема співпадінь, доступ заборонено.
Запис може мати один із семи форматів
local database user auth-method [auth-options]
host database user CIDR-address auth-method [auth-options]
hostssl database user CIDR-address auth-method [auth-options]
hostnossl database user CIDR-address auth-method [auth-options]
host database user IP-address IP-mask auth-method [auth-options]
hostssl database user IP-address IP-mask auth-method [auth-options]
hostnossl database user IP-address IP-mask auth-method [auth-options]
Значення цих полів:
local
відповідає спробі зєднань з використанням сокетів домена Unix. Без запису цього типу, подібні зєднання не будуть дозволені.
host
Відповідає зєднанням через TCP/IP. Відповідає і SSL і нешифрованим спробам зєднання.
Зауваження: віддалені зєднання TCP/IP не будуть можливими, поки сервер не запущено з відповідним значенням параметра listen_addresses, оскільки по замовчуванню там тільки localhost.
hostssl
Відповідяє зєднанню через TCP/IP, але тільки з використанням SSL. Щоб використовувати цю опцію, сервер має бути побудований з підтримкою SSL. SSL має бути включений при запуску сервера, встановленням параметра SSL( більше в розділі 17.8).
hostnossl
Протилежний hostssl – всі зєднання, що не використовують SSL.
database
Задає відповідну базу даних. Значення all визначає відповідність всім базам даних. Параметр sameuser задає, що запис відповідає, якщо база даних має імя таке ж ,як у користувача. Значення samerole задає, що користувач маж бути членом заданої ролі, з імям, як у бази даних. Значення replication задає, що запис співпадає, якщо запитується зєднання реплікації. ( вони не задають окрему базу). Це імя специфічної бази даних. Багато імен можуть також задаватись через кому. Може також задаватись окремий файл з іменами бази даних, якщо йому передує @.
user
Задає відповідні імена користувачів бази даних. Значення all задає всіх користувачів. Це може бути імя користувача, або групи, якому передує +. (+ задає вимогу до ролей і всіх відповідних під ролей, тоді як просто імя задає окрему роль). Багато імен можуть також задаватись через кому. Може також задаватись окремий файл з іменами користувачів, якщо йому передує @.
CIDR-address
Задає ранг адресу клієнтської машини, що відповідає цьому запису. Це поле містить ІР-адресу в стандартному десятковому форматі і довжину маски CIDR (ІР адреси можуть бути задані тільки цифрами, не як імена хоста чи домена). Довжина маски показує число бітів вищого порядку клієнської адреси, що мають співпадати. Біти справа мають бути нульовими в заданих ІР адресах. Між адресою, слешем і довжиною маски не має бути пробілів.
Замість CIDR-address, ви можете написати samehost для встановлення власних ІР-адрес сервера, або samenet щоб додати адресу з будь-якох підмережі, до якої зєднаний сервер.
Типовими прикладами адрес є 172.20.143.89/32 для одного хоста, або 172.20.143.0/24 для малої мережі, або 10.6.0.0/16 для більшої. 0.0.0.0/0 представляє всі адреси. Для задання окремого хоста, використовуйте маску 32 для IPv4 або 128 для IPv6. В адресі мережі не упускайте нулів.
Адреса подана в форматі IPv4 буде відповідати IPv6 зєднанням, що мають відповідну адресу, для прикладу 127.0.0.1 відповідатиме адресі ::ffff:127.0.0.1. Формат IPv6 буду відповідати тільки зєднанням IPv6, навіть якщо дана адреса має ранг IPv4-in-IPv6. Зауважте, що бібліотека С не підтримує адреси IPv6. Це поле відноситься до host, hostssl, і hostnossl.
IP-address
IP-mask
Ці поля можуть використовуватись як альтернатива до CIDR-address. Замість задання довжини маски, маска задається в окремому стовпці. Для прикладу 255.0.0.0 представляє довжину маски IPv4 CIDR 8, а 255.255.255.255 задає довжину маски 32.
Ці поля стосуються тільки записів host, hostssl, і hostnossl.
auth-method
Задає метод аутентифікації для використання, коли зєднання відповідає запису. Можливими варіантами є подані нижче. Детальніше в розділі 19.3.
Trust
Дозволяє безумовне зєднання. Цей метод дозволяє будь-кому, хто підключенється до сервера бази даних PostgreSQL входити під будь-яким користувачем без пароля або іншої аутентифікації. Дивіться 19.3.1 для детальної інформації.
Reject
Відкидає зєднання. Це корисно для фільтрування деяких хостів з групи, наприклад рядок reject блокує окремих хост від зєднання, тоді як в настуних рядках задаються дозволи іншим хостам.
md5
Вимагає від клієнта підтримки шифрування пароля MD5. Дивіться розділ 19.3.2.
Password
Вимагає клієнта ввести нешифрований пароль для аутентифікації. Оскільки він пересилається по мережі в нешифрованому вигляді, це не може використовуватись у недовірених мережах. Дивіться розділ 19.3.2
Gss
Використовує GSSAPI для аутентифікації. Це доступно тільки для зєднань TCP/IP. Дивіться розділ 19.3.3
Sspi
Використовує SSPI для аутентифікації користувача. Доступне тільки на Windows. Дивіться розділ 19.3.4 для деталей.
krb5
Використовує Kerberos V5 для аутентифікації. Достуне тільки для зєднань TCP/IP. Дивіться розділ 19.3.5.
Ident
Співставляє імя користувача операційної системи (для зєднань TCP/IP контактування з сервером ident на клієнті, для локальних зєднань для отримання його з операційної системи) і перевіряє, чи воно співпадає іменем користувача операційної системи. Дивіться розділ 19.3.6.
Ldap
Аутентифікація через LDAP. Дивіться розділ 19.3.7
Radius
Аутентифікація через RADIUS. Дивіться розділ 19.3.8
Cert
Аутентифікація з використанням сертифікатів SSL. Дивіться розділ 19.3.9
Pam
Аутентифікація з використанням Pluggable AuthenticationModules (PAM), що забезпечується ОС. Дивіться розділ 19.3.10.
auth-options
Після поля auth-method можуть бути поля форми name=value, що задають опції для методу аутентифікації. Деталі про те, які опції доступні для ідентифікацій різними методами, показані нижче.
Файли, включені конструкцією @ читаються як списки імен, які можуть біти розділені пробілами або комами. Коментарі преставляються через #, як у pg_hba.conf, дозволені вкладені конструкції @. Якщо імя файлу не є абсолютним шляхом, його шукають в каталозі, де знаходиться файл посилання.
Оскільки записи pg_hba.conf перевіряються при спробі зєднання. Порядок записів має значення. Типово, раніші записи мають вужчі відповідаючі параметри і слабші методи аутентифікації, тоді як пізніші мають ширші параметри і сильніші методи. Для прикладу, можна використовувати аутентифікацію trust для локальних зєднань TCP/IP, але вимагати пароль для віддалених зєднань TCP/IP. В цьому випадку запис задає аутентифікацію trust для зєднань з 127.0.0.1, і він передує загальному запиту, що задає аутентифікацію з паролем для дозволених ІР-адрес.
Файл pg_hba.conf читається при запуску і коли головний процес сервера отримує сигнал SIGHUP. Якщо ви змінюєте файл на активній системі, ви можете захотіти дати сигнал постмастеру (через pg_ctl reload або kill –HUP) щоб перечитати файл.
Підказка: для зєднання з окремою базою даних, користувач має не тільки пройти pg_hba.conf, але і мати привілей CONNECT для бази даних. Якщо ви хочете обмежити коло користувачів, що мають зєднуватись з базою даних, простіше здійснити цей контроль наданням або забиранням привілею CONNECT, а не правилами входу в pg_hba.conf.
Деякі приклади входів у pg_hba.conf показані в прикладі 19-1. Дивіться наступний розділ для деталей різних методів аутентифікації.
Example 19-1. Example pg_hba.conf entries
# Allow any user on the local system to connect to any database with
# any database user name using Unix-domain sockets (the default for local
# connections).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local all all trust
# The same using local loopback TCP/IP connections.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 127.0.0.1/32 trust
# The same as the previous line, but using a separate netmask column
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 127.0.0.1 255.255.255.255 trust
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Allow any user from host 192.168.12.10 to connect to database
# "postgres" if the user’s password is correctly supplied.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.12.10/32 md5
# In the absence of preceding "host" lines, these two lines will
# reject all connections from 192.168.54.1 (since that entry will be
# matched first), but allow Kerberos 5 connections from anywhere else
# on the Internet. The zero mask causes no bits of the host IP
# address to be considered, so it matches any host.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 krb5
# Allow users from 192.168.x.x hosts to connect to any database, if
# they pass the ident check. If, for example, ident says the user is
# "bryanh" and he requests to connect as PostgreSQL user "guest1", the
# connection is allowed if there is an entry in pg_ident.conf for map
# "omicron" that says "bryanh" is allowed to connect as "guest1".
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.0.0/16 ident map=omicron
# If these are the only three lines for local connections, they will
# allow local users to connect only to their own databases (databases
# with the same name as their database user name) except for administrators
# and members of role "support", who can connect to all databases. The file
# $PGDATA/admins contains a list of names of administrators. Passwords
# are required in all cases.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local sameuser all md5
local all @admins md5
local all +support md5
# The last two lines above can be combined into a single line:
local all @admins,+support md5
# The database column can also use lists and file names:
local db1,db2,@demodbs all
19.2.Карти користувачів.
Коли ви використовуєте зовнішню систему аутентифікації, як Ident або GSSAPI, імя користувача операційної системи, який ініціював зєднання має біти не таким же, як імя користувача бази даних, що зєднується. В цьому випадку карта користувачів співставляється з картою користувачів ОС до користувачів БД. Для використання карти користувачів, задайте map=map-name в полі опцій pg_hba.conf. Ця опція підтримується для всіх методів аутентифікації що отримують зовнішні імена користувачів. Оскільки потрібні різні карти для різних зєднань, назва карти, що використовується, задається в параметрі map-name в pg_hba.conf щоб показати, котра з карт використовується в цьому зжднанні.
Карти користувачів визначені в файлі карт, яким по замовчуванню є pg_ident.conf, що зберігається в каталозі даних кластера. (Можливо його помістити в інше місце, дивіться параметр ident_file). Файл карт містить рядки загальної форми
map-name system-username database-username
Коментарі і путсе місце читаються так само, як і в pg_hba.conf. map-name це імя, що використовується для посилання до цієї карти в pg_hba.conf. Інші два поля задають імя користувача ОС і відповідне імя користувача БД. Таке ж map-name використовується для задання декількох керувать користувачем в одній карті.
Нема обмежень на кількість користувачів БД, яким відповідає один користувач ОС. Тому входження в карту мають сприйматись як «цей користувач ОС може зєднуватись як цей користувач БД», а не сприймаючи їх як еквівалентні. Зєднання буде дозволено, якщо є входження в карту, що співставляє імя користувача з зовнішньої системи аутентифікації з іменем користувача бази даних, під яким заходить даний користувач.
Якщо system-username посинається із слеша, решта поля сприймається як реулярний вираз. (дивіться секцію 9.7.3.1 для деталей регулярного синтаксису). Регулярний вираз може включати один вираз, або підвираз, що посилається на поле database-username як \1. Це дозволяє управління декількома іменами одночасно, що досить зручно для простих замін синтаксису. Для прикладу, ці записи:
mymap /^(.*)@mydomain\.com$ \1
mymap /^(.*)@otherdomain\.com$ guest
Будуть видаляти частину домена для користувачів з іменами, що закінчуються на @mydomain.com і дозволяти будь-якому користувачу, чиє імя закінчується на @otherdomain.com заходити як гість.
Підказка: памятайте, що по замовчуванню, регулярний вираз може відповідати тільки частині рядка. Зазвичай розумно використовувати ^ і $, як показується вище, щоб примусити співпадіння бути користувачем системи входу.
Файл pg_ident.conf читається при запуску і коли серверний процес отримує сигнал SIGHUP. Якщо ви редагуєте файл активно системи, дайте сигнал постмастеру (використовуючи pg_ctl reload або kill –HUP), щоб перечитати файл.
Файл pg_ident.conf, що використовується як додаток до pg_hba.conf в прикладі 19-1, показано в прикладі 19-2. В цьому прикладі, кожен, що зайшов на машину в мережі 192.168 що не має імен користувачів ОС bryanh, ann, або robert, може отримати доступ. Користувач Unix robert отримає доступ, якщо він спробує зайти як користувач PostgreSQL bob, а не як robert чи хтось інший. Ann може зайти тільки як ann. Користувач bryanh може зєднатись тільки як bryanhor або guest1.
Example 19-2. An example pg_ident.conffile
# MAPNAME SYSTEM-USERNAME PG-USERNAME
omicron bryanh bryanh
omicron ann ann
# bob has user name robert on these machines
omicron robert bob
# bryanh can also connect as guest1
omicron bryanh guest1
Методи аутентифікації.
Наступні підрозділи описують методи аутентифікації більш детально.
19.3.1. Аутентифікація Trust
Коли задається такий тип аутентифікації, PostgreSQL знає, що кожен, хто може зєднатись до сервера, авторизується для доступу до бази даних, яке би імя користувача вони не задали (навіть суперкористувача). Звичайно, обмеження колонок database і user мають вплив. Цей метод використовується тільки при відповідному захисті операційною системою подібних зєднань.
Аутентифікація trust є дуже зручною для локальних зєднань для робочої станції з одним користуачем. Вона не є хорошим рішенням для машини з багатьмя користувачами. Але ви можете використовувати trust на багатокористувацькій машині, якщо ви можете обмежити доступ до сокета домену Unix через дозволи файлової системи. Щоб зробити це, встановіть unix_socket_permissions (і unix_socket_group), як описано в секції 18.3. Або ви можете встановити параметр конфігурації unix_socket_directory, щоб помістити файл сокета в відподіний обмежений каталог.
Встановлення обмежень файлової системи допомагає тільки для зєднань Unix-socket. Локальні зєднання TCP/IP не обмежуються дозволами файлової системи. Якщо ви хочете використовувати ці дозволи для локального захисту, видаліть рядок host ... 127.0.0.1 ... з pg_hba.conf, або змініть на метод ідентифікації відмінний від trust.
Аутентифікація –trust застосовується для зєднань TCP/IP, якщо ви довіряєте кожному користувачу кожної машини, яким дозволено зєднуватись з сервером через рядки pg_hba.conf, що задають trust. Нерозумно використовувати trust для зєднань звідкись крім локалхосту (127.0.0.1).
19.3.2. Аутентифікація з паролем.
Базовані на паролі методи - md5 і password. Ці методи працюють одиноково, окрім виду, в якому пересилається пароль, шифрований в MD5, або чистим текстом відповідно.
Якщо ви знаєте про атаки перехвату паролю, рекомендовано md5. Звичайний password має по можливості уникатись. Але md5 не може використовуватись з опцією db_user_namespace. Якщо зєднання захищене шифруванням SSL, тоді password може безпечно використовуватись (оскільки сертифікат SSL є кращим рішенням).
Паролі баз даних PostgreSQL відрізняються від паролів користувачів ОС. Пароль кожної бази даних зберігається в системному каталозі pg_authid. Паролями можна управляти через команди CREATEUSER і ALTERUSER, наприклад CREATE USER foo WITH PASSWORD ’secret’. Якщо не задається пароль, то збережений пароль буде нульовим, а аутентифікація для цього користувача ніколи не буде вдалою.
19.3.3. аутентифікація GSSAPI
GSSAPI це протокол промислового стандарту для захисту аутентифікації, заданої в RFC2743. PostgreSQL підтримує GSSAPI з Kerberos згідно RFC1964. GSSAPI забезпечує автоматичну аутентифікацію для систем, що її підтримують. Сама аутентифікація безпечна, але дані, що пересилаються, не шифруються, якщо не використовується SSL.
Коли GSSAPI використовує Kerberos, воно використовує стандартний запис в форматі servicename/hostname@realm. Для інформації про частини запису і як встановлювати ключі, дивіться розділ 19.3.5.
Пітримка GSSAPI має бути включена при побудові PostgreSQL (Розділ 15).
Наступні опції підтримуються для GSSAPI:
include_realm
Якщо встановлено в 1, імя області з запису аутентифікованого користувача включається в імя користувача системи, що проходить управління іменами (19.2). Це корисно для роботи з користувачами з декількома областями.
Map
Дозволяє співставлення між іменами користувачів ОС і БД. Дивіться розділ 19.2. для запису Kerberos username/hostbased@EXAMPLE.COM, імя користувача, що використовується – це username/hostbased, якщо include_realm відключено, і username/hostbased@EXAMPLE.COM якщо include_realm включено.
krb_realm
Задає область для співставлення з іменами користувача. Якщо цей параметр встановлено, тільки користувачі цієї області будуть прийняті. Якщо ні, то зєднуватись можуть користувачі будь-якої області.
19.3.4. Аутентифікація SSPI.
Це технологія Віндовс для захисту аутентифікацій. PostgreSQL використовує SSPI в режимі negotiate, що використовує коли можливо Kerberos і звертається до NTLM в інших випадках. SSPI працює тільки, коли і клієнт і сервер працюють з Віндовс.
Коли використовується аутентифікація Kerberos, SSPI працює так само, як GSSAPI, дивіться розділ 19.3.3.
Пітримуються настуні опції
include_realm
Якщо встановлено в 1, імя області з запису аутентифікованого користувача включається в імя користувача системи, що проходить управління іменами (19.2). Це корисно для роботи з користувачами з декількома областями.
Map
Дозволяє співставлення між іменами користувачів ОС і БД. Дивіться розділ 19.2. krb_realm
Задає область для співставлення з іменами користувача. Якщо цей параметр встановлено, тільки користувачі цієї області будуть прийняті. Якщо ні, то зєднуватись можуть користувачі будь-якої області.
19.3.5. Аутентифікація Kerberos
Зауваження: Рідна аутентифікація Kerberos використовується тільки для зворотньої сумісності. Нові установки використовують стандартний метод GSSAPI (Розділ 19.3.3).
Kerberos це промисловий стандарт захисту аутентифікацій, призначений для розподілених обчилень в загальних мережах. Опис системи поза темою цього документу. Це досить складна штука, якщо брати в загальному. Для дослідження починайте з Kerberos FAQ або MIT Kerberos. Є декілька джерел дистрибутивів Kerberos. Kerberos забезпечує захист аутентифікації але не шифрує дані і запити в мережі. Для цього використовуйте SSL.
PostgreSQL підтримує версію 5 Kerberos. При побудові слід включити підтримку Kerberos (розділ 15).
PostgreSQL працює як нормальна служба Kerberos. Імя запису сервісу - servicename/hostname@realm.
Servicename може задаватись на сервері використанням параметру конфігурації krb_srvname і на клієнтській стороні використанням параметра krbsrvname (дивіться розділ 31.1). Значення по замовчуванню можна змінити з postgres під час побудови, використовуючи ./configure --with-krb-srvnam=whatever. В більшості середовищ, цей параметр не треба міняти. Але це необхідно для підримки деклькох інсталяцій PostgreSQL на одному хостів. Деякі виконання Kerberos можуть також вимагати інше імя служби, наприклад Microsoft Active Dіrectory, яке вимагає імя в верхньому регістрі (POSTGRES).
hostname це повністю задане імя хоста на серверній машині. Область служби буде пріоритетною областю серверної машини.
Записи клієнтів мають мати імені користувачів бази даних як перший компонент, наприклад pgusername@realm. Замість цього ви можете використати управління картою для першого компонента для записів імен як імен користувачів БД. По замовчуванню область клієнта не перевіряється. Якщо ми маєте міжобласну аутентифікацію і хочете взани область, використовуйте параметр krb_realm, або включіть include_realm і використовуйте імена для перевірки областей.
Впевніться, що файл ключів сервера читабельний з акаунту сервера PostgreSQL (розділ 17.1). Розміщення файлу ключів задається параметром /usr/local/pgsql/etc/krb5.keytab або каталогом, заданим як sysconfdir підчас побудови).
Цей файл генерується Kerberos, детальніше про це в документації Kerberos. Ось приклад МІТ-сумісного виконання Kerberos 5:
kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
Коли зєднуєтесь з базою даних, пересвідчіться, що ви маєте квиток для співпадіння з відповідним користувачем бази даних.
Для прикладу, для бази даних fred, запис fred@EXAMPLE.COM може зєднуватись. Щоб дозволити ззапис fred/users.example.com@EXAMPLE.COM, використовуйте карту імен користувачів, як описано в Розділі 19.2.
Якщо ви використовуєте mod_auth_kerb і mod_perl на вашому веб-сервері Apache ви можете використовувати AuthType KerberosV5SaveCredentials зі скриптом mod_perl. Це дає захист дотсупу до бази даних через веб, без додаткових паролів.
Настуні опції підтримуються Kerberos:
Map
Дозволяє співсталення користувачів ОС та БД. Дивіться розділ 19.2.
include_realm
Якщо встановлено в 1, імя області з запису аутентифікованого користувача включається в імя користувача системи, що проходить управління іменами (19.2). Це корисно для роботи з користувачами з декількома областями.
krb_realm
Задає область для співставлення з іменами користувача. Якщо цей параметр встановлено, тільки користувачі цієї області будуть прийняті. Якщо ні, то зєднуватись можуть користувачі будь-якої області.
krb_server_hostname
Задає частину імені хочта в запиті. Це в комбінації з krb_srvname, використовується для генерації повного запису служби, krb_srvname/krb_server_hostname@REALM. Якщо не задано, по замовчуванню це імя хоста сервера.
19.3.6. Ident-based аутентифікація.
Метод аутентифікації ident працює використанням імені користувача ОС як імені користувача бази даних (з можливим співставленням). Визнаначення імені користувача клієнта – це важлива для захисту критична точка, і працює вона по різному в залежності від типу зєднання, як показано нижче. Потримується опція map, що дозволяє співставлення імен користувачів ОС і БД. Дивіться розділ 19.2.
19.3.6.1. Аутентифікація Ident через TCP/IP.
“Identification Protocol” описується в RFC 1413. Віртуально кожна операційна система, подібна до Unix працює з сервером ident що прослуховує по замовчуванню 113 порт ТСР. Простою функцією цього сервера є запитання «Який користувач ініціював зєднання, що йде з вашого порта Х до мого порта У?». оскільки PostgreSQL має ці значення після встановлення фізичного зєднання, він теоретично може визначити, який з користувачів використовує дане зєднання.
Недолік цієї системи є в тому, що він залежить від інтеграції клієнта. Якщо машина клієнта не є довіреною, хакер може тільки запустити будь-яку програму на 113 портів і взяти будь-яке імя користувача. Цей метод ефективний тільки для закритих мереж, де кожна машина знаходиться під контрлем і де база даних працює з адміністраторами в тісному контакті. Ішими словами, ви вірите машині, що запускає сервер ident. Подивіться на попередження:
The IdentificationProtocol is not intended as an authorization or access control protocol.
—RFC1413
Деякі сервери ident мають нестандартну властивість, що дозволяє повернутому імені бути зашифрованим, з використанням ключа, який знає тільки адміністратор даної машини. Ця опція не має використовуватись з PostgreSQL, оскільки PostgreSQL не має способів дешифрувати цей пароль і визначити імя користувача.
19.3.6.2. Аутентифікація Ident через локальні сокети.
На системах, що підтримують запити SO_PEERCRED для сокетів домена Юнікс (наприклад Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS, і Solaris), аутентифікація ident може використовуватись для локальни зєднань. PostgreSQL використовує SO_PEERCRED для знаходження імені користувача ОС підєднаного процесу клієнта. В цьому випадку, не має ніякого ризику, більше того це хороший вибір для локальних зєднань в цих системах.
На системах без запитів SO_PEERCRED аутентифікація iden доступна тільки для зєднань TCP/IP. Як вирішення, можливо задати адресу локалхоста і зробити зєднання по цій адресі. Цей метод вимагає довіри локальному серверу ident.
19.3.7. Аутентифікація LDAP
Цей метод аутентифікації працює так само, як password крім того, що він використовує LDAP як метод підтвердження паролю. LDAP використовується для співставлення пар користувач-пароль. Тому користувач, що існував в базі до LDAP може використовувати цей метод.
LDAP може працювати в двох режимах. В першому, сервер буде привязуватись до імені, побудованої як prefix username suffix. Типово параметр prefix використовується для задання cn=, або DOMAIN\ в середовищі Active Directory. Suffix використовується для задання решти частини DN в середовищі не ActiveDirectory.
В другому режимі, сервер спочатку привязує каталог LDAP до фіксованого імені та пароля, заданого ldapbinduser і ldapbinddn, і виконує пошук користувача, що пробує ввійти в базу. Якщо немає такої конфігурації, буде викоирстовуватись анонімна привязка. Пошук робиться по піддереву ldapbasedn, і саробує знайти відповідність атрибуту, заданому в ldapsearchattribute. Якщо нема атрибута, сервер відєднується і перевривязується до каталога як користувач, використовуючи пароль клієнта, щоб пересвідчитись, що логін коректний. Цей метод дозволяє значно більшу гнучкість для перевірки коректності логіна, але буде спричиняти два різних зєднання до сервера LDAP.
Наступні опції підтримуються LDAP:
Ldapserver
Імя або IP сервера LDAP.
Ldapport
Номер порта, до якого треба зєднуватись. Якщо не заданий, використовується занчення по замовчуванню із бібліотеки LDAP
Ldaptls
Встановлення в 1 шифрує зєднання між серверами PostgreSQL і LDAP через TLS. Це шифрує тільки трафік до сервера LDAP – зєднання з клієнтом не буде шифрованим, якщо ви не використовуєте SSL.
Ldapprefix
Рядок для формування імені DN, до якого привязуються при простій аутентифікації
Ldapsuffix
Рядок для формування імені DN, до якого привязуються при простій аутентифікації
Ldapbasedn
Кореневий DN для пошуку користувача при другому способі аутентифікації.
Ldapbinddn
DN користувача для звязування з каталогом при другому способі аутентифікації.
Ldapbindpasswd
Пароль для користувача звязування з каталогом при другому способі аутентифікації.
Ldapsearchattribute
Атрибут для співстарення в пошуку при другому способі аутентифікації.
Зауваження: оскільки LDAP часто використовує коми і пробіли для відділення різних частин DN, необхідно задавати параметри в лапках при конфігурації LDAP, наприклад
ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
19.3.8. Аутентифікація RADIUS
Цей метод аутентифікації працює так само, як і password за виключенням того, що він використовує RADIUS для підтвертження аутентифікації. RADIUS використовується для встановлення пар імя користувача – пароль. Тому користувач, що існував в базі до RADIUS може аутентифікуватись.
Під час аутентифікації RADIUS, на сервер RADIUS відсилається повідомлення AccessRequest. Цей запит буде типу Authenticate Only, і включатиме параметри для user name, password (шифрований) і NAS Identifier. Запит буде шифрований через пароль на сервера. Сервер відповість цьому серверу Access Accept або Access Reject. Нема підтримки облікових записів RADIUS.
Опції, що пітримуються RADIUS:
Radiusserver
Імя або ІР-адреса сервера RADIUS. Цей парметр обовязковий.
Radiussecret
Ключ загального доступу, для роботи з сервером RADIUS. Він має мати одинакове значення для серверів PostgreSQL і RADIUS. Рекомендовано, щоб його довжина була від 16 символів і більше. Цей параметр вимагається.
Зауваження: цей напрям шифрування буде досить стійким, якщо сервер будувався з підтримкою OpenSSL. В інших випадких, передача буде незахищеною і мають бути прийняті міри зовнішнього захисту.
Radiusport
Порт, до якого потрібно підєднуватись на сервері RADIUS, якщо не задано, використовується значення 1812.
Radiusidentifier
Рядок, що використовується як NAS Identifier для потреб RADIUS. Цей параметр використовується як другий параметр ідентифікації, для прикладу, до якого користувача БД підключається даний користувач, що може використовуватись в правилах відповідності сервера RADIUS. Якщо не задано, по замовчуванню буде викристовуватись postgresql.
19.3.9. Аутентифікація з сертифікатом.
Цей спосіб використовує сертифікати клієнта SSL. Він доступний тільки для зєднань SSL. Коли використовується цей метод, сервер вимагає від клієнта діючий сертифікат. Паролі не потрібні. Атрибут cn (Common Name) буде порівнюватись із іменем користувача БД і якщо вони співпали, вхід буде дозволено. Може використовуватись керування іменами для вибору cn відмінного від імені користувача бази даних.
Наступні опції підтримуються для аутентифікації сертафікатами SSL:
Map
Дозволяє співставлення імен користувачів БД і ОС. Дивіться розділ 19.2 для деталей.
19.3.10. Аутентифікація PAM
Цей метод працює як password за винятком того, що він використовує механізм аутентифікації РАМ. Імя служби по замовчуванню postgresql. РАМ використовується тільки для співставлення пар користувач – пароль. Тому користув, що існував в базі до РАМ, може використовувати цей метод аутентифікації. Для більшої інформації прочитайте Linux-PAM Page і Solaris PAM Page.
Наступні опції підтримуються РАМ:
Pamservice
Імя сервісу РАМ
Зауваження: якщо PAM встановлений з читанням /etc/shadow, аутентифікація не буде проходити, оскільки сервер PostgreSQL запускається не з користувача root. Хоча це не проблема, якщо РАМ використовує LDAP або інші методи аутентифікації.
19.4. Проблеми аутентифікації
Проблеми Аутентифікації супроводжуються подібними повідомленнями:
FATAL: no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"
Це те, що ви отримаєте, якщо ви звязали з сервером, але він не відповідає. Сервер відкинув зєднання, оскільки не знайшов потрібного запису в файлі pg_hba.conf
FATAL: password authentication failed for user "andym"
Повідомлення типу цього показують, що ви звязались з сервером, і він відповір, але ви не пройшли авторизацію. Перевірте парльо або програмне забезпечення Kerberos чи iden, якщо в повідомленні згадується про них.
FATAL: user "andym" does not exist
Такого імені користувача не було знайдено.
FATAL: database "testdb" does not exist
База даних, до якої ви підєднуєтесь, не існує. Подивіться, чи добре ви задали базу даних, що відповідає імені користувача, оскільки швидше за все помилка в цьому.
Підказка: лог сервера може містити більше інформації про невдалі аутентифікації, ніж її надається клієнту. Якщо ви не знаєте в чому причина, перевірте логи сервера.