Brian Crowell <brian@fluggo.com> writes:
> I'm starting to see that this appears very differently to Postgres
> people. I'm coming here from SQL Server, where in our company we've
> now got it set up that each user's SQL Server login _is_ their domain
> login. Not just named the same--SQL Server understands the domain, and
> each user is coming in as their Windows identity.
> However, to Postgres, Kerberos is not about identities at all, it's
> just a fancy password mechanism. Really you just want to know a
> Postgres user, and it's never been a problem for users to specify
> that. I guess what I'm asking is if Kerberos can be used to specify my
> Postgres username as well.
Hm. That's an interesting way of putting it, and you're right --- we
don't expect Kerberos to be a source of identity. Which is not the
world view Kerberos users have.
I wonder whether there would be any value in an option for SSPI (and
maybe other auth methods) to say "after authentication is complete,
substitute the authenticated principal name for the database user
name" (possibly after realm-stripping, case-folding, etc).
The usage pattern would be that you'd pass say "use_kerberos_username"
as the user name in the startup packet, and that would select a
pg_hba.conf entry along the lines of
host use_kerberos_username all samenet sspi use_principal=without_realm
I'm not sure if that'd solve Npgsql's problem or not, though. As sketched
here, the existence of such an auth entry, as well as the spelling of the
magic username, would be at the whim of the Postgres installation's DBA.
That might not be stable enough for you; I'm betting you're wishing you
could hard-wire a dummy name. On the other hand, you weren't complaining
about the fact that you can't use Kerberos at all without a suitable
pg_hba entry; so maybe some additional constraints on its form would be OK
for your use-case.
regards, tom lane