|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.131 2010/02/03 17:25:05 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.132 2010/02/20 19:21:14 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="client-authentication">
|
4 | 4 | <title>Client Authentication</title>
|
@@ -824,23 +824,28 @@ omicron bryanh guest1
|
824 | 824 | The following configuration options are supported for <productname>GSSAPI</productname>:
|
825 | 825 | <variablelist>
|
826 | 826 | <varlistentry>
|
827 |
| - <term><literal>map</literal></term> |
| 827 | + <term><literal>include_realm</literal></term> |
828 | 828 | <listitem>
|
829 | 829 | <para>
|
830 |
| - Allows for mapping between system and database usernames. See |
831 |
| - <xref linkend="auth-username-maps"> for details. |
| 830 | + If set to <literal>1</>, the realm name from the authenticated user |
| 831 | + principal is included in the system user name that's passed through |
| 832 | + username mapping (<xref linkend="auth-username-maps">). This is |
| 833 | + useful for handling users from multiple realms. |
832 | 834 | </para>
|
833 | 835 | </listitem>
|
834 | 836 | </varlistentry>
|
835 | 837 |
|
836 | 838 | <varlistentry>
|
837 |
| - <term><literal>include_realm</literal></term> |
| 839 | + <term><literal>map</literal></term> |
838 | 840 | <listitem>
|
839 | 841 | <para>
|
840 |
| - If set to <literal>1</>, the realm name from the authenticated user |
841 |
| - principal is included in the system user name that's passed through |
842 |
| - username mapping (<xref linkend="auth-username-maps">). This is |
843 |
| - useful for handling users from multiple realms. |
| 842 | + Allows for mapping between system and database usernames. See |
| 843 | + <xref linkend="auth-username-maps"> for details. For a Kerboros |
| 844 | + principal <literal>username/hostbased@EXAMPLE.COM</literal>, the |
| 845 | + username used for mapping is <literal>username/hostbased</literal> |
| 846 | + if <literal>include_realm</literal> is disabled, and |
| 847 | + <literal>username/hostbased@EXAMPLE.COM</literal> if |
| 848 | + <literal>include_realm</literal> is enabled. |
844 | 849 | </para>
|
845 | 850 | </listitem>
|
846 | 851 | </varlistentry>
|
@@ -1027,10 +1032,10 @@ omicron bryanh guest1
|
1027 | 1032 | <para>
|
1028 | 1033 | When connecting to the database make sure you have a ticket for a
|
1029 | 1034 | principal matching the requested database user name. For example, for
|
1030 |
| - database user name <literal>fred</>, both principal |
1031 |
| - <literal>fred@EXAMPLE.COM</> and |
1032 |
| - <literal>fred/users.example.com@EXAMPLE.COM</> could be used to |
1033 |
| - authenticate to the database server. |
| 1035 | + database user name <literal>fred</>, principal |
| 1036 | + <literal>fred@EXAMPLE.COM</> would be able to connect. To also allow |
| 1037 | + principle <literal>fred/users.example.com@EXAMPLE.COM</>, use a username |
| 1038 | + map, as described in <xref linkend="auth-username-maps">. |
1034 | 1039 | </para>
|
1035 | 1040 |
|
1036 | 1041 | <para>
|
|
0 commit comments