Re: RADIUS fallback servers

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>
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 19:53:46
Message-ID: CABUevEwM3tm588OyRmz607URH5=dSgu22KLjRAppYrPUrV4eTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, March 3, 2017, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>
wrote:

> 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?
>

If we do that we should do it for all the parameters, no? So not just
host:port, but something like host:port:secret:identifier? Mixing the two
ways of doing it would be quite confusing I think.

And I wonder if that format wouldn't get even more confusing if you for
example want to use default ports, but non-default secrets.

I can see how it would probably be easier in some of the simple cases, but
I wonder if it wouldn't make it worse in a lot of other cases.

> > 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.
>
>

//Magnus

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-03-03 20:04:28 Re: patch: function xmltable
Previous Message Petr Jelinek 2017-03-03 19:51:22 Re: Logical Replication and Character encoding