Web Servers on Unix and Linux - How to prevent direct .JSP access from Tomcat?

This is Interesting: Free IT Magazines  
Home > Archive > Web Servers on Unix and Linux > December 2004 > How to prevent direct .JSP access from Tomcat?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author How to prevent direct .JSP access from Tomcat?
javaguy@sbcglobal.net

2004-12-10, 5:50 pm

I have an app served by Apache 2 / Tomcat 5.

If I could prevent users from accessing my site by JSP name, then I
don't have to test for proper logins, etc., on each JSP page.
Especially if the JSP are merely views.

For example, suppose a logged-in user selects a choice from
myurl/myapp/menu.jsp. That choice calls the servlet
myurl/myapp/frontController?action=orderSearch and the page
myurl/myapp/orderSearch.jsp is served up.

If the user accesses their browser location bar and types in
"myurl/myapp/orderSearch.jsp" then, if all JSP access is allowed, the
orderSearch.jsp page must check for a valid session, and user
permissions for that page. By that logic, all my JSP pages must have
role and session checking.

Now, if I can limit the pages the user can directly access then the
entry to orderSearch.jsp would be prohibited, but the access from the
servlet would be allowed.

I already tried using the SECURITY-CONSTRAINT and SECURITY-ROLE
sections (upper-casing to avoid translation of LT and GT brackets...)
of Tomcat's web.xml, to no good effect. I told SECURITY-CONSTRAINT
that /servlet/* was always allowed (the role was "*"), for both GET and
POST. I also said that *.jsp was only allowed for role "nobody", for
both GET and POST. I got bad results. Apparently when the servlet
dished back orderSearch.jsp this was intercepted by the security,
denied, and then Apache said "myurl:8443" couldn't be accessed (it fell
back to a non-existent SSL connection). The real meaning was that
using SECURITY-CONSTRAINT didn't work.

So, can I get to where I want to go? I sense that this is a Tomcat
config problem, rather than of Apache, but...
Thanks for anything,
Jerome.

Juha Laiho

2004-12-10, 5:50 pm

javaguy@sbcglobal.net said:
>I have an app served by Apache 2 / Tomcat 5.
>
>If I could prevent users from accessing my site by JSP name, then I
>don't have to test for proper logins, etc., on each JSP page.
>Especially if the JSP are merely views.


Ah, ok. I just hinted about this in my previous message, and looks
like you need to take a step forward - to start using the
authentication provided by the framework.

>So, can I get to where I want to go? I sense that this is a Tomcat
>config problem, rather than of Apache, but...


Yep, this all can be done within Tomcat. I'll get more details in
another message, after I've dug them up myself..
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
Juha Laiho

2004-12-10, 5:50 pm

.... and more about user authentication in Tomcat.

Three parts; configuration is needed for the application, and configuration
is needed for Tomcat. Finally, relevant login and error pages need to
be written.

Application configuration (so, these belong to the
webapps/yourapp/WEB-INF/web.xml):

You'll need to set up security constraint requiring authentication for
your webapp; example picked from web.xml of the Tomcat admin application:
<!-- Security is active on entire directory -->
<security-constraint>
<display-name>Tomcat Server Configuration Security Constraint</display-name> <web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.do</url-pattern>
<url-pattern>*.html</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area -->
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

So, within this application, any request to *.jsp, *.do or *.html will
require that the accessing user (session) has role 'admin'.

Then, you'll need to declare the login configuration for the application.
As you already do, use form-based login - but implement it through Tomcat:
<!-- Login configuration uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Tomcat Server Configuration Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>

The <login-config> element should be after all <security-constraint> -
elements. The page URL's are relative to your webapp root.


Then (this is a bit idiosyncratic, I'd say) you declare which roles this
application uses/recognises:
<!-- Security roles referenced by this web application -->
<security-role>
<description>
The role that is required to log in to the Administration Application
</description>
<role-name>admin</role-name>
</security-role>


Ok, application configuration done. Now to Tomcat configuration; you'll
need to create conf/tomcat-users.xml (so, within your Tomcat installation
directory, the same directory that holds your server.xml):

<tomcat-users>
<user name="user1" password="password" roles="admin" />
</tomcat-users>

There are also ways to use non-plaintext password entries, but let's be
happy with plaintext passwords for now.


Then, Tomcat configuration (server.xml) needs to be set up to make use
of this file. I find this set-up is more complex than needed, but
perhaps it gives needed flexibility in more complex server environments:

Within <GlobalNamingResources> block you'll need to declare and configure
a Realm used for authentication; this example is from Tomcat 4.1.30; you
may need to make slight alterations for Tomcat 5:
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users -->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved">
</Resource>
<ResourceParams name="UserDatabase">
<parameter>
<name>factory</name>
<value>org.apache.catalina.users.MemoryUserDatabaseFactory</value>
</parameter>
<parameter>
<name>pathname</name>
<value>conf/tomcat-users.xml</value>
</parameter>
</ResourceParams>

Later, within <Engine> block you'll need to enable this realm to be used
within the engine:
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>

So, here the resourceName must match with name used in the above
configurations.

Configuration done; now to creating the login and error pages; I'm
extracting here the bare minimums from login.jsp and error.jsp in
the Tomcat admin webapp.

So, for the login form (which must be the page you declared in web.xml)
you need:

<form method="POST" action='<%= response.encodeURL("j_security_check") %>'
name="loginForm">
Username: <input type="text" name="j_username">
<br>
Password: <input type="password" name="j_password">
<br>
<input type="submit" value="Login">
</form>

The names j_security_check, j_username and j_password are constants;
they must not be changed. Also the form method must be POST.


The error page can be pretty much anything; it doesn't have any formal
requirements.


That's all. No code needed for password validation. "Just" set up and
enable the realm, configure your application for security, and
create the login page. I'd say this is rather nice - given especially
that with the server configuration you can change the password store
to be LDAP directory or a database, or even write your own custom
authenticator to use some very specific backend.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
javaguy@sbcglobal.net

2004-12-16, 6:49 pm

Thanks for the help. However, I don't think that the realm solution
matches my needs.

First, I wish an authenticated user to be sent a .jsp page, but not to
be able to request a .jsp page. So they access the /myapp/getOrders
servlet which eventually forwards to the showOrders.jsp page, which is
displayed. The security should allow them to get that .jsp page, but
not be able to point directly at it. I'm going to try this as
forwarding later.

Second, I don't think authentication is my problem. While I *could*
make authentication work through Tomcat I already have form-based
authentication working within my application. My logical problem isn't
letting authenticated user A into the .jsp files and keeping
unauthenticated user B out of them. My problem is keeping A and B out
of .jsp files, but letting A see those .jsp files when the servlet
forwards to them.

I will reconfigure one of my test systems as recommended above, and
forward the result of a servlet. I will report on my results.

Jerome.

javaguy@sbcglobal.net

2004-12-16, 6:49 pm

I have tried the <security-constraint>, <security-role> and
<tomcat-users> configuration with reasonable success. After I changed
my login servlet to forward instead of redirecting, I changed my
Login.jsp to Login.html (performing appropriate edits). I can't get to
Login.jsp at all, which in my configuration is good. I can get to
Login.html, the login authenticates, and diplays my "welcome,
authenticated user" .jsp page, which I had forwarded to. This is what
I wanted to happen. I don't see my images on that page, and I
understand that happens with forwarding. But since there are Struts
tags that answer that situation (I'm moving to Struts) this isn't a
problem for me.

Thanks for the help, and the encouragement to try the job correctly!
Jerome.

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com