blob: a1a025245ba9536415fc93a4fae2e570b0542cd9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>21.8. Ident Authentication</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="sspi-auth.html" title="21.7. SSPI Authentication" /><link rel="next" href="auth-peer.html" title="21.9. Peer Authentication" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">21.8. Ident Authentication</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="sspi-auth.html" title="21.7. SSPI Authentication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="client-authentication.html" title="Chapter 21. Client Authentication">Up</a></td><th width="60%" align="center">Chapter 21. Client Authentication</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="auth-peer.html" title="21.9. Peer Authentication">Next</a></td></tr></table><hr /></div><div class="sect1" id="AUTH-IDENT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">21.8. Ident Authentication <a href="#AUTH-IDENT" class="id_link">#</a></h2></div></div></div><a id="id-1.6.8.15.2" class="indexterm"></a><p>
The ident authentication method works by obtaining the client's
operating system user name from an ident server and using it as
the allowed database user name (with an optional user name mapping).
This is only supported on TCP/IP connections.
</p><div class="note"><h3 class="title">Note</h3><p>
When ident is specified for a local (non-TCP/IP) connection,
peer authentication (see <a class="xref" href="auth-peer.html" title="21.9. Peer Authentication">Section 21.9</a>) will be
used instead.
</p></div><p>
The following configuration options are supported for <code class="literal">ident</code>:
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">map</code></span></dt><dd><p>
Allows for mapping between system and database user names. See
<a class="xref" href="auth-username-maps.html" title="21.2. User Name Maps">Section 21.2</a> for details.
</p></dd></dl></div><p>
</p><p>
The <span class="quote">“<span class="quote">Identification Protocol</span>”</span> is described in
<a class="ulink" href="https://datatracker.ietf.org/doc/html/rfc1413" target="_top">RFC 1413</a>.
Virtually every Unix-like
operating system ships with an ident server that listens on TCP
port 113 by default. The basic functionality of an ident server
is to answer questions like <span class="quote">“<span class="quote">What user initiated the
connection that goes out of your port <em class="replaceable"><code>X</code></em>
and connects to my port <em class="replaceable"><code>Y</code></em>?</span>”</span>.
Since <span class="productname">PostgreSQL</span> knows both <em class="replaceable"><code>X</code></em> and
<em class="replaceable"><code>Y</code></em> when a physical connection is established, it
can interrogate the ident server on the host of the connecting
client and can theoretically determine the operating system user
for any given connection.
</p><p>
The drawback of this procedure is that it depends on the integrity
of the client: if the client machine is untrusted or compromised,
an attacker could run just about any program on port 113 and
return any user name they choose. This authentication method is
therefore only appropriate for closed networks where each client
machine is under tight control and where the database and system
administrators operate in close contact. In other words, you must
trust the machine running the ident server.
Heed the warning:
</p><div class="blockquote"><table border="0" class="blockquote" style="width: 100%; cellspacing: 0; cellpadding: 0;" summary="Block quote"><tr><td width="10%" valign="top"> </td><td width="80%" valign="top"><p>
The Identification Protocol is not intended as an authorization
or access control protocol.
</p></td><td width="10%" valign="top"> </td></tr><tr><td width="10%" valign="top"> </td><td colspan="2" align="right" valign="top">--<span class="attribution">RFC 1413</span></td></tr></table></div><p>
</p><p>
Some ident servers have a nonstandard option that causes the returned
user name to be encrypted, using a key that only the originating
machine's administrator knows. This option <span class="emphasis"><em>must not</em></span> be
used when using the ident server with <span class="productname">PostgreSQL</span>,
since <span class="productname">PostgreSQL</span> does not have any way to decrypt the
returned string to determine the actual user name.
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="sspi-auth.html" title="21.7. SSPI Authentication">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="client-authentication.html" title="Chapter 21. Client Authentication">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="auth-peer.html" title="21.9. Peer Authentication">Next</a></td></tr><tr><td width="40%" align="left" valign="top">21.7. SSPI Authentication </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 21.9. Peer Authentication</td></tr></table></div></body></html>
|
