Hi Brian,
Thanks for your reply. I wish I had held off until Friday before posting my question because a lot of different discussions have taken place at work about the nature of J2EE security within a Solaris environment. I think, at bottom, the security model our sysadmin wants to put into place is at odds with the security model that Java has in place.
The following is a letter I posted for our sysadmin on our internal discussion forum:
=======> Letter Starts Here <========
Hi <SysAdmin>,
I kind of look at the security features of web containers this way: Java security is based on the premise that everything running within a JVM is 'safe' while everything coming in and out of the JVM is considered 'unsafe' and needs to be handled by the default Security Manager run by the JVM at the time of execution.
Looking at it this way, JBoss serves a number of roles - EJB Container and
Servlet Container among others. Because Java's security mechanism still applies, however, everything coming in and going out of JBoss HAS to be handled by the default Security Manager in place -- otherwise Java's fundamental security policy is compromised. In the case of J2EE development, the Manager is a little more complex and involves XML configuration files among other things.
I think it's because of the premise that everything outside the JVM is unsafe and has to be handled by a Java Security Manager, that authentication has been given to the web container to perform. Why? Apache runs outside the Java JVM and is considered unsafe. I think it is partly because of this that JBoss has evolved to take on the role of HTTP server -- to keep things within the Java VM as it were. This is not just a problem with JBoss, but a problem with other EJB Containers as well -- Orion is a prime example as is iPlanet and the other big players.
What I find really interesting about this explanation is that your desire to keep security in the hands of the the physical server (the embodied VM we're running on), is the same desire that Java has to keep security in the hands of the JVM. The problem is, the JVM is itself a server that runs on another server and issues of policy and ownership are coming into conflict.
My two cents worth.
Darryl
========> Letter stops here <========
One of the driving concerns of our Sysadmin as I found out after posting my letter on JavaRanch was to link authentication to a single HTTP gateway (namely Apache) in order to maximize control and security over incoming and outgoing traffic. Since JBoss doesn't implement security in this way, I (as a developer) was left wondering why I needed to proxy authentication requests through Apache, and the Sysadmin was left wondering how to implement security JBoss seemed to circumvent Apache authentication.
Our Sysadmin has just posted a letter on our discussion
thread that I will post here:
========> Letter starts here <========
OK, I have done my research and you can just assume that Apache will have nothing to do with the authentication or authorization of requests for JBoss webapps. Even if Apache is involve it will be little more than passing the HTTP request straight to Jetty. This simplifies our discussions on "auth" substantially.
Technically its true that the method I suggested previously will work. Using an AJP connector, Apache could pass Jetty/JBoss the authenticated name of the user making the HTTP request. So, technically Apache could do all the authentication (via mod_auth_ldap) however I see little advantage in it unless we have non-JBoss webapps that need to be accessed by the same users as our JBoss webapps. If we do have both JBoss and non-JBoss webapps that need to be used by the same group of authenticating users, then we have to let Apache do the auth, or make the user login twice (once to JBoss and once to non-JBoss apps).
Further reading shows that JBoss started with the goal of being an EJB container but no longer holds that as a goal. JBoss claims to be a Web-based Operating System. Being an EJB container is just one small part of that. I will not be so bold as to criticise this products ability to be a WebOS. It still frustrates me that this product is choosen by many because it is an open-source EJB container but that we are forced to take Jetty with it.
What does this mean in to us? It means there is no point in pursuing Apache/JBoss integration. JBoss' is wedded to Jetty. There are configurations that are usable that use JBoss/Tomcat/Apache (via mod_jk) but there are not substantially different than a configuration that uses JBoss/Jetty/Apache (via mod_jk).
========> Letter stops here <========
Anyway, I will stop here. I just wanted to share the fruits of our internal discussion regard Apache / JBoss / LDAP authentication. Since I am now free to authenticate against LDAP directly, I will be using JBoss' JAAS/LDAP features.
Thanks everyone,
Darryl
[ October 20, 2002: Message edited by: Darryl A. J. Staflund ]