| From: | Ajit Awekar <ajitpostgres(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Continuous re-validation of session credentials |
| Date: | 2026-06-16 12:14:27 |
| Message-ID: | CAER375PeMJkejmRueUoWjpMwg+msX4HahP6_=UFxJyge_boD4Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Today PG validates a client's credentials only once, at connection
time. After that the backend runs until the client disconnects, even if
the
basis for the original authentication decision has gone away. In
particular:
- the role's VALID UNTIL passes, or the role is dropped (ALTER ROLE ...
VALID UNTIL / DROP ROLE);
- the OAuth bearer token the session authenticated with expires;
- the TLS client certificate the session authenticated with reaches its
notAfter date.
In all of these cases a long-lived session keeps running with credentials
that
would be rejected on a fresh connection. For environments with short-lived
credentials (OAuth tokens, short-lived certs, time-boxed accounts) this is a
real gap: revoking access has no effect on already-established sessions.
This patch series adds an optional mechanism to periodically re-validate
the
credentials of an active session and terminate it (FATAL) once they are no
longer valid.
A per-backend timer (CREDENTIAL_VALIDATION_TIMEOUT) fires every
credential_validation_interval seconds and sets a pending flag.
Validation has two layers:
- A baseline, auth-method-independent check (role still exists and has
not
passed rolvaliduntil), applied to every authenticated session.
- Optional method-specific validators, registered via
RegisterCredentialValidator(), for OAuth token expiry and client
certificate expiry.
The framework is deliberately extensible: adding re-validation for a new
authentication method needs only three small steps -- add a
CredentialValidationType, implement a "bool validator(void)" callback that
returns whether the credential is still valid, and register it with
RegisterCredentialValidator(). The certificate and OAuth validators in
0002
and 0003 are themselves examples of plugging into the framework this way,
so methods such as LDAP, RADIUS, or GSSAPI/Kerberos credential lifetimes
could be added later without touching the core.
Two GUCs :
credential_validation_enabled (bool, default off)
credential_validation_interval (int, 5..3600 s, default 60)
Patch series
------------
0001 Framework + baseline role-validity check (rolvaliduntil / role
existence). Useful on its own for password/md5/scram sessions.
0002 TLS client certificate expiry. The cert presented at connect time
is
retained on the Port, so its notAfter is re-checked locally with no
network round-trip.
0003 OAuth token expiry. This adds an optional expire_cb callback to
OAuthValidatorCallbacks; to stay ABI-compatible the validator magic
is
versioned (V1 = existing layout, V2 = adds expire_cb), and the
server
accepts both.
Request a review.
Thanks & Best Regards,
Ajit
| Attachment | Content-Type | Size |
|---|---|---|
| 0002-Add-TLS-client-certificate-expiry-to-credential-vali.patch | application/octet-stream | 11.5 KB |
| 0003-Add-OAuth-token-expiry-to-credential-validation.patch | application/octet-stream | 10.8 KB |
| 0001-Add-continuous-credential-validation-framework.patch | application/octet-stream | 36.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Renaud Métrich | 2026-06-16 12:16:59 | Re: [PATCH v2] Add ssl_alt_cert_file/ssl_alt_key_file for dual RSA+ECDSA certificate support |
| Previous Message | solai v | 2026-06-16 12:07:20 | Re: Improving psql autocompletion for SET LOCAL / SET SESSION |