tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gagnon, Joseph M \(US SSA\)" <>
Subject RE: Help/Examples setting up security settings
Date Tue, 14 Jun 2005 13:26:55 GMT

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

Using both sources of information, I made the following
additions/changes to the following files: (Remember, I'm using Tomcat


<?xml version='1.0' encoding='utf-8'?>
	<role rolename="spid_jsp"/>
	<user username="[my user name]" password="[my password]"


	<display-name>SPID JSP Test</display-name>
	<description>SPID JSP Test</description>

			<web-resource-name>SPID 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"
<title>SPID_JSP Login Page</title>
<form action="j_security_check" method="post" name="login_form">
<table width="30%" border="0" cellpadding="1" cellspacing="1">
    <td width="30%">User name:</td>
    <td><input name="j_username" type="text"></td>
    <td width="30%">Password:</td>
    <td><input name="j_password" type="password"></td>
		<td width="30%">&nbsp;</td>
    <td><input name="submit" type="submit" value="Login"></td>


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<title>SPID JSP Login Error</title>
Nope. Wrong password.
<a href="login.jsp">Try again</a>

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

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.


-----Original Message-----
From: Frank W. Zammetti [] 
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

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
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

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
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


Ok, so there's really 3 things being done here...

(1) We are saying that anything in the /admin directory (/admin/*),
on that URL pattern, is to be constrained.  So, will be constrained, 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
in that directory, THEY WILL GET TO IT WITHOUT HINDERANCE.  Note that
<display-name> element is for IDE purposes... it is optional.  Also,
<web-resource-name> is for your own purposes, it can be whatever you

(2) The next part is defining who will be able to access those
In this example we are saying that something called the "AdminRole" will
be allowed to get to it (potentially, assuming they are validated).
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
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:


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
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:


This basically turns on security, more or less... Here I am sayingt to
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/ (probably a Struts Action in this case) or
them to /login/ if they do not get authenticated.

So, what happens in a web app with all this in it?  Let's walk through

(1) User enters

(2) The container looks through the defined <security-constraint>'s and
looks for one with a <url-pattern> element that matches the requested
 In this case it finds one.

(3) So, security kicks it.  Now the <login-config> element is looked at
and we see that form-based authentication is in use.  So, the page named
in the <form-logon-page> element is displayed.  Note that if you were
using basic auth, the user would get a popup box.

(4) In either case, they enter their username and password.

(5) At this point, we get into container-specific stuff... basically,
whether it is a lookup against an LDAP directory, or against a Tomcat
file, or something else entirely, j_security_check (a servlet) is
responsible for this.  It looks up the user, and assuming they are
returns the group they are in.  Might be AdminRole in this case, might
PlainOldUserRole, or something else.  P.S., if the user isn't found, or
their password is not correct, a 403 error is returned.,  You can name
what page to display in this case by adding to web.xml:


(6) So, the container then has the group the authenticated user is in...
So it consults the <security-role> elements and finds a match.  It then
looks again at the security constraints that the URL mapped to and see
the group the user is in is defined as having rights to that resource.

(7) Assuming the group the user is in has rights, the original request
goes through. This might be confusing... remember that the reason the
login screen was displayed was because the user requested a constrained
resource... you can think of that request as being placed "on hold", in
sense, until the user is authenticated.  Once they are, the original
request "continues" and the resource is returned.  Let me see if my
art is up to the challenge...

| Request for /admin/page1.jsp |
| Security intercept: login page shown |
| Login form submit |
| User validated and belongs to allowed group |
| Request forwarded to /admin/page1.jsp |

Ok, hope that gets the point across.  So, but the end of that chain, the
page1.jsp is now displayed, the user is happy :)  Note that this process
as outlined is conceptual... there could be some details in how the
container does it's thing that I got wrong... from your perspective, and
the perspective of what the user sees though, it is correct.

I think that's everything.  Hope that helps!

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

On Mon, June 13, 2005 1:55 pm, Gagnon, Joseph M  \(US SSA\) said:
> Hello,
> Does anyone have any examples of how to set up my deployment
> (web.xml in Tomcat 5.5.9) to do BASIC authentication (of any of the
> other methods, for that matter)?
> I've looked at various sources of information on the web (including
> of Sun's sites), but have not yet found good examples (more than one
> would be great), from soup to nuts, with good explanations along the
> way, describing the various elements involved (what they do and why
> why not) they are needed).
> A lot of these sources provide copious amounts of information, but not
> good working examples that I can either use directly, or at least
> from.  Many times example chunks of code are provided, but it's not
> clear what each element does.  Also, quite often only one example of a
> specific usage (say: FORM based authentication) is provided, but
> are not.
> I guess the basic gripe I have is that there's a lot of information
> provided for this technology, but very little information provided
> actually helps someone who's just learning this stuff, actually learn
> HOW to use it.
> Now there's a caveat: I'm investigating possibly using JSP for a
> work-related project.  I am looking at adding some functionality to an
> existing web application that is currently written as an ASP app.
> other things, I am trying to evaluate JSP to see what advantages it
> (or may not) provide over the existing ASP.
> At this point, I'm trying to take a small part (essentially the front
> end) of the ASP app. and JSP-icize it to see what's involved in
> the same (or similar) functionality.  Unfortunately I keep running
> problems that for the most part, result from my lack of knowledge in
> this technology area.
> I do not want to spend money on books (at least not at this time),
> we have not reached a decision on whether we will go with JSP, or
> with ASP.  I'm not sure which books would be the best ones to get in
> case.  What I've found so far on the web, has not helped me out at
> and in general, is way over my head (at this point anyway).
> Does anybody have any examples they could provide that might help me
> along?  It would be greatly appreciated.
> Thanks,
> Joe
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message