Re: Design Considerations for New Authentication Methods

Поиск
Список
Период
Сортировка
От Henry B. Hotz
Тема Re: Design Considerations for New Authentication Methods
Дата
Msg-id C7EFB93E-052A-4A69-9A92-9C870F791F1A@jpl.nasa.gov
обсуждение исходный текст
Ответ на Re: Design Considerations for New Authentication Methods  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Design Considerations for New Authentication Methods
Список 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 по дате отправления:

Предыдущее
От: Kai-Uwe Sattler
Дата:
Сообщение: Re: [Fwd: Index Advisor]
Следующее
От: imad
Дата:
Сообщение: Re: ¿¿¿past chunk end???