Here is an extract which I by a coincidence posted in this topic the day before yesterday, you may find it useful:
You normally use the HttpSession to maintain a logged in user. You can set its timeout in the web.xml. The default timeout is 30 minutes. When an user logs in successfully, you set the representing User object (or some other key indicating a logged in user) in the session. When an user logs out, you simply invalidate the session so that the user can continue with a fresh start. Or you just let the session expire which automatically logs out the user. The HttpSession attributes are accessible by ExternalContext#getSessionMap(). The HttpSession itself is available by ExternalContext#getSession(). Alternatively you can also declare a session scoped managed bean, e.g. UserSession, which holds an User property indicating the logged in User.
You may find this article useful as well: http://balusc.blogspot.com/2007/03/user-session-filter.html It might look hard and lengthy, but if you don't care about the login being lost after a session timeout, then you can leave the UserSessionFilter and the persisting of the UserSession in the database using UserSessionDAO away if you want. Just carefully read the article text and the code (comments!!) to understand what's going on.
I've seen a number of Do-it-Yourself security systems in Java webapps over the years. They pretty much all stink. At best, they make life difficult for maintenance people, since they have to be manually coded into what should properly be display and business logic. Failing to do so properly even once opens up your system to exploitation.
At worst, you end up with something that requires major application changes if the security system changes, almost never works in a single-signon environment (especially portals and portlets), carries several other liabilities that I could enumerate, and almost always has some fatal security hole at its core.
I am this very day, in fact attempting to mitigate the damage that came from people designing such a system, having just spent 6 weeks berating another group for the weaknesses in theirs.
The J2EE builtin security isn't a cure for everything, but it can handle just about every situation I've seen in common use. Because it acts as a wrap-around gatekeeper, you can debug the app without having to debug the security at the same time. Because it surrounds the app, it guards the entrances to all functions, not just the ones you remember to guard. Because it's primarily declarative, "logic" errors are greatly reduced, since it's much easier to automate the vetting process.
J2EE container-based security is a standard. So when you want to sell your app as a third-party-product, you don't have to worry about whether it's going to fit well in someone else's environment. Because the realms are part of the container environment, the administration and integration are simpler. Because it's pluggable, you can use your own security environment (such as a tomcat-users.xml file) for testing and be assured that the same app will work unmodified in your Active-Directory authenticated production system. Because it's a standard, new people on the team don't have to learn it - it's already in their books.
Also, the hooks for J2EE security are built into many common products, including Struts, some of the JSF packages, etc. You don't have to ugly-up your pages in order to limit the content of pages based on security requirements.
The most compelling reason of all, however, is the difference between "clever" people and people for whom paranoia is a full-time paying job. The J2EE standards were designed by groups of people whose main task was to look full time for possible exploits and head them off while providing maximum functionality, not ram something in while their main task was getting an app out the door, or even a committee of people who think they can do a better job but have never had formal training in mathematical proofs of security.
JSF is one of the more challenging environments for J2EE container security thanks to the funny URLs, but it can be done - I've put a number of such systems into production over the last 3-4 years and never once felt the need to forgo container-based security over a roll-my-own system.
Spring is popular these days because it does for application logic what J2EE Container-Based Security does for authentication and authorization. Both allow you to reduce the dependency of your application code on direct dependence on the services that they wrap, and in the process, reduce coding. Which boosts productivity and reliability.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jun 19, 2008
Thanks a lot Bauke for providing the detailed explanation .
Now I am able to get a handle to the session in the backed up bean using ::
I still have a couple of doubts ::
In struts I can prevent all incoming requests from directly accessing any JSP pages All my action classes extend from a common authenticator action class which checks whether the user exists on the session or not .
So what I understand is that by making use of the filter I could do the same .
On second thoughts what I was doing in struts was also a good candidate for filters !
There are still a few things I dont understand that I need to read and understand :: what a phase listener is and why we should use it Need to understand the phase events ::Restore View, Apply Request Values, Process Validation, Update Model Values, Invoke Application, and Render Response.
about to post my reply and realised that Tim has also replied .
I agree with what you say Tim as regards to avoiding writing custom security validators . My only point is if a fresher were to directly work in jsf / container security - it would go way over his / her head .
For starters dabbling in Http objects and understanding the concepts and only then progressing further is my way of doing things ( not in production code but self learning examples )
That is no justification to write custom security code but for self learning - thats the way to go .