postgres-github.git / summary / log / commit / refs

commit    b977bd308a09e8a70db1776db80e8abd84ca2b7e
Author:   Jacob Champion <jchampion@postgresql.org>
Date:     Tue Apr 07 15:15:19 2026 +0000

    oauth: Allow validators to register custom HBA options
    
    OAuth validators can already use custom GUCs to configure behavior
    globally. But we currently provide no ability to adjust settings for
    individual HBA entries, because the original design focused on a world
    where a provider covered a "single audience" of users for one database
    cluster. This assumption does not apply to multitenant use cases, where
    a single validator may be controlling access for wildly different user
    groups.
    
    To improve this use case, add two new API calls for use by validator
    callbacks: RegisterOAuthHBAOptions() and GetOAuthHBAOption().
    Registering options "foo" and "bar" allows a user to set "validator.foo"
    and "validator.bar" in an oauth HBA entry. These options are stringly
    typed (syntax validation is solely the responsibility of the defining
    module), and names are restricted to a subset of ASCII to avoid tying
    our hands with future HBA syntax improvements.
    
    Unfortunately, we can't check the custom option names during a reload of
    the configuration, like we do with standard HBA options, without
    requiring all validators to be loaded via shared_preload_libraries.
    (I consider this to be a nonstarter: most validators should probably use
    session_preload_libraries at most, since requiring a full restart just
    to update authentication behavior will be unacceptable to many users.)
    Instead, the new validator.* options are checked against the registered
    list at connection time.
    
    Multiple alternatives were proposed and/or prototyped, including
    extending the GUC system to allow per-HBA overrides, joining forces with
    recent refactoring work on the reloptions subsystem, and giving the
    ability to customize HBA options to all PostgreSQL extensions. I
    personally believe per-HBA GUC overrides are the best option, because
    several existing GUCs like authentication_timeout and pre_auth_delay
    would fit there usefully. But the recent addition of SNI per-host
    settings in 4f433025f indicates that a more general solution is needed,
    and I expect that to take multiple releases' worth of discussion.
    
    This compromise patch, then, is intentionally designed to be an
    architectural dead end: simple to describe, cheap to maintain, and
    providing just enough functionality to let validators move forward for
    PG19. The hope is that it will be replaced in the future by a solution
    that can handle per-host, per-HBA, and other per-context configuration
    with the same functionality that GUCs provide today. In the meantime,
    the bulk of the code in this patch consists of strict guardrails on the
    simple API, to try to ensure that we don't have any reason to regret its
    existence during its unknown lifespan.
    
    I owe particular thanks here to Zsolt Parragi, who prototyped several
    approaches that guided the final design.
    
    Suggested-by: Zsolt Parragi <zsolt.parragi@percona.com>
    Suggested-by: VASUKI M <vasukianand0119@gmail.com>
    Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
    Discussion: https://postgr.es/m/CAN4CZFM3b8u5uNNNsY6XCya257u%2BDofms3su9f11iMCxvCacag%40mail.gmail.com

[parent: 6d00fb9048fe]