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

From Henry B. Hotz
Subject Design Considerations for New Authentication Methods
Date
Msg-id DF6470FA-FCF7-41DE-A13B-FDA761C1C157@jpl.nasa.gov
Whole thread Raw
Responses Re: Design Considerations for New Authentication Methods  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Design Considerations for New Authentication Methods  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
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.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: TODO Item: IN(long list ...)
Next
From: Dave Cramer
Date:
Subject: Extended protocol logging