Re: Continuous re-validation of session credentials

Hi,

Following up on the ongoing work for continuous credential validation, I would like to propose the next two patches in the series. 

These patches extend the continuous validation framework to handle both GSSAPI/Kerberos and LDAP (Search+Bind) authenticated sessions.

Patch 4/5: Add GSS credential expiry to credential validation

This patch introduces method-specific validation for GSSAPI/Kerberos sessions (CVT_GSS).The GSS security context established at authentication carries a lifetime derived from the client's Kerberos ticket. We introduce a helper be_gssapi_get_context_expired() which utilizes gss_context_time() on the acceptor context retained on the Port. This is a purely local check that requires no round-trip to the KDC. If the context lifetime has elapsed, the session is safely terminated. 

postgres=> select system_user;      system_user
----------------------- gss:test1@EXAMPLE.COM
(1 row)

postgres=> select current_user; current_user
-------------- test1

postgres=> select current_time;
FATAL:  session credentials have expired
HINT:  Please reconnect to establish a new authenticated session.
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.

(1 row)

Patch 5/5: Add LDAP account-existence check to credential validation

This patch adds validation support for LDAP sessions (CVT_LDAP).

 Unlike token- or certificate-based authentication, an LDAP session does not retain a credential with an intrinsic expiry date. Instead, "validity" is defined as the account's continued existence within the directory.

 During each validation cycle, the backend connects and re-binds using the configured search credentials (ldapbinddn / ldapbindpasswd), then re-runs the configured search filter. If the search yields exactly zero entries, the account is considered deleted    or disabled, and the session is terminated.

postgres=> SELECT current_user;
 current_user
--------------
 test1
(1 row)

postgres=> select system_user;
           system_user
----------------------------------
 ldap:uid=test1,dc=example,dc=net. <= After this I fired ldapdelete and got validation error on next validation cycle
(1 row)

postgres=> select current_time;
FATAL:  session credentials have expired
HINT:  Please reconnect to establish a new authenticated session.
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.

(1 row)

Thanks & Best regards, 

Ajit

On Fri, 26 Jun 2026 at 11:21, Ajit Awekar <ajitpostgres@gmail.com> wrote:

Hi,

Attached is v2 of the patch set, rebased on the current master.

The only functional change from the previous version is a fix for the

cfbot failure. The earlier version src/test/modules/test_misc/t/003_check_guc.pl

due to the tab in the trailing spaces.

Thanks & Best Regards,

Ajit

On Tue, 16 Jun 2026 at 17:44, Ajit Awekar <ajitpostgres@gmail.com> wrote:

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