Обсуждение: Authenticating from SSL certificates
Hello,
I'm looking into connection to postgres using authentication from client certificates. [1]
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.
So my feature request is to allow the postgres admin to specify the field in the ssl client certificate to be used to read the auth_user.
I started to dig into the code and have some thoughts, but wanted to get any advice before I started writing up some code.
Add a "user" option to pg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
hostssl all all all cert map=usermap user=CN
1. Documentation seems straight forward [1]
2. The configuration value would be added in parse_hba_line and this value is accessible via port->hba.
3. The certificate can be parsed from port->peer with something like X509_NAME_field_to_text [2].
4. The user requested field would then be passed as auth_user into check_usermap [3].
The current code parses the ssl common name and populates peer_cn pretty early on. [4]
That suggests to me that most of the ssl parsing wants to be done up front.
Then again, peer_cn is not used anywhere else so it may be fine to just delete this field from the structure.
An alternative is to populate peer_cn with the user requested field. [4] The configuration option would be in postgresql.conf and would reside in a global variable (similar to ssl_cert_file).
Any pointers would be great.
I could find a little history in the archives, but couldn't determine if any decisions or conclusions had been made.
Thanks,
Keenan
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