On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
What the krb5 method does is IMO a documented bug. The realm name
is part
of the name.
As I explained at some length you cannot assume the username (first
component of the principal) has any meaning by itself, except in
small
deployments with no external trust agreements. Kerberos (and AD) are
designed to support larger infrastructures with multiple
organizations.
This isn't unexpected for PG as the current krb5 support does
this. I'm
not a big fan of it but at the same time I don't feel it's
justification
to drop it from 8.3. Having it only allow the default realm would
be an
option which could work in 8.3, imv.
I don't think the fact that the existing krb5 code does the wrong
thing (and can't be used in an environment with cross-realm
agreements) is justification for doing the wrong thing in a new
capability. The code in my original patch would do the latter
(default realm only).
More precisely: if you do a gss_import_name() on "smith" and
"[EMAIL PROTECTED]" you get the same internal representation, and
gss_compare_name() will tell you they're the same. Also
gss_compare_name() will tell you "[EMAIL PROTECTED]" is different
from either of the first two.
If we don't use gss_compare_name(), or some similar mechanism, to
compare connection names to PG usernames, then I don't think GSSAPI
support should be included in 8.3.
Longer term (since it's likely too
late to be accepted now), as I think has been discussed in the
past, PG
could really use a .k5login-esque, either admin-only (ala
pg_hba.conf /
ident map) or per-user (some sort of ALTER ROLE that a user could
do on
himself?), mapping functionality.
There has been discussion of a general mapping layer between
authentication names and authorization/role names. I think that's
the way to go. I haven't thought about who or where the
administration of the mapping ought to be.
See note about authentication vs authorization in last email.
It doesn't strike me as terribly complex or hard to do but it
certainly
goes beyond the what is currently implemented for GSS in 8.3, and what
exists currently for krb5. It's also something which could,
technically, be added later. I do think it would be better done now
though, if possible, since otherwise we would have to default to the
current sub-par behaviour for quite some time (if not forever).
Thanks,
Stephen
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
