You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Fr...@Edeka.de on 2004/08/18 11:30:35 UTC

Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]

Subject: Container managed security in tomcat 5.x, need j_password in
struts web app, ServletFilter or IntermediateServlet?

Background:
=========
I'm writing a web front-end to a back-end system which has 1000 user
accounts and each user has different rights (ACIs, ACLs) in that back-end
(think of LDAP Directory, RDBMS, Filessystem = any Data-Store with
user-dependend
access-rights)
I use J2EE, Tomcat 5.0.27, Struts 1.1+Tiles as front-end, Sun One LDAP as
back-end.

Requirement(s):
============
- I want to user container managed security to leverage Realms and
JNDI/JAAS.
- I want to connect to the same back-end with the same user used by
container managed security
-> Therefore I need principal *and* credential of that user by whatever
means
- authorization is not managed by security-roles in J2EE sphere but by
security rules of backend
which automatically apply to the logged on user

Problem: authorization in back-end:
==========================
I can use container-managed security (JNDI-Realm) to authenticate users,
*but* can't connect to the back-end as the current user because my
application
doesn't know the password(credential) of the current user. I can get the
Principal, which is
not enough. So I can't leverage the ACIs, ACLs of my Back-End System
because
I have to logon as Superuser/root/DBA who is allowed everything.

Solution(s):
=========
1. Intermediate Servlet
----------------------
- User request protected resource
- Container forwards to my configured login.jsp
- User enters j_username and j_password and submits
- login.jsp does not POST to container servlet /j_security_check directly
but to by servlet which copies j_username and j_password in the session
context and *then* forwards or redirects /j_security_check

-> Problem: /j_security_check as a servlet mapping magically disappeares
by that time in Tomcat 5.0.x, so it complains it can't find
'/j_security_check' :-P

Part of my LoginAction:
            ActionForward forward = new ActionForward();
            forward.setName("securityCheck");
            forward.setPath("/j_security_check");
            // forward.setPath("/../j_security_check");
            // forward.setPath("http://localhost:8080/j_security_check");
            forward.setContextRelative(false);
            forward.setRedirect(false);
            // forward.setRedirect(true);


2. ServletFilter
--------------
- User request protected resource
- Container forwards to my configured login.jsp
- User enters j_username and j_password and submits
- login.jsp POSTS to /j_security_check
- Container is configured as to apply MyServletFilter to the
URL pattern /j_security_check
- MyServletFilter gets the POSTed j_username, j_password
out of the request, copies them into the session.context
and chains to the Servlet /j_security_check which
authentificates the user as normal

-> Problem: MyServletFilter gets called for all URL patterns
with the one exeption being '/j_security_check'. :-P

Part of my FilterMapping in web.xml:
      <filter-mapping>
            <filter-name>LoginFilter</filter-name>
            <url-pattern>/j_security_check</url-pattern>
            <dispatcher>REQUEST</dispatcher>
            <dispatcher>FORWARD</dispatcher>
      </filter-mapping>
Part of my LoginFilter:
            log.warn("*** Executing LoginFilter doFilter()");
            chain.doFilter(request, response);

Being J2EE conform?
===============
Both solutions are J2EE conform. Standards were a bit ambigous at that
point but I don't consider both solutions valid.
The ServletFilter-solution is described for IBM Webpshere in developerWorks
and the Intermediate Servlet was proposed by people on the tomcat
mailing and seemed to work on tomcat 4.x

Struts and Tiles:
============
I use struts and tiles for the front-end. form-based authentification
via login.jsp does work, even with struts and tiles, if I call
/j_security_servlet
directly in a non Struts-action.
The Intermediate Servlet is my Action servlet from struts. j_username and
j_password are in an
action form bean. I use an ActionForward to '/j_security_check'.
Because Struts appends the name of the web-app I tried
'/../j_security_check' and 'http://localhost:8080/j_security_check'
with forward or redirect but to no success.
All *.do URLs are secure and protect be container-managed security.
All resources to build the login.jsp are not protected.
Subquestion: How do I forward to URIs outside my current web-app?
Now it gets appended so I end up with /<web-app>/j_security_check
which cannot be found?

I don't think I'm the only one with this problem. What did I wrong?
Did I overlook anything? Are my solutions valid. Are there more solutions?
I don't want to use ServletFiltering for my proprietary SecurityFilter
like the sourceforge.net project but stay with container-managed security.

All help is welcome, TIA,

Frerk Meyer

EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]

Posted by Tim Funk <fu...@joedog.org>.
It sounds like you'll need to create your own realm. You might be able to 
extend JNDIRealm.

You cannot run filters on /j_security_check. The spec says so. Websphere 
might allow it - but tomcat doesn't.

-Tim

Frerk.Meyer@Edeka.de wrote:

http://marc.theaimsgroup.com/?l=tomcat-user&m=109282146309790&w=2

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org