I am wondering if there is a solution to my problem. As a summary, I need a non-intrusive Web response cache for users that authenticate via a client certificate and are authorised to see URLs based on that.
I have a JEE application and I would like to cache responses to Web requests. I am trying to do it as transparent as possible (ie. without messing with the code), so I found Squid.
My problem is that users might authenticate themselves via a client certificate (or the absence of it) getting authorisation based on this, and this is what makes things "difficult". Is there a way to configure Squid, or any other software, to cache the results after the communication has been established by Tomcat? Something like a cache that is triggered by my application right after the TLS handshake is over and Shiro has been called (because user permissions depend on their certificate). The fact that users have to be authorised by my app make me think that the only way is to create Java code for this, not using Squid or similar software transparently.
I am sure this is a problem that has happened before.
I want to access a REST service from Java. The service runs under Windows and uses probably a "default" authentication mechanism. I was told it was Kerberos with a fallback to NTLM. I am able to access the service by a plain HTTPS GET request using Firefox (works with HttpRequester, too) - without specifying any credentials explicitely (obviously my Windows account is used).
How can I access the service from Java? A naive attempt to read using java.net.URL fails with status code 400.
Even the JDK (JVM implementation of Oracle) offers this, you may have a look at https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/lab/part6.html
This provides the high-level steps for the solution. You'll need Active Directory in order to leverage Kerberos with Windows. Then what you will do is use Java Spring Security for Kerberos in order to access the REST service from Java. The below are the more concrete steps.
The Java Spring Security for Kerberos library will do the heavy lifting for you, this provides a class to inject a Kerberos configuration into the HTTP client: org.springframework.security.kerberos.client.KerberosRestTemplate
You define some Kerberos properties within a client configuration .properties file. Here's the most important snippet from the file with respect to Kerberos:
KERBEROS.FLAG=Y
KERBEROS.DEBUG=true
SERVICE_ACCOUNT_PRINCIPAL = HTTP/some.hostname#YOUR.REALM
KEYTAB_LOCATION = file:///C:/path/to/filename.keytab
KDC = server.fqdn.name
KDC_DOMAIN = YOUR.REALM
KRB5 = file:///C:/path/to/krb5.conf
EDIT:
Kerberos keytabs are not required with a Java client on a Windows AD domain-joined machine. Since you want to use the credentials of the person who is running the Java program, you wouldn't use a keytab (since the keytab itself contains only one credential).
Refer to the official Spring Security Website
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?
My project is an Android application that communicates with a server. The server is written in Java, deployed in Tomcat, and running on a Windows Server host.
I need to provide authentication against Windows domain accounts. Basically I need to ask the user of the app to type in their username and password; send this data to the Tomcat server; and have the server authenticate it.
I'm having trouble finding a straight answer as to how to do this. Since my app is not a web site, I don't have the option to do browser redirects or anything like that, and obviously the Android device on which the app runs is not a Windows machine and will most likely not even be on the local network.
I don't really need to execute anything as the Windows user, I just need to know that they are who they say they are. Hopefully there is a simple way to do this?
Thanks.
Assuming you want to use Java EE container-based form authentication, on the server you'll have to:
secure your web application
configure Tomcat to use Windows authentication
On the client, you can:
POST application/x-www-form-urlencoded login data with the special keys in the web form (j_password, etc.)
retain the session cookies in the response for subsequent interactions with the server
I haven't tested the specifics with these exact technologies but approach is sound.
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).