CAS 3 switches to using Apache HttpClient. Shawn Bayren raises the concern that this removes the validation of SSL certificates:
>> - The switch to Jakarta Commons's HttpClient may have been a mistake;
>> at the very least, you need to drive the HttpClient code so that it
>> validates SSL certificates, as the old implementation did (by relying
>> on the Java API client's inherent behavior). If you don't do this –
>> i.e., as the code stands now, unless I'm overlooking a deep
>> configuration parameter somewhere – then nothing actually
>> authenticates the HTTPS service you're connecting to, letting it be
>> spoofed arbitrarily.
>>
>>
>>
> I'll check into this. I'm not 100% familiar with the HttpClient API either so I'll need to read up on it. Dmitriy may know more about the configuration stuff than I do though.
>
http://jakarta.apache.org/commons/httpclient/sslguide.html
maybe we should log this into JIRA rather than confluence so we don't forget?
Yes, agreed should be logged into JIRA. However, the resolution of this issue has as its deliverables not only an audit of the code, verification that it really is doing ssl cert validation, etc., – I'd also like it to have the deliverable of updating this Wiki page to document exactly what it is you have to do to make HttpClient properly do SSL, how we've done that in the code, and why we've made this change to use this client.
In the process of refactoring, I realized that we really aren't currently using the http abstraction that HttpClient offers. Therefore I've removed it as a requirement for CAS 3 server.
The same server authentication can occur without the HttpClient.
I can see for the Clients however that the abstraction may prove useful so a CAS 3 client may have a dependency.