Re: Design Considerations for New Authentication Methods

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Design Considerations for New Authentication Methods
Date: 2006-11-01 18:43:01
Message-ID: C7EFB93E-052A-4A69-9A92-9C870F791F1A@jpl.nasa.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Nov 1, 2006, at 6:33 AM, Stephen Frost wrote:

> * Henry B. Hotz (hotz(at)jpl(dot)nasa(dot)gov) wrote:
>> I've been looking at adding SASL or GSSAPI as an auth method. I have
>> some questions about how to handle the flow of control changes.
>
> Great! I'd love to see that implemented, personally, so if you're
> looking for help, please let me know.

Thank you. I will! ;-)

Do you know Java? I'm doing this ultimately because I want the JDBC
driver to support encrypted connections with Kerberos and without
needing SSL. As an added plus a Windows-native client should support
it.

My main hesitation between SASL and GSSAPI is that the Windows
equivalent APIs for SASL have not received the same degree of
interoperability testing as SSPI<-->GSSAPI. I don't have a published
example to crib from. For general information the relevant calls are
at the bottom of <http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/secauthn/security/authentication_functions.asp>.

"I don't do windows (TM)." ;-)

>> round trips and network accesses done. I notice that all the
>> authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
>> which sounds like something that isn't expected to block on network
>> access.
>
> I think you're missing a bit about how the design works.
> PGConnectPoll() is expected to be called multiple times until the
> connection is established.

I think I got it. I just didn't want to get it.

I'll probably do the simple, blocking-loop client anyway as a way to
debug the server side. Then worry about getting the clients up to
snuff.

> Basically, you can return something to the
> user that says "connection not done yet, but I'm returning because you
> said to not block. Please call again when more data available or you
> have the opportunity to". This is a pretty common arrangment when
> non-blocking systems are implemented. As Tom said, you should just
> need
> to have some state stored so that you know what's going on when you're
> called again.

Once I start adding connection state I can add a control for whether
data packets need to be wrapped as well. I'm not sure how hard the
>8KB case will be to handle though. Probably some hooks in the
underlying library, and I hope they make it easier rather than harder.

> Thanks!
>
> Stephen

------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message imad 2006-11-01 19:18:09 Re: ¿¿¿past chunk end???
Previous Message Kai-Uwe Sattler 2006-11-01 18:41:58 Re: [Fwd: Index Advisor]