Design Considerations for New Authentication Methods

["Henry B. Hotz" <hotz(at)jpl(dot)nasa(dot)gov>]

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.

When you do one of the above, an authentication is not (necessarily)  
a simple one-packet exchange.  In fact the exchange may involve  
trying several different authentication mechanisms before you find  
one that works.

The question is how do I handle the multiple round-trips where one  
trip is now assumed?

The simple approach is for me to just put the loop inside the  
relevant fe-auth.c and auth.c sections, corresponding to where the  
pg_krb5_{send,recv}auth() calls are.  However the comments in the  
code make it sound like people are very concerned about the number of  
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.

Is this behavior important during startup?  Or is it only important  
once the connection is fully established?

I haven't looked at the corresponding logic on the server side, but  
I'd assume that it forks before we get to this point so it doesn't  
matter.
------------------------------------------------------------------------ 
----
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