On Nov 2, 2007, at 8:38 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
On Nov 1, 2007, at 1:40 PM, Magnus Hagander wrote:
Henry B. Hotz wrote:
Thank you very much. This helps, but I'm still evaluating how
much.
I *can* point at one problem though: you do a strchr
(gbuf.value, '@')
and then error out if there isn't a Kerberos realm there. In
fact that
is exactly the default username of at least one of the GSSAPI
implementations I've tested if the realm is the same as the local
default realm.
Eh, so how do we then determine the difference between local
realm and
no realm given?
Well, what I've seen is: no realm given if and only if the default
local realm matches the realm for the GSSAPI username. I don't think
that's guaranteed.
Irrk. Very much irrk.
I'm not entirely sure what the intended semantics of
krb_match_realm
are, but if you're trying to match the GSSAPI-authenticated name
against
"value_of(PGUSER)@value_of(krb_match_realm)" then you need to
construct
that string, gss_import_name() it, and then gss_compare_name() the
imported name with the authenticated name that GSSAPI already
gave you.
I know the API overhead of doing that is a PITA, but that's
what's going
to work.
Why?
Because if we're using the GSSAPI then we need to use the properties
defined by the GSSAPI, and not depend on observed behavior of
specific
implementations of specific mechanisms. Otherwise things will be
non-portable or unreliable in ways that may be non-obvious.
In particular gss_display_name() produces a character string intended
for display to a human being. It is *NOT* intended for access
control.
As another example, Heimdal gss_display_name() puts '\' escapes in
front
of special characters in the username. I don't think it's worth
writing
special case code for that either.
Ok. I can see that point. However, if you have those characters in
your
username, you may have other problems as well :-)
Yeah. Not many people put spaces inside usernames.
Is there some other way to actually get the username from gss? I mean,
if we *didn't* get it from the startup packet, how would we ever be
able
to determine what user logged in?
gss_export_name(), but what it returns is supposed to be an opaque
binary blob.
It's guaranteed to produce a unique, canonicalized name based on the
specific mechanism in use. It is suitable for memcmp(). The
exported name will re-import. Section 3.10 of rfc 2744 describes all
this, and appears to be clearer than the Sun document I pointed you
at. Certainly it's more concise. YMMV.
memcmp() on exported names will only be true if everyone uses the
same gss mechanism. (OK, the only one we care about is kerberos.)
In contrast it's possible that gss_compare_name() would say that
"uid=smith,ou=People,dc=example,dc=com" is the same as
[EMAIL PROTECTED]
The standard defines two ways to do comparisons for access
control. We
should use one of them. Anything else is going to be more work
and less
reliable.
What's the other way then?
Last I checked there was no way to do case insensitive matching on
gss_compare_name() but I could be on the wrong docs? Finding any
kind of
consistent docs for this stuff isn't exactly easy.
Because we *must* have the ability to do case insensitive matching, or
it *will* break on Windows.
No gss_compare_name() is case sensitive. I think the way to do it is
to know what case Microsoft is going to use and pre-map everything to
that case (before you do a gss_import_name()). I *think* Microsoft
will use upper case for the service name so we will need to change
from "postgres" to "POSTGRES" as the default name in service
principals. I've seen places where they may be using lower case
realm names (which makes *NO* sense to me).
Absent an environment where I can actually look at all these things,
my only point of reference is mod_auth_kerb, and the issues reported
with it. I know an upper case "HTTP" is needed to interoperate with
windows clients. An upper case realm name seems to be OK, as is a
lower case server name in the second component. The actual usernames
seem to be lower case, but that's not the concern of the
mod_auth_kerb developers since the deployer just needs to put in
whatever matches.
I assume in AD you can't create both "smith" and "Smith", but can you
create the latter at all? If you do, does AD remember the case for
display purposes? Here at JPL usernames are lower case, and I don't
think we allow anything special but hyphens in them, so I'm not
likely to see a lot of the possible corner cases.
I think you can upper case the service name, lower case the server
name, upper case the realm name, and lower case the user name. If
you can create "Smith" in AD and the user gets authenticated as
"[EMAIL PROTECTED]" at the protocol level then that won't work though.
I'm actually trying to write some Kerberos principal to X500 name
translation code for mod_auth_kerb right now, and I'm not happy with
my options. I'm probably going to wind up doing something that I
would tell you is improper, not general purpose, fragile, and
shouldn't be done. |-P At least it's completely legitimate for me
to assume that the only mechanism in use is the Kerberos one (since
SPNEGO will have negotiated to kerberos before I need to worry about
it). This is part of building up an example SAPP server (Solaris
Apache Postgres Perl, you've heard of LAMP servers I assume).
Well, it's not a high priority for me, but there is a GSSAPI
mechanism
called SPKM which uses X500-syle names (X509 certificate subject
names
to be precise). If we use gss_name_compare() properly then it should
"just work".
I'm unsure if PostgreSQL in general is prepared to deal with such
usernames. You'd certainly have to verify that stuff before anything
would "just work".
//Magnus
Well it might be nice if we could use the same logic and conventions
to support TLS client identities as SPKM ones. Shouldn't be hard.
(Famous last words.)
------------------------------------------------------------------------
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 6: explain analyze is your friend
