users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Client security configuration proposal for JAX-RS 2.0

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 6 Feb 2013 16:26:41 +0100

On Feb 6, 2013, at 2:44 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 2/5/2013 6:55 PM, Marek Potociar wrote:
>> Hello experts,
>>
>> I made another stab at this one. Please review:
>>
>> https://github.com/mpotociar/jax-rs/commit/00b33d12245849ac967cbb129daa09fcb008ddd6
>>
>> Here's the change summary:
>>
>> - ClientFactory merged with and renamed to ClientBuilder.
>> - Added new security-related setters to ClientBuilder (sslContext,
>> keyStore, trustStore, hostnameVerifier).
>> - The new ClientBuilder now implements Configurable.
>> - Added ClientBuilder.newBuilder() static method.
>> - Updated examples and javadoc references to ClientFactory.
>>
>
> Thank you.
>
> Javadoc suggestion for keystore()
>
> Append this:
>
> "This
> config setting is only required if you want to enable 2-way SSL connections (client cert authentication)."

Done.

>
> Javadoc suggestion for truststore()
>
> Append this:
>
> "If you do not set the truststore or disable trust management, then trust management reverts to JDK defaults."

Done (except for the disable part).
 
>
>> I have to say that I went as far as I could go. Clarifications, javadoc
>> fixes, typos, method renames and similar comments and suggestions are,
>> of course, always welcome. But, please, do not try to sneak any more
>> features into this proposal (esp. not related to SSL), otherwise I may
>> be inclined to go with the "not have it at all" option...
>>
>
> This was in my original proposal so I need to hightlight it again....

FWIW, I am quite familiar with your proposal. If I chose to not include something from your code, it does not necessarily indicate I would not read and consider your code carefully.

>
> There are many instances where users just want/need to communicate over SSL and don't care about trust management or they just don't have access to the certificates they want to trust. I can't stress enough how often this occurs! Its actually quite complicated to set up SSL to disable trust management. So I strongly suggest adding this capability.
>
> /**
> * Calling this method will disable SSL trust management
> * and hostname verification. <i>NOTE</i> this
> * is a security hole and should only be applied for testing purposes
> * and situations when you cannot or do not care to verify the identity
> * of the host you are communicating with.
> */
> ClientBuilder disableTrustManagement()

I think that the functionality above is a better fit for a test client API and does not belong into official JAX-RS API. A simple utility can construct an appropriate SSL context that you can pass to the client builder. I'm against adding the method unless there is a much stronger support in EG for it. That's btw. the reason why I may seem to have ignored this feature. Perhaps I should have elaborated more on why the feature was omitted.

>
>> Please, send your feedback by Thursday CoB.
>>
>
> So, the experts work is done CoB Thursday?

I'm not completely sure, but let's assume the above is not meant to be another sarcasm remark. In which case, no, the work of this EG is not done on Thursday CoB. I'm talking about this particular feature proposal. With all the renames and API additions, from a user perspective it is a quite significant API update. As all the other Java EE 7 specifications, we are supposed to be feature-complete by Friday, Feb 08. So I would like to make sure JAX-RS 2.0 makes this deadline. Once we're feature complete, the EG should stop trying to introduce new features and APIs and focus on clean up and fixing issues in the set of features and APIs that has been proposed so far in order to prepare for PFD submission which is scheduled for Feb 20.

Marek

>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com