From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Marc-André Laverdière <marc-andre(at)atc(dot)tcs(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Support for cert auth in JDBC |
Date: | 2011-05-19 05:58:31 |
Message-ID: | 4DD4B187.6080002@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 05/18/2011 03:48 PM, Marc-André Laverdière wrote:
> It is true that anyone who knows the right Java APIs can put that
> factory together with little pain. I just think that the average user
> shouldn't have to bother about it.
>
> Also, some use cases do not allow to use the default keystore and trust
> store for everything.
I agree, and I think you're right that the PgJDBC code should have a
re-usable class to provide support for these use cases without everyone
having to code their own.
I've taken your code and re-worked it a bit to:
- Use the PgJDBC WrappedFactory rather than re-implementing an
effectively identical one;
- Separate the basic construction process of the SSLSocketFactory
from its configuration, providing an abstract superclass that does
the construction via a few simple method calls, so someone who needs
different configuration sources/methods can re-use the code;
- Provided a concrete subclass of the above that gets its configuration
from system properties and uses the superclass methods to construct
the factory. This class has the same functionality as what you posted
originally plus a few additional configuration options for additional
use cases like non-default KeyStore types (pkcs12 etc); and
- Added more extensive JavaDoc
It's also possible to pass your own KeyStore and/or TrustStore instances
directly if your app has to do something funky like manage an in-memory
KeyStore.
What I haven't done yet is tested it! This is a preview so you can
comment on it and tell me if you think I've gone completely off the
rails or not.
The simplest uses of the code remain as simple as they were with your
original version. You just set some system properties and specify
SysPropCertAuthFactory as the sslsocketfactory class. More complex use
cases become possible without having to re-implement the whole lot - in
particular, if you can't fetch your configuration from system properties
you can provide alternative mechanisms to look it up without having to
re-write all the JSSE crap.
So: thanks VERY much for posting this code. My original demos weren't
flexible enough to be included in PgJDBC, and by posting this you really
helped motivate me to try to turn your code and my original demoes into
something that _was_.
What do you think? Note that you'll need PgJDBC on your classpath to
complile this now, because it uses org.postgresql.ssl.WrappedFactory .
--
Craig Ringer
Attachment | Content-Type | Size |
---|---|---|
AbstractCertAuthFactory.java | text/plain | 7.3 KB |
SysPropCertAuthFactory.java | text/plain | 5.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc-André Laverdière | 2011-05-19 06:14:13 | Re: Support for cert auth in JDBC |
Previous Message | Craig Ringer | 2011-05-19 05:46:57 | Re: Support for cert auth in JDBC |