Supporting fallback RADIUS server(s) - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Supporting fallback RADIUS server(s)
Date
Msg-id 55D51B54.4050902@joh.to
Whole thread Raw
Responses Re: Supporting fallback RADIUS server(s)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

We use RADIUS authentication at $WORK, and it has one major flaw (well, 
two, but I already fixed the other one this week): it only supports 
specifying a single server, which as we might know, is bad for high 
availability.  So I'm developing a patch to fix this issue, but I'm not 
exactly sure what the configuration should look like.  I see multiple 
options, but the one I like the best is the following:

Add two new HBA configuration options: radiusfallbackservers and 
radiusfallbackports; both lists parsed with SplitIdentifierString (à la 
listen_addresses).  If radiusfallbackservers is set, it's the list of 
servers to try after "radiusserver" has timed out (but ONLY if it timed 
out, obviously).  If radiusfallbackports is set, it must be of equal 
length with radiusfallbackservers, and the corresponding port entry is 
used for each fallback server.  If it's not set, radiusport is used as 
the port for all fallback servers, or finally the default port (1812) if 
no port options have been specified in pg_hba.conf.

This interface is both flexible, simple to use in the common case (YMMV) 
and fully backwards compatible.

I'm planning two submit two patches: one to refactor CheckRADIUSAuth() a 
bit to make it easier to try the authentication against more than one 
server, and then another one to add the two new configuration options.

Does anyone have a problem with this plan?  Want to comment on the 
interface or get anything else off their chest?


.m



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Badly broken logic in plpython composite-type handling
Next
From: Tom Lane
Date:
Subject: Re: proposal: function parse_ident