Re: Design Considerations for New Authentication Methods - Mailing list pgsql-hackers

From Henry B. Hotz
Subject Re: Design Considerations for New Authentication Methods
Date
Msg-id C7EFB93E-052A-4A69-9A92-9C870F791F1A@jpl.nasa.gov
Whole thread Raw
In response to Re: Design Considerations for New Authentication Methods  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Design Considerations for New Authentication Methods  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-hackers
On Nov 1, 2006, at 6:33 AM, Stephen Frost wrote:

> * Henry B. Hotz (hotz@jpl.nasa.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
hooksin 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.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




pgsql-hackers by date:

Previous
From: Kai-Uwe Sattler
Date:
Subject: Re: [Fwd: Index Advisor]
Next
From: imad
Date:
Subject: Re: ¿¿¿past chunk end???