Keenan,
* keenan@thebrocks.net (keenan@thebrocks.net) wrote:
> I'm looking into connection to postgres using authentication from client
> certificates. [1]
Nice! Glad to hear of more users of that capability. :)
> The documentation states that the common name (aka CN) is read from the
> certificate and used as the user's login (aka auth_user).
> The problem is the common name is typically the user's full name. A field
> like email address would contain a more computer friendly identifier.
This is why we have the pg_ident mapping capability.. I realize that
file has to be generated, but at that point it's really just a string,
no?
That said, I'm not against this capability in general, but we'd need to
make sure it doesn't lock us into OpenSSL. Heikki's been working on
changing the SSL code to allow other libraries to be used, which is
great, and I'm slightly worried this might make that more difficult.
The other issue is that we'd need to be very cleear in the documentation
that any users of this capability have to verify with their CA that they
aren't going to end up with the same value in whichever field is used
for distinct individuals- otherwise, the CA might unknowingly issue two
certs with the same value and you would then be unable to distinguish
between those two certs and both certs would have access to the account.
That's already an issue in the SSL world when using "real" CAs (that is,
ones outside of your own organization) and, really, we would do better
to support including *more* fields than just the CN to address that
issue. As such, perhaps we should support having a *list* of fields to
use and then we combine them in some way in the mapping file. That
would allow users to, say, include the issuer and the CN, and perhaps
the serial number if they want.
Thanks!
Stephen
