Re: Support for cert auth in JDBC - Mailing list pgsql-jdbc
From | Marc-André Laverdière |
---|---|
Subject | Re: Support for cert auth in JDBC |
Date | |
Msg-id | 4DD4BB85.4070300@atc.tcs.com Whole thread Raw |
In response to | Re: Support for cert auth in JDBC (Craig Ringer <craig@postnewspapers.com.au>) |
Responses |
Re: Support for cert auth in JDBC
(Craig Ringer <craig@postnewspapers.com.au>)
|
List | pgsql-jdbc |
Hello, Thanks for the changes. It is a good step forward in terms of extensibility. That being said, I think we could just put a lot of the loading code in AbstractCertAuthFactory, so that it is more reusable. There was a tiny bug in SysPropCertAuthFactory whereas a path was sent instead of a password. I'm attaching the fix. I also added the code that allows to load both PKCS12 and JKS blindly. I think that we can remove the property for specifying the type. I doubt we have to worry about other types of keystores than those two. I'm also adding the slightly modified tester which uses the right class. Regards, Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On Thursday 19 May 2011 11:28 AM, Craig Ringer wrote: > 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
pgsql-jdbc by date: