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.
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.
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.
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've been trying to mug up on Glassfish and one thing that keeps coming up is the "how-to" on fronting Glassfish with Apache. Unfortunately, I have yet to find a description of why you would want to do this!
From my experimentation, Glassfish seems like a pretty fully featured web server-type service; but I might be missing a lot. So, is the notion of front-ending Glassfish more of a solution to integrate it with an existing architecture, or does front-ending (in a pure Java environment) provide extra benefits?
There's also another valid use case as to why we front Glassfish with Apache. Apache in this instance would function as a reverse proxy for increased security of your Glassfish. The RP is configured to allow only certain URLs to be passed through to the application server. For e.g., you may have app contexts /myApp and /myPrivApp deployed in Glassfish. In the RP server, you only configure /myApp to be passed to Glassfish. Anybody requesting for /myPrivApp would see a 404 'cos the request stops right at the RP level.
In one of my deployments, I have a bunch of WARs deployed, some for users coming from the internet, some for intranet only. I have 2 RPs running, one for internet users and the other for intranet. I configure the internet RP to only allow URLs for approved internet applications to pass through while intranet users get to see everything.
Hope that helps.
It is usually used to speed things up. Since apache is a very fast web server it is used to deliver static content. Like images, CSS files and so on. Glassfish serves the dynamic content (servlets, JSPs) in this scenario.
Another reason for using Apache as a frontend to Glassfish is the possibility to provide load balancing across a Glassfish cluster. See http://tiainen.sertik.net/2011/03/load-balancing-with-glassfish-31-and.html for details.
A other reason is that glassfish cannot run (easily) on port 80, without giving it root rights of course.
So, for most users it's easer to run a proxy (apache, nginx, varnish) some sort in front of apache and have both servers run under a normal user.
Then you have a other advantage of some configurations options of your front end. Like others mentioned, caching for example.
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