From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Magnus Hagander" <magnus(at)hagander(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Dave Page" <dpage(at)postgresql(dot)org>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Future of krb5 authentication |
Date: | 2007-07-18 21:49:18 |
Message-ID: | 87ir8hz8kh.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Magnus Hagander wrote:
>
>> The wire protocol is the same for them. It's a matter of which *client
>> library* should be used to produce the packets that go over the network.
>...
> On Windows, why would you need GSSAPI, if SSPI comes with the operation
> system? What's the difference between the libraries? Can you try SSPI
> first, and fall back to GSSAPI?
Am I right in thinking that while the client<->postgres protocol may be the
same the actual authentication tokens are different? That is, if you have a
Windows Active Directory server then using SSPI will use your Windows
credentials obtained from that server to log you in whereas if you used the
MIT GSSAPI library it would try to use your Kerberos tickets for which it would
look elsewhere?
What confuses me here is that I don't understand how this relates to
applications. You keep talking about using the connection string which may be
appropriate for a user-oriented application like psql. But in the general case
surely the application needs to be able to control the authentication process
and be able to provide credentials of its choice?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-18 21:52:03 | Re: Future of krb5 authentication |
Previous Message | Stephen Frost | 2007-07-18 21:44:48 | Re: Future of krb5 authentication |