I want to host REST APIs over https. REST web services will be written in java probably using spring framework.
These web services will be accessed by java clients (not web browsers), probably using org.apache.http lib.
I am not getting clear picture of working with SSL certificates.
My questions are -
What configurations will be required to host REST web services over "https"?
What configurations will be required at client side for accessing these "https" URIs?
Do I need to buy trusted SSL certificate for REST server or open java keygen will do?
Do I need the same/different certificate copy on REST client too?
No particular configuration, you just need https activated.
No particular configuration, you just need to take care to use libs that check the certificate.
If you write the client, you can use a self signed one, and customize the client to check if it's your certificate. If anybody can write a client, it's better to have a publicly trusted certificate. WARNING : the free let's encrypt certificate are NOT trusted by java !
Why do you want a certificate on your client ?
Side note: if your API is publicly accessible, I strongly advise you do NOT redirect http to HTTPS but instead makes HTTP systematically answer an error. If you don't do so, a developer that use by mistake the http will NOT see the error and that will create security risks.
I have a question about whether I really need SSL or not. The scenario is as follows:
I have two applications at the moment, they are both Java webapps. One of them is getting data from another via RESTful web service secured by Spring Security, but my problem is that it sends username and password in URL so the other app can authenticate and authorize it using LDAP. In the end both apps will be running on JBoss AS 7 server so even though one of them is a client and the other one is server they will be running on one server and that confuses me a little bit (even if they will use multiple instances of JBoss they will still be both in the same network). Also signing certificate by third party seems unnecessary here because I don't really care if anyone will trust my server app and again I found that I can implement my own Certificate Authority but it really seems to me as an overkill.
So to summarize it: if I only care about request (or just its parts - username and password) being encrypted do I need to enable SSL and provide all it needs or is there any easier way to achieve it?
I need to connect to a MySQL database from a java Desktop application. The way I was planning on doing this, was using HTTP to open a php page on my website, that PHP script will handle all the mysql stuff so my MySQL user/pass is not accessable to the client at all. so, my question is, would SSL be required? and also, how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
This should probably be on the security site, but anyway.
If you don't want everything you send to the database to be visible to the world, use SSL.
Force the client to authenticate to your server side script before making any changes to the database if you don't want anyone in the world making changes.
Make sure that SQL injection is prevented.
Why wouldn't you just use MySQL user authentication with SSL? Writing your own bridge sounds like it would only cause problems and expose more security holes than you'd otherwise have.
so, my question is, would SSL be required?
SSL helps provide a layer of security, through encryption, which keeps people from hijacking the connection and intercepting what you send (for more information, see: Firesheep). Therefore, while not required, per se, it is recommended. If you have control over the Java app, and depending on your purposes (namely, an in-house application), then you can use a self-signed certificate and package the cert with the app for verification purposes (see: this SO question for more info on self-signed vs CA SSL certs).
how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
As with other Information Security things, nothing is 100% guaranteed, but the most common way to do this would be via an API key, especially since what you're describing is an API.
If you're looking for a quick-and-dirty setup, then you can use HTTP Basic Authentication to send some credentials, and use SSL to secure it. For a more robust solution, you'll probably want to look into HTTP Digest Authentication and/or OAuth. What you use will also depend on your specific needs.
You can then code the API key into the Java app, or create a way of generating and requesting API keys (again, depends on your specific purposes and needs), and the client sends the API key with the request. If the key doesn't match what you have "on file", then you deny the request.
A quick note on using an API vs connecting to MySQL directly
A couple of people brought up connecting to MySQL directly. I think this is a valid option, but will depend largely on what you're doing and who you're distributing to (and, for that matter, whether you want to open that database to other clients).
If you have plans to have other clients (such as mobile devices) connecting to this database, or if you don't have control of the database for whatever reason (ie - your hosting setup won't allow you to make remote access available), then it might prove useful in the long run to build an API.
However, if you have no such plans, or do have full control of the database, and you control the source code of the Java application, then directly connecting to the MySQL database is a valid option. Just make sure you follow the principle of least access - the Java application gets a dedicated MySQL user that only has the permissions that are absolutely necessary - and the Java application user has a strong password (and since no humans are involved in this process after you code it, you can use a password generator to create something long and convoluted and completely random).
i have a two web applications running in java wih weblogic server, both the applications have same user name and password, so i decided to use single sign on machanism for sharing the session.
Apart from openSSO configuration, policy agent installation, i have to write java code for redirect the particular page from one application to another application.
if anyone already implemented the single sign on with java, please send me java the part to control the user authentication.
If OpenSSO is setup properly for both the weblogic instances, you can just redirect from one application to the other, you don't have to do anything else.
I have a Java Web Start Application which communicates against my server via a web service (over https).
I want to restrict the usage of the webservice to my app only, so that 3rd party apps don't work.
What strategies to I have? This question is somewhat broad, but running in JWS disables some options, like doing a checksum over all jars (at least I don't know a way of doing this in a JWS environment).
I can always implement my own auth scheme, but since the client code is on the client-side, one can always disassemble the class files and crack the auth mechanism.
Remember that if the client is communicating with the server over https, the user can easily replace the JWS client with something else that also communicates over https. Anything the JWS client could sent to "prove" its identity could be faked pretty easily. You could use client certificates (or numerous other types of authentication) to make sure only users with access to the JWS client could connect, but they will always be able to extract what they need from the JWS client to connect with something else.
The service needs to be secured based on what the user should be allowed to do.