|
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