From: | "keenan(at)thebrocks(dot)net" <keenan(at)thebrocks(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Authenticating from SSL certificates |
Date: | 2015-04-22 05:32:55 |
Message-ID: | CAP+QC2yNgHbxt+avJ0L130V9Jw9EPbvG78rxZPXDUeg08wZsjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
[1]: http://www.postgresql.org/docs/9.4/static/auth-methods.html#AUTH-CERT
[2]:
https://github.com/postgres/postgres/blob/b0a738f428ca4e52695c0f019c1560c64cc59aef/contrib/sslinfo/sslinfo.c#L171-L192
[3]:
https://github.com/postgres/postgres/blob/b0a738f428ca4e52695c0f019c1560c64cc59aef/src/backend/libpq/auth.c#L2153
[4]:
https://github.com/postgres/postgres/blob/b0a738f428ca4e52695c0f019c1560c64cc59aef/src/backend/libpq/be-secure-openssl.c#L428-L445
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-04-22 06:17:59 | Re: Streaming replication and WAL archive interactions |
Previous Message | Kouhei Kaigai | 2015-04-22 02:33:50 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |