From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
---|---|
To: | "Samuel D(dot) Leslie" <SDL(at)nexiom(dot)net> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add radiustimeout parameter for RADIUS HBA |
Date: | 2016-11-03 07:20:06 |
Message-ID: | CAJrrPGcKf=yq9MdaAWpY9-XtVer9Zr5PLTdATsbj7P_FmT3RSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 24, 2016 at 2:03 PM, Samuel D. Leslie <SDL(at)nexiom(dot)net> wrote:
> Hello everyone,
>
> I’d like to submit the attached patch for feedback from the PostgreSQL
> community and potential future inclusion in the codebase. The patch adds a
> new parameter to the RADIUS authentication method named “radiustimeout”,
> allowing the database administrator to configure the timeout in seconds to
> wait for responses from a configured RADIUS server. Until now, this has
> been hardcoded to three seconds by the RADIUS_TIMEOUT define in auth.c.
> While this is usually sufficient for typical RADIUS server configurations,
> there are some more unusual configurations where a higher timeout is
> required. Examples include:
> - Authenticating against a RADIUS server over a high latency link
> - Authenticating against a RADIUS server that is performing additional
> out-of-band authentication
>
> The latter case is applicable to a server I admin and spurred the
> development of this patch. We implemented multi-factor authentication for
> user access to a sensitive database via a RADIUS server implementation
> which performs the standard username & password verification, and if it
> succeeds, subsequently performs a second factor of authentication via a
> configured mobile app. The RADIUS response confirming successful
> authentication is only returned after both authentication factors have
> completed. In our deployment, a timeout of 60 seconds seems to work well,
> but certainly three seconds is not at all workable.
>
> Thanks in advance for any and all feedback.
>
I reviewed and tested the patch. It works as expected.
Following are my observations during the test.
1. In case if the radiustimeout is more than authentication_timeout the
client connection is stopped only when the radiustimeout is occurred.
Do we need add the CHECK_FOR_INTERRUPTS() call or add this
behavior information in the docs?
2. When the Postgresql Backend is waiting for a response from
Radius server, in case if the client disconnects, still backend waits
for the response from RADIUS server and then it closes.
I feel the second case is rare, may not be a problem.
Regards,
Hari Babu
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | amul sul | 2016-11-03 07:22:32 | Re: Exclude pg_largeobject form pg_dump |
Previous Message | amul sul | 2016-11-03 07:12:18 | Re: Exclude pg_largeobject form pg_dump |