RE: Help/Examples setting up security settings
Ah-ha! Everything I had read so far led me to think I needed to put everything under ROOT. I'm glad you guys pointed that out. It makes sense. In the meantime, to make things simpler, I set up another webapp without any of the SPID stuff I was talking about before. It's very simple and contains nothing more than a login page (login.jsp) and login error page (login_error.html), the environment page (environment.jsp) I mentioned before and an error page (error.jsp), specified in the errorPage attribute of the page directive of the JSP files. The new app. sits in [tomcat]\webapps\Simple_JSP (not under ROOT any more) and the web.xml file in the WEB-INF subdirectory has been set up to use the correct path. I also included the security-role element Frank mentioned below. The web-app portion of web.xml looks like this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameSimple JSP/display-name descriptionSimple JSP Test/description login-config auth-methodFORM/auth-method form-login-config form-login-page/Simple_JSP/login.jsp/form-login-page form-error-page/Simple_JSP/login_error.html/form-error-page /form-login-config /login-config security-role descriptionSecurity Role/description role-namesimple_jsp/role-name /security-role security-constraint web-resource-collection web-resource-nameSimple JSP Test/web-resource-name url-pattern/Simple_JSP/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namesimple_jsp/role-name /auth-constraint /security-constraint /web-app Of course, I set up the simple_jsp role in the tomcat-users.xml file and added that role to my user entry. Now that this is all said and done, I'm still getting behavior that I'm not expecting. If I load my environment file into the browser (http://localhost/Simple_JSP/environment.jsp), it comes up as though there were no security/authentication mechanism to put up a roadblock. The login page is never presented. I was expecting that if I were to request any page from the Simple_JSP area, that before anything is displayed, I would be prompted to provide and user name and password. Isn't that what's supposed to happen? Thanks, Joe -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 6:37 PM To: Tomcat Users List Subject: Re: Help/Examples setting up security settings As Mark indicated in another post, the first problem you need to resolve is how you have installed your webapp. ROOT is itself a webapp, and although it might seem right that you want to put your webapp under it, that isn't the case. Move SPID_JSP to /webapps and you should be all set. One other thing I see is you are missing security role definitions in your web.xml. You'll want to add something like this: security-role descriptionspid_jsp/description role-namespid_jsp/role-name /security-role The role-name element maps to the role you created in tomcat-users.xml, and also maps to the security constraint's role-name element, as you already have. One other thing... the order of elements in web.xml is usually important. I think newer versions of Tomcat allow you to put things in any order you want (as one would expect with XML!), but earlier versions had a more restrictive DTD. You should see an error message when you start Tomcat if this is going to be a problem. Just wanted to warn you about it is you see it later. Frank Gagnon, Joseph M (US SSA) wrote: OK, now I'm more confused. First some background (for those of you who haven't seen the entire history). 1.I have defined a role and added myself as a user in that role to the tomcat-users.xml file (in [tomcat install dir]/conf). The role is defined as spid_jsp. (SPID is just the name of an existing application that contains ASP files that I would like to test converting to JSP.) 2.I have placed a WEB-INF directory under my test application directory ([tomcat install dir]/webapps/ROOT/SPID_JSP) and put a web.xml file in it. (SPID_JSP is where the JSP and HTML files reside.) 3.That web.xml file contains the following: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameSPID JSP Test/display-name descriptionSPID JSP Test/description
RE: Help/Examples setting up security settings
Although I don't think this is the source of your problem, it strikes me as odd to be protecting the root of your webapp when this is where the unprotected page are as well (i.e., login.jsp, login_error.html) I would suggest leaving those two in the root of the webapp, and move environment.jsp and error.jsp to a subdirectory, maybe /Simple_JSP/content or something, then of course update the security constraint to constrain that new directory. Actually, one other thing... the references to the login form and the login error page in the login-config element I believe are relative to the webapp root, so drop the Simple_JSP from the beginning of them so they are /login.jsp and /login_error.jsp respectively. Again, not sure this is the problem, but it could be. Some other things, and this is where hopefully some Tomcat folks more knowledgable than me can help... There seems to be a realm-name element for login-config as well, but I have never used it... does it apply here? I think it may be for basic auth, but I am unsure. Also, there are perhaps some other things you need to do to tell Tomcat to use security... anyone else, does Joseph need to do anything to set up the UserDatabase resource, or is that set up by default? Also, does he need to create a context for his app and perhaps set something to tell Tomcat to use security? This is stuff I am not familiar with, so hopefully someone else reading this can help. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 15, 2005 9:31 am, Gagnon, Joseph M \(US SSA\) said: Ah-ha! Everything I had read so far led me to think I needed to put everything under ROOT. I'm glad you guys pointed that out. It makes sense. In the meantime, to make things simpler, I set up another webapp without any of the SPID stuff I was talking about before. It's very simple and contains nothing more than a login page (login.jsp) and login error page (login_error.html), the environment page (environment.jsp) I mentioned before and an error page (error.jsp), specified in the errorPage attribute of the page directive of the JSP files. The new app. sits in [tomcat]\webapps\Simple_JSP (not under ROOT any more) and the web.xml file in the WEB-INF subdirectory has been set up to use the correct path. I also included the security-role element Frank mentioned below. The web-app portion of web.xml looks like this: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-nameSimple JSP/display-name descriptionSimple JSP Test/description login-config auth-methodFORM/auth-method form-login-config form-login-page/Simple_JSP/login.jsp/form-login-page form-error-page/Simple_JSP/login_error.html/form-error-page /form-login-config /login-config security-role descriptionSecurity Role/description role-namesimple_jsp/role-name /security-role security-constraint web-resource-collection web-resource-nameSimple JSP Test/web-resource-name url-pattern/Simple_JSP/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namesimple_jsp/role-name /auth-constraint /security-constraint /web-app Of course, I set up the simple_jsp role in the tomcat-users.xml file and added that role to my user entry. Now that this is all said and done, I'm still getting behavior that I'm not expecting. If I load my environment file into the browser (http://localhost/Simple_JSP/environment.jsp), it comes up as though there were no security/authentication mechanism to put up a roadblock. The login page is never presented. I was expecting that if I were to request any page from the Simple_JSP area, that before anything is displayed, I would be prompted to provide and user name and password. Isn't that what's supposed to happen? Thanks, Joe -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 6:37 PM To: Tomcat Users List Subject: Re: Help/Examples setting up security settings As Mark indicated in another post, the first problem you need to resolve is how you have installed your webapp. ROOT is itself a webapp, and although it might seem right that you want to put your webapp under it, that isn't the case. Move SPID_JSP to /webapps and you should be all set. One other thing I see is you are missing security role definitions in your web.xml. You'll want to add something like this: security-role descriptionspid_jsp/description
RE: Help/Examples setting up security settings
Frank, First of all, thanks for the detailed information. At about the same time your response came through, I also managed to locate similar info from Marty Hall's web site (http://courses.coreservlets.com/Course-Materials/msajsp.html). Using both sources of information, I made the following additions/changes to the following files: (Remember, I'm using Tomcat 5.5.9) [tomcat_install_dir]/conf/tomcat-users.xml: ?xml version='1.0' encoding='utf-8'? tomcat-users ... role rolename=spid_jsp/ user username=[my user name] password=[my password] roles=spid_jsp/ /tomcat-users [tomcat_install_dir]/webapps/ROOT/SPID_JSP/WEB-INF/web.xml: web-app display-nameSPID JSP Test/display-name descriptionSPID JSP Test/description login-config auth-methodFORM/auth-method form-login-page/SPID_JSP/login.jsp/form-login-page form-error-page/SPID_JSP/login_error.html/form-error-page /login-config security-constraint web-resource-collection web-resource-nameSPID JSP Test/web-resource-name url-pattern/SPID_JSP/*/url-pattern /web-resource-collection auth-constraint role-namespid_jsp/role-name /auth-constraint /security-constraint /web-app [tomcat_install_dir]/webapps/ROOT/SPID_JSP/login.jsp: %@ page contentType=text/html; charset=iso-8859-1 language=java import=java.sql.* errorPage= % !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head titleSPID_JSP Login Page/title /head body form action=j_security_check method=post name=login_form table width=30% border=0 cellpadding=1 cellspacing=1 tr td width=30%User name:/td tdinput name=j_username type=text/td /tr tr td width=30%Password:/td tdinput name=j_password type=password/td /tr tr td width=30%nbsp;/td tdinput name=submit type=submit value=Login/td /tr /table /form /body /html [tomcat_install_dir]/webapps/ROOT/SPID_JSP/login_error.html: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head titleSPID JSP Login Error/title /head body Nope. Wrong password. a href=login.jspTry again/a /body /html Very simple stuff. However, when I try to login (by loading the login.jsp page), I get the following error from Tomcat: HTTP Status 404 - /SPID_JSP/j_security_check type Status report message /SPID_JSP/j_security_check description The requested resource (/SPID_JSP/j_security_check) is not available. Apache Tomcat/5.5.9 Obviously, there are some other things that I need to do, but I don't know what they are. Also, I'm curious how to direct control to the success page once authentication passes and the login succeeds. I'm really very new at web programming, so I'm sure there are either a lot of stupid things I'm doing, or stuff I need to do, but am not. Any help would be appreciated. Thanks, Joe -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, June 13, 2005 3:06 PM To: Tomcat Users List Cc: Tomcat Users List Subject: Re: Help/Examples setting up security settings Having just spent a couple of weeks integrating a new security framework into an existing app, a framework that works in concert with J2EE security, let me see if I can help... Hang on, this is going to be a long post!... J2EE security (I *thimk* that's what it's called this week!) works with the concept of constrained resources... think of it this way... a server's job, be it a web server, app server, Quake server, whatever, is to SERVE. Therefore, the baseline assumption is that resources should be AVAILABLE, and you will be defining which are constrained in some way. This is actually backwards for how many people think of it, so it is worth noteing. Now, in terms of actually configuring it, it comes down to two things... well, I guess three really... (1) Define what resources you want to constrain (2) Define who will be allowed to access those resources (3) Tell your app server how to authenticate a user for a given resource The first two are standard, the third is app server-specific. Let's say for the sake of example that you have a bunch of administration-type JSPs in your application, for setting up users or something. Let's assume they are all in the directory /admin in the root of your webapp. Now, let's do step (1) and define a rule that says we want anything in that directory to be constrained. Here's the web.xml entry: security-constraint display-nameAdminConstraint/display-name web-resource-collection web-resource-nameAdminConstraint/web-resource-name url-pattern/admin
RE: Help/Examples setting up security settings
On Tue, June 14, 2005 9:26 am, Gagnon, Joseph M \(US SSA\) said: Very simple stuff. However, when I try to login (by loading the login.jsp page), I get the following error from Tomcat: HTTP Status 404 - /SPID_JSP/j_security_check type Status report message /SPID_JSP/j_security_check description The requested resource (/SPID_JSP/j_security_check) is not available. Apache Tomcat/5.5.9 Obviously, there are some other things that I need to do, but I don't know what they are. Also, I'm curious how to direct control to the success page once authentication passes and the login succeeds. Hmmm... The only thing that strikes me odd is what is being requested... Every time I've seen it, j_security_check is in the root... I wonder if Tomcat doesn't recognize j_security_check as being a special servlet if it isn't in the root? Just for chuckles, move your JSPs to the root of your webapp, that should result in /j_security_check being what the form is submitted to, see if that solves the problem (I *think* you could make the action of your form ../j_security_check instead of moving everything, that should do the same thing and would be easier). If that doesn't work then there is probably something else specific to Tomcat that needs to be done to enable that servlet that I am not aware of. As for the question of directing control to the success page, this is one of those things that is a bit confusing at first... you really don't direct control anywhere... what should happen is the URL your users should access *IS* the success page, assuming the succcess page is a constrained resource... in other words, write your application with the assumption that a user is already authenticated and that really the login page IS NOT part of your application. Then, when they try to access the success page, the request will be intercepted and the login page shown. If they enter valid credentials, THEN the success page will be returned to them automatically. That part usually confuses people at first (I think it did me too for a few minutes when I first dealt with this). Just remember, it's an intercept-based security mechanism... when the user tries to hit a protected resource, the request is intercepted and they are challenged to authenticate themselves. Conceptually, think of the original request as having been put on hold. Once they authenticate, the request continues where it left off, you have nothing special to do. I'm really very new at web programming, so I'm sure there are either a lot of stupid things I'm doing, or stuff I need to do, but am not. No, I think you've managed to get pretty far essentially on your own... Good job! :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help/Examples setting up security settings
converting an existing ASP application to JSP. The books would be purchased through my department, and I don't want to have a bunch of books bought that I may end up not using, if the decision ends up being that we won't go the JSP route. I realize that it's difficult for someone reading this to get the full picture of my situation. I've tried to include all pertinent information. If anyone can help me out, I would sure appreciate it. (Thanks again Frank Zammetti for the information you've provided so far.) Thanks, Joe Gagnon -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 9:39 AM To: Gagnon, Joseph M (US SSA) Cc: Tomcat Users List Subject: RE: Help/Examples setting up security settings On Tue, June 14, 2005 9:26 am, Gagnon, Joseph M \(US SSA\) said: Very simple stuff. However, when I try to login (by loading the login.jsp page), I get the following error from Tomcat: HTTP Status 404 - /SPID_JSP/j_security_check type Status report message /SPID_JSP/j_security_check description The requested resource (/SPID_JSP/j_security_check) is not available. Apache Tomcat/5.5.9 Obviously, there are some other things that I need to do, but I don't know what they are. Also, I'm curious how to direct control to the success page once authentication passes and the login succeeds. Hmmm... The only thing that strikes me odd is what is being requested... Every time I've seen it, j_security_check is in the root... I wonder if Tomcat doesn't recognize j_security_check as being a special servlet if it isn't in the root? Just for chuckles, move your JSPs to the root of your webapp, that should result in /j_security_check being what the form is submitted to, see if that solves the problem (I *think* you could make the action of your form ../j_security_check instead of moving everything, that should do the same thing and would be easier). If that doesn't work then there is probably something else specific to Tomcat that needs to be done to enable that servlet that I am not aware of. As for the question of directing control to the success page, this is one of those things that is a bit confusing at first... you really don't direct control anywhere... what should happen is the URL your users should access *IS* the success page, assuming the succcess page is a constrained resource... in other words, write your application with the assumption that a user is already authenticated and that really the login page IS NOT part of your application. Then, when they try to access the success page, the request will be intercepted and the login page shown. If they enter valid credentials, THEN the success page will be returned to them automatically. That part usually confuses people at first (I think it did me too for a few minutes when I first dealt with this). Just remember, it's an intercept-based security mechanism... when the user tries to hit a protected resource, the request is intercepted and they are challenged to authenticate themselves. Conceptually, think of the original request as having been put on hold. Once they authenticate, the request continues where it left off, you have nothing special to do. I'm really very new at web programming, so I'm sure there are either a lot of stupid things I'm doing, or stuff I need to do, but am not. No, I think you've managed to get pretty far essentially on your own... Good job! :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help/Examples setting up security settings
Gagnon, Joseph M (US SSA) wrote: snip 2. I have placed a WEB-INF directory under my test application directory ([tomcat install dir]/webapps/ROOT/SPID_JSP) and put a web.xml file in it. (SPID_JSP is where the JSP and HTML files reside.) snip You will need to fix this before anything stands a chance of working. The ROOT web application and SPID_JSP web application should be in separate directories. You should have [tomcat install dir]/webapps/ROOT/ for the root context and [tomcat install dir]/webapps/SPID_JSP for your app. HTH, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help/Examples setting up security settings
dump, except this time, the page header shows what I expect: Get Environment Data. First, why didn't I get presented with the login page? Isn't that what was supposed to happen? Second, I don't understand the dual behavior observed above. Why should I get what happens in scenario 1? The file requested exists at the location specified. What gives? Why does scenario 2 allow me to access my page as I would expect to? Obviously, I don't know diddly-squat about how this technology works and is meant to be used. Everything I try ends up either a drop dead failure or confuses me even more than I already was. There does not seem to be any consistency to the behaviors I've been seeing. If someone asked me right now whether to recommend using JSP, I'd have to say No. I can't even get a simple test scenario to work. I'm trying to hold off on buying any books on the subject, because I'm not sure which ones would be the best to get (although I have some ideas) and more importantly, because I am trying to evaluate the technology and the feasibility (not to mention the do-ability) of potentially converting an existing ASP application to JSP. The books would be purchased through my department, and I don't want to have a bunch of books bought that I may end up not using, if the decision ends up being that we won't go the JSP route. I realize that it's difficult for someone reading this to get the full picture of my situation. I've tried to include all pertinent information. If anyone can help me out, I would sure appreciate it. (Thanks again Frank Zammetti for the information you've provided so far.) Thanks, Joe Gagnon -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 9:39 AM To: Gagnon, Joseph M (US SSA) Cc: Tomcat Users List Subject: RE: Help/Examples setting up security settings On Tue, June 14, 2005 9:26 am, Gagnon, Joseph M \(US SSA\) said: Very simple stuff. However, when I try to login (by loading the login.jsp page), I get the following error from Tomcat: HTTP Status 404 - /SPID_JSP/j_security_check type Status report message /SPID_JSP/j_security_check description The requested resource (/SPID_JSP/j_security_check) is not available. Apache Tomcat/5.5.9 Obviously, there are some other things that I need to do, but I don't know what they are. Also, I'm curious how to direct control to the success page once authentication passes and the login succeeds. Hmmm... The only thing that strikes me odd is what is being requested... Every time I've seen it, j_security_check is in the root... I wonder if Tomcat doesn't recognize j_security_check as being a special servlet if it isn't in the root? Just for chuckles, move your JSPs to the root of your webapp, that should result in /j_security_check being what the form is submitted to, see if that solves the problem (I *think* you could make the action of your form ../j_security_check instead of moving everything, that should do the same thing and would be easier). If that doesn't work then there is probably something else specific to Tomcat that needs to be done to enable that servlet that I am not aware of. As for the question of directing control to the success page, this is one of those things that is a bit confusing at first... you really don't direct control anywhere... what should happen is the URL your users should access *IS* the success page, assuming the succcess page is a constrained resource... in other words, write your application with the assumption that a user is already authenticated and that really the login page IS NOT part of your application. Then, when they try to access the success page, the request will be intercepted and the login page shown. If they enter valid credentials, THEN the success page will be returned to them automatically. That part usually confuses people at first (I think it did me too for a few minutes when I first dealt with this). Just remember, it's an intercept-based security mechanism... when the user tries to hit a protected resource, the request is intercepted and they are challenged to authenticate themselves. Conceptually, think of the original request as having been put on hold. Once they authenticate, the request continues where it left off, you have nothing special to do. I'm really very new at web programming, so I'm sure there are either a lot of stupid things I'm doing, or stuff I need to do, but am not. No, I think you've managed to get pretty far essentially on your own... Good job! :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Re: Help/Examples setting up security settings
Having just spent a couple of weeks integrating a new security framework into an existing app, a framework that works in concert with J2EE security, let me see if I can help... Hang on, this is going to be a long post!... J2EE security (I *thimk* that's what it's called this week!) works with the concept of constrained resources... think of it this way... a server's job, be it a web server, app server, Quake server, whatever, is to SERVE. Therefore, the baseline assumption is that resources should be AVAILABLE, and you will be defining which are constrained in some way. This is actually backwards for how many people think of it, so it is worth noteing. Now, in terms of actually configuring it, it comes down to two things... well, I guess three really... (1) Define what resources you want to constrain (2) Define who will be allowed to access those resources (3) Tell your app server how to authenticate a user for a given resource The first two are standard, the third is app server-specific. Let's say for the sake of example that you have a bunch of administration-type JSPs in your application, for setting up users or something. Let's assume they are all in the directory /admin in the root of your webapp. Now, let's do step (1) and define a rule that says we want anything in that directory to be constrained. Here's the web.xml entry: security-constraint display-nameAdminConstraint/display-name web-resource-collection web-resource-nameAdminConstraint/web-resource-name url-pattern/admin/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameAdminRole/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Ok, so there's really 3 things being done here... (1) We are saying that anything in the /admin directory (/admin/*), based on that URL pattern, is to be constrained. So, http://mysite.com/admin/page1.jsp will be constrained, http://mysite.com/jsp/page1.jsp WILL NOT. Further, we are saying that only the GET and POST methods are being constrained. In other words, if someone tries to use an HTTP method other than GET and POST on a resource in that directory, THEY WILL GET TO IT WITHOUT HINDERANCE. Note that the display-name element is for IDE purposes... it is optional. Also, web-resource-name is for your own purposes, it can be whatever you want. (2) The next part is defining who will be able to access those resources. In this example we are saying that something called the AdminRole will be allowed to get to it (potentially, assuming they are validated). We'll get to what that AdminRole is in a minute... (3) We are saying that we want the resource to be served under SSL. That's what the CONFIDENTIAL transport-guarantee does. IIRC, this part is optional. There are three setting, CONFIDENTIAL, INTEGRAL (I think) and NONE. The first two are close to the same, so close in fact that I don't rememeber the difference :) None, as the name implies, means no guarantee about transport is made (i.e., serve it in the clear). Ok, so that's the first part of the equation. The next part is to make that AdminRole mean something. We do this by another entry in web.xml: security-role descriptionAdminRole/description role-nameAdminRole/role-name /security-role This is saying that there is a role (read: group) that a user can be in called AdminRole. Just like almost any other security mechanism out there, a user is assigned to a group (or a number of groups). This helps determine what rights they have. In this case we are saying that if a user tries to access a resource in the /admin directory, and if they are in the AdminRole group, then they are elligible to get at that resource. Ok, now we get to the third part... Somehow, your app server has to know about that AdrminRole and what users are in it. As I said, this part is server-specific. But, the bottom line is that you will see the name AdminRole defined somewhere, and probably with a list of users in it (or it might be a reference to an LDAP directory that contains that information, etc.) I guess there really is one other piece in web.xml: login-config auth-methodFORM/auth-method form-login-config form-login-page/login/doLogin.do/form-login-page form-error-page/login/loginError.do/form-error-page /form-login-config /login-config This basically turns on security, more or less... Here I am sayingt to use form-based authentication (i.e., a form with the fields j_username and j_password that submits to j_security_check as the action), and I'm also saying that if the user tries to access a constrained resource, display the page /logon/doLogin.do (probably a Struts Action in this case) or send them to /login/loginError.do if they do not get authenticated. So, what happens in a web app
