Re: Support for cert auth in 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