Web Services Data Encryption. If the web service provider wants the data being exchanged between the server and the clients to be protected from other users who may be “listening” then data encryption is necessary. To this aim there are different protocols and algorithms to encrypt the data. We are going to use as a proof of concept the Secure Socket Layer (SSL) protocol. SSL is a protocol that provides security for communications between client and server by implementing encrypted data and certificate based authentication. When SSL is configured instead of using HTTP the server will use the secured HTTPS protocol. Tomcat fully supports SSL and therefore it has a tutorial showing how to do that. This procedure can be different depending on the configuration of our Tomcat. We are not going to detail the whole process but we are going to describe it. SSL is based on certificates. The server needs to have a certificate to use SSL; this certificate needs to be certified by a Certification Authority (CA) if we want to be sure no other server can use a certificate to impersonate our server. When the certificate is generated and the server configured the system is ready to encrypt the data being send between the server and the clients. Having a certificate validated by a CA is not free and it costs around 70 € per month. Users can easily see if a certificate is validated by a CA in the web browser because the HTTPS turns green when the certificate is validated and red when it is not. WSPs interested in encryption should use the Tomcat documentation or consider using another server to carry the encryption task. They should also follow the instruction of the chosen CA (e.g. ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇) to have their server certificate to be validated. The last validation cycle performed at T23 validated the functionalities of the platform v2 and the integration of the components ready at that time. On the basis of the validation report and on the feedback received by validators, improvements and additions have been made to the platform v3. Below, we review the validation conclusions and the lessons learnt reported in D7.3 (section 2.7), mainly focussing on the problematic issues, and single out the tasks and efforts made to address those issues and to improve the platform functionalities. Overall, validation was very satisfactory as most of the requirements were fulfilled and the platform proved technically functional, realized its main technical expectations. Some weaknesses however emerged. In general, the weakest aspect of the platform in its second version seemed to be documentation, which had some gaps. In particular:
Appears in 2 contracts
Sources: Grant Agreement, Grant Agreement