You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Gagnon, Joseph M (US SSA)" <jo...@baesystems.com> on 2005/06/13 19:55:14 UTC
Help/Examples setting up security settings
Hello,
Does anyone have any examples of how to set up my deployment descriptor
(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 some
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 (or
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 learn
from. Many times example chunks of code are provided, but it's not made
clear what each element does. Also, quite often only one example of a
specific usage (say: FORM based authentication) is provided, but others
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 that
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. Among
other things, I am trying to evaluate JSP to see what advantages it may
(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 creating
the same (or similar) functionality. Unfortunately I keep running into
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), since
we have not reached a decision on whether we will go with JSP, or stick
with ASP. I'm not sure which books would be the best ones to get in any
case. What I've found so far on the web, has not helped me out at all,
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Help/Examples setting up security settings
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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-name>AdminConstraint</display-name>
<web-resource-collection>
<web-resource-name>AdminConstraint</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>AdminRole</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</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>
<description>AdminRole</description>
<role-name>AdminRole</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-method>FORM</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 with all this in it? Let's walk through it...
(1) User enters http://mysite.com/admin/page1.jsp
(2) The container looks through the defined <security-constraint>'s and
looks for one with a <url-pattern> element that matches the requested URL.
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 XML
file, or something else entirely, j_security_check (a servlet) is
responsible for this. It looks up the user, and assuming they are found,
returns the group they are in. Might be AdminRole in this case, might be
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:
<error-page>
<error-code>403</error-code>
<location>/jsp/badLogon.jsp</location>
</error-page>
(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 if
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 a
sense, until the user is authenticated. Once they are, the original
request "continues" and the resource is returned. Let me see if my ASCII
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
http://www.omnytex.com
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 descriptor
> (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 some
> 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 (or
> 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 learn
> from. Many times example chunks of code are provided, but it's not made
> clear what each element does. Also, quite often only one example of a
> specific usage (say: FORM based authentication) is provided, but others
> 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 that
> 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. Among
> other things, I am trying to evaluate JSP to see what advantages it may
> (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 creating
> the same (or similar) functionality. Unfortunately I keep running into
> 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), since
> we have not reached a decision on whether we will go with JSP, or stick
> with ASP. I'm not sure which books would be the best ones to get in any
> case. What I've found so far on the web, has not helped me out at all,
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org