Supporting fallback RADIUS server(s)

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Supporting fallback RADIUS server(s)
Дата
Msg-id 55D51B54.4050902@joh.to
обсуждение исходный текст
Ответы Re: Supporting fallback RADIUS server(s)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Badly broken logic in plpython composite-type handling
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: function parse_ident