You have a lot to learn, Ganesh. I'll see what I can do, but you might want to find a good book or two. One of the better treatments of this topic I have is the Professional
JSP, 2nd Edition from Wrox, but Wrox went out of business several years ago, so I don't know what a good choice that's newer is.
There is no login servlet when you control security with web.xml. The login process is done entirely by the server (Tomcat, in this particular case). The URL pattern isn't where you send stuff, it's what stuff sends you to login.
The advantage of container-managed security is it sits at the front of the webapp like a big mean dog and only lets you pass if you make it happy. There aren't any back doors, because the metaphorical house is owned by Tomcat. Like I said, that's good, since a lot of Do-It-Yourself security systems are practically nothing
but back door. They assume you'll only come in through the entrance. They're wrong.
When Tomcat starts up a web application, it reads a number of items from the web.xml file and stores them in its application context for its own use. That includes the security rules, roles, URL mappings, locations of the login, loginfail and hello pages, as well as other things not interesting here.
So when you send a request to Tomcat, one of the things it does is look for security URL patterns and attempt to match the current request's URL to them.
If a match is made, Tomcat checks to see if a security context for that user has previously been established. If so, the URL request proceeds normally.
If there is a match but no security context, then Tomcat places the incoming URL request "on hold". It takes the location of the login page from the application's web.xml information and presents the login form back to the client. I'm assuming form-based logins here, of course.
The client (user) then fills in the login form and sends the login request back to Tomcat. Because this is the login form, it doesn't get sent to the web application, it gets sent to the login subsystem built into Tomcat itself. That subsystem extracts the userid and password and sends them on to the security Realm module that was configured for that webapp. The Realm allows or denies the authentication (logon request). If the request is denied, the loginfail page is displayed - it can also be a login form if you like.
If the request is authenticated, a UserPrincipal object is constructed to hold the user's security context and it's bound to the user's HttpSession object so that it will be remembered on subsequent requests. Tomcat will then retrieve the original application URL request that it had put aside ("on hold") and proceed to send it to the web application.
So, in other words, no user code does login processing, and no user code gets control at all once you've made a secured request until the user has successfully authenticated.
And, no explicit event shows that the user was just logged in. Which is why I used a servlet filter.
Servlet filters can be used to examine (and change) URL requests. In my case, I made a servlet filter that discarded the user's original URL and invoked a "home page" URL of its own choosing when the transition from un-authenticated to authenticated mode was detected. Since there's no callback to support that, I simply looked for the point when the request UserPrincipal stopped being a null object.
It's not really that hard to understand J2EE container-managed security, but the critical thing to realize is that it's a
declared mechanism, not a programmed one. The primary security functions are part of Tomcat, not part of your application code. That means that you can't write a "login servlet" or callback or anything like that.
The post-login redirection is another matter. However, for that you need to understand how servlet filters are implemented.
