Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E6E10633372 for ; Fri, 23 Oct 2009 16:44:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 52353-02 for ; Fri, 23 Oct 2009 19:44:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from master.nyc.deshaw.com (master.nyc.deshaw.com [149.77.10.1]) by mail.postgresql.org (Postfix) with ESMTP id E2E60633341 for ; Fri, 23 Oct 2009 16:44:41 -0300 (ADT) Received: from mailnyc2.nyc.deshaw.com (mailnyc2.nyc.deshaw.com [149.77.72.24]) by master.nyc.deshaw.com (8.13.8+Sun/8.13.7/2.0.kim.desco.357) with ESMTP id n9NJieql011379 for ; Fri, 23 Oct 2009 15:44:40 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5419.24FECDCF" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: [PATCH] clarify username mapping in Kerberos and GSSAPI Date: Fri, 23 Oct 2009 15:43:50 -0400 Message-ID: <28A4DB436106924BADF219EA31CE80AEF4BEE7@mailnyc2.nyc.deshaw.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] clarify username mapping in Kerberos and GSSAPI Thread-Index: AcpUGSSzIZw5X1a2SE6DuZxedO6E8Q== From: "Turner, Ian" To: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200910/7 X-Sequence-Number: 5278 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5419.24FECDCF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello all, I noticed what appears to be an ambiguity in this area, so I prepared a = patch. It is included below. The issue is that the documentation does = not make it crystal clear exactly what string is used for username = mapping when authenticating with GSSAPI or Kerberos. It's possible that = this issue also applies to the SSPI documentation, though I didn't = check. Cheers, --Ian Turner Senior UNIX Systems Engineer D. E. Shaw & Co. --- postgresql-8.4-8.4.1/doc/src/sgml/client-auth.sgml 2009-06-24 = 14:46:32.000000000 +0100 +++ postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml = 2009-10-23 20:41:28.000000000 +0100 @@ -801,23 +801,28 @@ The following configuration options are supported for = GSSAPI: - map + include_realm - Allows for mapping between system and database usernames. See - for details. + If set to 1, the realm name from the authenticated = user + principal is included in the system user name that's passed = through + username mapping (). This = is + useful for handling users from multiple realms. - include_realm + map - If set to 1, the realm name from the authenticated = user - principal is included in the system user name that's passed = through - username mapping (). This = is - useful for handling users from multiple realms. + Allows for mapping between system and database usernames. See + for details. For a = Kerboros + principal username/hostbased@EXAMPLE.COM, = the + username used for mapping is = username/hostbased + if include_realm is disabled, and + username/hostbased@EXAMPLE.COM if + include_realm is enabled. @@ -1003,10 +1008,10 @@ When connecting to the database make sure you have a ticket for a principal matching the requested database user name. For example, = for - database user name fred, both principal - fred@EXAMPLE.COM and - fred/users.example.com@EXAMPLE.COM could be used to - authenticate to the database server. + database user name fred, principal + fred@EXAMPLE.COM would be able to connect. To also = allow + principle fred/users.example.com@EXAMPLE.COM, use a = username + map, as described in . ------_=_NextPart_001_01CA5419.24FECDCF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [PATCH] clarify username mapping in Kerberos and GSSAPI

Hello all,

I noticed what appears to be an = ambiguity in this area, so I prepared a patch. = It is included below. The issue is that the documentation does not make = it crystal clear exactly what string is used for username mapping when = authenticating with GSSAPI or Kerberos. = It’s = possible that this issue also = applies to the = SSPI = documentation, though I didn’t check.

Cheers,

--Ian Turner

Senior UNIX Systems Engineer

D. E. Shaw & Co.

--- = postgresql-8.4-8.4.1/doc/src/sgml/client-auth.sgml  2009-06-24 = 14:46:32.000000000 +0100

+++ = postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml   = 2009-10-23 20:41:28.000000000 +0100

@@ -801,23 +801,28 @@

     The following configuration options = are supported for = <productname>GSSAPI</productname>:

     = <variablelist>

      = <varlistentry>

-      = <term><literal>map</literal></term>=

+      = <term><literal>include_realm</literal></term>

       = <listitem>

        = <para>

-        Allows for = mapping between system and database usernames. See

-        <xref = linkend=3D"auth-username-maps"> for = details.

+        If set to = <literal>1</>, the realm name from the authenticated = user

+        principal is = included in the system user name that's passed through

+        username mapping = (<xref linkend=3D"auth-username-maps">). This = is

+        useful for = handling users from multiple realms.

        = </para>

       = </listitem>

      = </varlistentry>

      = <varlistentry>

-      = <term><literal>include_realm</literal></term>

+      = <term><literal>map</literal></term>=

       = <listitem>

        = <para>

-        If set to = <literal>1</>, the realm name from the authenticated = user

-        principal is = included in the system user name that's passed through

-        username mapping = (<xref linkend=3D"auth-username-maps">). This = is

-        useful for = handling users from multiple realms.

+        Allows for = mapping between system and database usernames. See

+        <xref = linkend=3D"auth-username-maps"> for details. For a = Kerboros

+        principal = <literal>username/hostbased@EXAMPLE.COM</literal>, = the

+        username used for = mapping is = <literal>username/hostbased</literal>

+        if = <literal>include_realm</literal> is disabled, = and

+        = <literal>username/hostbased@EXAMPLE.COM</literal> = if

+        = <literal>include_realm</literal> is = enabled.

        = </para>

       = </listitem>

      = </varlistentry>

@@ -1003,10 +1008,10 @@

    <para>

     When connecting to the database make = sure you have a ticket for a

     principal matching the requested = database user name. For example, for

-    database user name = <literal>fred</>, both principal

-    <literal>fred@EXAMPLE.COM</> = and

-    = <literal>fred/users.example.com@EXAMPLE.COM</> could be used = to

-    authenticate to the database = server.

+    database user name = <literal>fred</>, principal

+    <literal>fred@EXAMPLE.COM</> = would be able to connect. To also allow

+    principle = <literal>fred/users.example.com@EXAMPLE.COM</>, use a = username

+    map, as described in <xref = linkend=3D"auth-username-maps">.

    </para>

    <para>

------_=_NextPart_001_01CA5419.24FECDCF--