On Fri, 2021-01-29 at 17:01 -0500, Stephen Frost wrote:
> > - for LDAP, the bind DN is discarded entirely;
>
> We don't support pg_ident.conf-style entries for LDAP, meaning that the
> user provided has to match what we check, so I'm not sure what would be
> improved with this change..?
For simple binds, this gives you almost nothing. For bind+search,
logging the actual bind DN is still important, in my opinion, since the
mechanism for determining it is more opaque (and may change over time).
But as Tom noted -- for both cases, if the role name changes, this
mechanism can still help you audit who the user _actually_ bound as,
not who you think they should have bound as based on their current role
name.
(There's also the fact that I think pg_ident mapping for LDAP would be
just as useful as it is for GSS or certs. That's for a different
conversation.)
> I'm also just generally not thrilled with
> putting much effort into LDAP as it's a demonstrably insecure
> authentication mechanism.
Because Postgres has to proxy the password? Or is there something else?
> > I propose that every auth method should store the string it uses to
> > identify a user -- what I'll call an "authenticated identity" -- into
> > one central location in Port, after authentication succeeds but before
> > any pg_ident authorization occurs. This field can then be exposed in
> > log_line_prefix. (It could additionally be exposed through a catalog
> > table or SQL function, if that were deemed useful.) This would let a
> > DBA more easily audit user activity when using more complicated
> > pg_ident setups.
>
> This seems like it would be good to include the CSV format log files
> also.
Agreed in principle... Is the CSV format configurable? Forcing it into
CSV logs by default seems like it'd be a hard sell, especially for
people not using pg_ident.
> For some auth methods, eg: GSS, we've recently added information into
> the authentication method which logs what the authenticated identity
> was. The advantage with that approach is that it avoids bloating the
> log by only logging that information once upon connection rather than
> on every log line... I wonder if we should be focusing on a similar
> approach for other pg_ident.conf use-cases instead of having it via
> log_line_prefix, as the latter means we'd be logging the same value over
> and over again on every log line.
As long as the identity can be easily logged and reviewed by DBAs, I'm
happy.
--Jacob
