LDAP authentication in different J2EE servers is different, unfortunately.
Eg. If I develop a code in JBoss for LDAP authentication with LDAP login module of JBoss, 99% chances are that it will not run in WebSphere or any other J2EE containers. Maybe if I import that library jar files, it might work. I’m looking at just porting the application and not having to worry about library files, unless we have written the libraries. Libraries of J2EE servers must not be copied from one server to the other. I don’t know if that could be called code ethics!!
Is there a J2EE server independent module for LDAP or way of programming for doing this?
Is the solution – code from scratch using JNDI the only method? Please advice.
I'd suspect that most J2EE container already have an LDAP module for the authentication, in which case the problem you're having isn't really about programming, but about adapting the configuration from one container to another. Little to no actual code should be required for this. It's not clear why you would develop your own code for LDAP authentication then.
If you really want this configuration to be container independent, you'll certainly need to embed the authentication within the webapp itself.
The Restlet framework, for example, can do that, but it's part of a wider architectural choice, which may or may not be what you're after.
Even if you program your own LDAP code via JNDI or JAAS for example, you're likely to have to tweak the configuration of the container, perhaps for its security manager to let the connections to your LDAP server through (if enabled) or at least to configure which LDAP server to use when deploying the application.
I think in the general case, it's probably wiser to use the container's module (which will vary depending on the container). It ultimately depends on how you configure your webapps when deploying them.
Related
I am trying an application setup in JBOSS AS 7 and Struts 1.2.8.
We have a monstrous project which needs to be broken down into separate deployments so that we can micromanage different modules (i.e. do hot deploy or ONLY deploy the bits that need changes).
So there is a Portal - which has several modules inside it - and though the modules share some common functionality like interacting with some (not all) common databases and same ESB in the backend. However functionally all the modules are pretty independent. Hence we want to deploy a Common.war - which will have the Login page and will manage authentication and authorization. Then all other modules will be deployed on their own wars. Any common functionality like communication with Databases and ESB will be pushed to JNDI Datasources and Stateless EJBs.
Now say when a user logs in he will go to
https://myportal.com/login - this is hosted and serviced by the Common.war
Once logged in he will be stored in session and redirected to a url https://myportal.com/module1/action1
The 2nd url will be serviced by the war module1.war. Now when this Action tries to access the session and check if the user is the one who logged in - will it be able to access the session for Common.war deployment? Not too sure if a session will be per war or per application server. Any work around if not?
All common back end integration logic will be deployed as EJBs - so I guess that will be accessible by any war. Or is there a better alternative?
You have to introduce session replication and single-sign-on to have the different webapps to share the login (and other) information. I am not sure how you can do it on JBoss, I tried on Glassfish, it worked.
Maybe this link or that link could be useful.
Does the glassfish SSO implementation implement any standards? If so, which ones?
If I have a dependency on Glassfish SSO for my applications, will my applications be portable - will the SSO work if I deploy my applications to another web container such as tomcat?
Glassfish, like many (all?) containers, uses the concept of a Realm when working with container-based security. I don't know if there's a standard to define a Realm, but certainly code that we've written that delegates to the Realm runs in Tomcat, Glassfish and Jetty, and OSGi containers like Apache Karaf also have Realms that seem to be the same (but I haven't actually tried that one yet).
The SSO implementation is entirely on the container side - if several applications use the same realm, then you can configure the container to enable SSO across those applications. The fact that the Glassfish implementation of SSO is a tomcat valve is entirely hidden to the application - so long as the container supports realms, and can be configured to enable sso across applications using those realms, then the application is portable across any such container.
Caveat - this is all based on my (limited) real-world experience. I don't know how common Realms are, nor if there's any standards compliance between them. But for our use, they seem (so far) to be a reasonable, portable abstraction.
It seems that the GlassFish implementation is based on the Tomcat valve org.apache.catalina.authenticator.SingleSignOn and not on a Java/Java EE standard.
It should be possible to port applications to other app servers that are based on Tomcat, though I would recommend doing some tests first.
I'm migrating a lot of websites from Resin 3 to Tomcat 7 (centos 4/apache 2.20) and I'm struggling to determine what type of configuration matches my requirements. In particular:
proxy_ajp vs mod_jk vs mod_proxy for passing requests to Tomcat/Railo
automating deployment of new sites
putting WEB-INF outside the site roots (to simplify cloning sites)
using apache itk with tomcat so each vhost runs as a different user and process
having a single shared railo server administrator config
support for SES URLs with no extension (ie: /path/to/page)
SSL support required
I've read a lot of howtos already but most are out of date or provide conflicting advice. I would like to see some examples from people who run many railo vhosts and deploy them automatically or programmatically. In general I'd prefer efficiency/speed over simplicity as I want to get the most out of limited resources.
I could have asked these questions separately but I want to be sure any answers take into account all the above factors (assuming the requirements are actually compatible).
firstly, check out the vivotech installers - they are a hosting company, so use their installers as your base, they are flawless. (it uses tomcat)
railo 3.3 makes it a lot easier to deploy contexts from admin, so scripting this shouldn't be that hard.
web-inf should be automatically put into a site when it is defined in tomcat
if you give each user a new context-root, then they will have their own admin
every webserver (apache/iis2k8/even tomcat) supports url-rewrite
everything supports ssl
you might also want to look at how you're going to tune your jvm's for this senario, then do some load testing to see how they fare.
drop an email to sean corfield, google railo and his name and you'll get his email.
When testing various authentication solutions (my own LoginModule etc) in JBoss, it seemed to me that sometimes when I redeployed a change or otherwise provoked the login form to show, that JBoss didn't actually call the authentication module.
Just wondering if there is some type of short term caching going on?
I tested both from a web application (taking care to delete cookies etc) and from a fat RMI java client.
Of course, If I restarted JBoss, the full authentication process was followed.
Is there a cache, and if so, can it be disabled for development purposes?
Yes, JBoss caches authentication information by default for a few minutes.
To disable caching, set DefaultCacheTimeout to 0 in the configuration for the JaasSecurityManagerService. The configuration is in the "jboss-service.xml" file.
For more info and various ways to flush the cache, see CachingLoginCredentials at jboss.org.
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