I'm looking for the best approach to achieve SPNEGO/Kerberos login for a spring-security application on Tomcat and Windows. Candidates i've looked at:
Spring Security Kerberos Extension
Waffle
Apache httpd fronting with mod_auth_kerb module
Apache httpd with mod_auth_sspi module
I wasn't super-impressed by Waffle and mod_auth_sspi only seems to support NTLMv1 so that is out. I do see a value in fronting with an Apache httpd so that seems like a good approach. How well does that play with spring-security though, I wonder. Who has done this? Which is the best/most stable approach?
Don't do any overhead. Use the Spring SEC Extension. That one works quite well on our environment for more than a year. Though it has the potention for some improvement.
Related
Looking at the CKAN deployment documentation, there are several web server options:
Apache with the modwsgi Apache module proxied with Nginx for caching
Apache with the modwsgi Apache module
Apache with paster and reverse proxy
Nginx with paster and reverse proxy
Nginx with uwsgi
I'm wondering what the merits are of using Apache/modwsgi over Nginx/uwsgi, and how much value Nginx's proxying adds.
The core question, I guess, is if I wanted to avoid using two separate web servers in a single installation, what should I consider when choosing one or the other?
The CKAN Tech Team document one particular config: apache/modwsgi + nginx reverse proxy. They encourage people to use that, so that when difficulties occur we can fix them as a community.
I'm not clued up enough to give technical arguments between uwsgi and modwsgi. I think there are some CKAN sites on uwsgi and it being more modern there may be some technical advantages. However the installs I've worked with have mostly been apache/modwsgi + nginx reverse proxy. That's probably more down to familiarity and the blessing of the CKAN tech team than anything else.
However I believe nginx is better than apache2 for SSL/TLS termination. We found it was far simpler to configure SSL/TLS, with plenty of new best practices to keep up with in the past few years. And last time I looked several years ago there was an argument that the asynchronous design avoided e.g. slow loris attacks. So I think having nginx on your front-end makes a lot of sense.
You suggest having two HTTP servers is too much, but I think nginx is pretty low overhead and isn't usually a concern.
paster is a toy - no-one uses it for servers.
I am learning Erlang and found out it contains httpd which I managed to configure and make serve to my needs for creating an API service.
I know there are other solutions like mochiweb and Cowboy which must be undoubtedly great choice but I want to begin lean and bare bones.
When I decide to release my project, will it be a good plan to use Erlang's httpd regarding performance and HTTP features like HTTPS, HTTP/2, performance, or should I choose another server?
httpd is powerful webserver and a perfectly valid choice for production, as long as it fits your needs. I think the main reason to go for other alternative webservers is that you find that some functionality is missing in httpd that you find somewhere else. For example, I don't think httpd supports websockets, however websockets are supported by for instance cowboy and yaws.
When I decide to release my project, will it be a good plan to use
Erlang's httpd regarding performance and HTTP features like HTTPS,
HTTP/2, performance, or should I choose another server?
I can't find any benchmarks comparing httpd with the other solutions that you mention, like cowboy and mochiweb, but I've not heard any complaints about the peformance of httpd and I would guess that it's as good as cowboy and mochiweb for production. The fact that it's shipped with the erlang language is a good reason for assuming that the code is performant and battle-tested, if you want to go in depth you can always:
look at the source: https://github.com/erlang/otp.
Make your own benchmarks.
I need PHP for UI coding and I'll be making AJAX requests to a Java backend. I've never deployed two servers before. I'll need Apache for PHP and Tomcat for Java.
How can I do this?
You can run php through Tomcat as it is based on Apache. Here is a pretty simple tutorial to do so. http://nexus.zteo.com/2008/02/15/how-to-setup-php5-with-tomcat-5/
One possibility is to run a PHP interpreter written in Java directly in Tomcat and there is an open-source one called Quercus.
Well you can run both servers seperately but that would mean, that Tomcat will have to run on another port. You can also setup PHP with Tomcat as a CGI Script as already mentioned but I don't know if that'll offer the best performance.
In my experience the best way is to connect Tomcat with Apache is via mod_jk conenctor. You just have to tell Apache which pages to redirect to the Tomcat Server running behind it. Since you didn't give more information about your system environment I could only give you the link to the general documentation.
I have been looking around to figure out how to configure Glassfish front ended with Apache. And most of the tutorials using the load balancing plug in is making me enable SSL on Apache. I am trying to understand the connection. I should be able to do non SSL communications when I dont have a need for SSL.
There are several blog posts showing how you can use Apache in front of Glassfish. There are several options and depending on your needs, different strategies might be the most appropriate.
I've used Apache with mod_jk which forwards requests to Glassfish - both https and regular http. Lots of good references here.
It's possible to use other modules in Apache also like mod_proxy, but again the requirements you have will flesh out the most appropriate.
Glassfish also have pretty good http engine inside of it where you can configure virtual hosts like in apache. If the load on the Glassfish server isn't to big, you might consider just using Glassfish without anything in front of it.
You can also use the Sun Java System Web Server SJSWS instead of Apache. Despite it's atrocious name, it is just Sun's web server (free to use). It can be used as a reverse proxy (PDF). The SJWS/Glassfish combination is presumably tested really well by Sun.
I have a J2EE-based system which is running currently on Apache Tomcat. We are in discussions to move our production servers to the Glassfish server.
Can someone share their experiences with either of them?
They are not really comparable.
Apache Tomcat is not a J2EE Server. It's merely a Servlet Container for Web-Applications. Nothing more. If you need J2EE API implementations, you have to take those from elsewhere. For example by using the Apache Geronimo Server which uses Tomcat as its container, or by taking the JAR files from Glassfish.
Glassfish is a complete Java Application Server with implementation for APIs like JPA, EJBs and more. Glassfish contains a Servlet Engine initially used by Tomcat, but they improved it (don't know what exactly). More recent glassfish servers use another container using grizzly which uses the NIO API for input/output and scales quite well. As far as i know, the Glassfish Servlet Engine is more performant. Here i've found a nice benchmark (it's a bit old though):
http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
Here's quite an old comparison. As such, the capabilities of each server have doubtless improved.
Edit: Here is a current comparison.
Both are more than stable enough for production use though. It's really going to come down to features.
Big question is: why? What do you think you need that Glassfish will provide you over Tomcat or Jetty? Management utilities perhaps?
Most things you want beyond basic servlet container are easily pluggable.
So while Glassfish is fine as is, there is no point in moving "just because". Most production services I have built are on plain old servlet containers, using none of implementation-specific features.
This may be a little dated and maybe even a little biased, but it's from Oracle. You can skip down to the section for comparing Glass Fish to Tom Cat
http://java.sun.com/developer/technicalArticles/glassfish/GFandMySQL_Part1.html