Re: RADIUS fallback servers

From: Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: RADIUS fallback servers
Date: 2017-03-03 18:44:13
Message-ID: CAE_9P=j8qnrYRX+gA9=CCaCDhbpa9iu3y=aMkTQWs26OoW66Eg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've given an initial review of this patch. It applies cleanly and
compiles without issue as of 6da9759. I'm going to continue with
testing it against a set of RADIUS servers in the next few days. But
in the meantime, I have a few questions (below).

> It supports multiple RADIUS servers. For all other parameters (secret, port,
> identifier) one can specify either the exact same number of entries, in
> which case each server gets it's own, or exactly one entry in which case
> that entry will apply to all servers. (Or zero entries for everything except
> secret, which will make it the default).

I wonder if removing the complexity of maintaining two separate lists
for the server and port would be a better/less complex approach. For
instance, why not go with a list of typical 'host:port' strings for
'radiusservers'? If no port is specified, then simply use the default
for that specific host. Therefore, we would not have to worry about
keeping the two lists in sync. Thoughts?

> Each server is tried in order. If it responds positive, auth is OK. If it
> responds negative, auth is rejected. If it does not respond at all, we move
> on to the next one.
>
> I'm wondering if in doing this we should also make the RADIUS timeout a
> configurable as HBA option, since it might become more important now?

Yes, I think this would make sense and would be a good idea.

-Adam

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-03-03 18:58:12 Re: DROP SUBSCRIPTION and ROLLBACK
Previous Message Pavel Stehule 2017-03-03 18:42:11 Re: patch: function xmltable