Application Security with Struts and SecurityFilter

[Melonie Brown <me...@yahoo.com>]

I am retrofitting container managed security onto an
application that is about halfway through development.

The login form would go to a logonaction which would
validate the user and retrieve a custom list of menu
items from the database and store into the session
before proceeding into the application.

I have changed the login to use the securityfilter
from sourceforge and modified the booleanAuthenticate
method to validate against our user database.  So far
so good.  

What's causing me problems now is retrieving the list
of custom menu items and placing into the session. 
Where does that fit into the container security?  I've
seen references to a principal, but don't understand
how to set additional attributes.  Should the page
that the user gets directed to just do a redirect
forward to a struts action that would load the menu
items?

Also, if the session times out and the user logs back
in, will the container send the user back to the
original page?  

Since the login form is a "pure" html form, can the
Validator be used with it to force min lengths on
passwords, etc.?  If so, how is that done?

We're using Tomcat, but would prefer not to do Tomcat
specific things if possible (which is why I'm using
the securityfilter).

Assistance would be greatly appreciated, as I'm
getting resistance on the container security versus a
check for login placed into each page of the app
(which I understand is a bad idea).  



__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

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

Re: Application Security with Struts and SecurityFilter

[Max Cooper <ma...@maxcooper.com>]

Hi Melonie,

See my comments interspersed below...

----- Original Message -----
From: "Melonie Brown" <me...@yahoo.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, April 23, 2003 11:03 AM
Subject: Application Security with Struts and SecurityFilter


> I am retrofitting container managed security onto an
> application that is about halfway through development.
>
> The login form would go to a logonaction which would
> validate the user and retrieve a custom list of menu
> items from the database and store into the session
> before proceeding into the application.
>
> I have changed the login to use the securityfilter
> from sourceforge and modified the booleanAuthenticate
> method to validate against our user database.  So far
> so good.
>
> What's causing me problems now is retrieving the list
> of custom menu items and placing into the session.
> Where does that fit into the container security?  I've
> seen references to a principal, but don't understand
> how to set additional attributes.  Should the page
> that the user gets directed to just do a redirect
> forward to a struts action that would load the menu
> items?

Container security does not have any facility for having your app do any
work at the point of login. This is perhaps the most common user requestfor
SecurityFilter, so we have been considering a few ideas about how to support
this functionality. But there is no support for it at this time. This
SecurityFilter RFE has some ideas on ways to put stuff in the session
without using special processing on login:
http://sourceforge.net/tracker/index.php?func=detail&aid=670009&group_id=594
84&atid=491167

Putting the info in the Principal might also be an option. There are two
basic ways to write a custom Realm for use with SecurityFilter. One is to
extend the SimpleSecurityRealmBase class, where you need only implement
booleanAuthenticate() and isUserInRole() without having to deal with making
Principal objects. The other way is to implement the SecurityRealmInterface
directly, where you need to implement authenticate() that returns a
Principal object, and a slightly different isUserInRole() method. Using the
second realm implementation approach, you can provide your own
implementation of Principal with any additional properties you want. Calling
request.getUserPrincipal() will return the Principal object that your realm
creates, so you can cast it to the subtype you created to access additional
information. I haven't seen much discussion on what kinds of things belong
in the Principal from a design standpoint. My own inclinations are that the
Principal should be somewhat generic and that app-specific stuff should be
separate, but I don't have any rock-solid arguments why I think that is so.

>
> Also, if the session times out and the user logs back
> in, will the container send the user back to the
> original page?

They will be redirected to the page they wanted to go to after logging in.
For example:

0. user is logged in and surfing around the site/app...
1. user loads the form FillMeOut.do
2. user falls asleep at desk for 3 hours, causing session to time out
3. user wakes up and submits form to ProcessMe.do
4. SecurityFilter intercepts the request, takes note that they wanted
ProcessMe.do (including all the form field values they submitted) and
redirects them to LoginForm.do
5. user fills out the login form, and submits to j_security_check
6. filter authenticates user and redirects them to ProcessMe.do
7. ProcessMe.do gets the request, with all the parameters originally
submitted, and does its work

>
> Since the login form is a "pure" html form, can the
> Validator be used with it to force min lengths on
> passwords, etc.?  If so, how is that done?

The filter does all the processing of the form submittal, so it won't ever
get to Struts/validator for processing. However, validation on password
length and username, etc. really belong in the registration / edit user
page, which will be totally separate from the security mechanism. For
securityfilter (and CMS), the username/password combo either the
username/password combo is valid or not valid and no mechanism is present
for telling the user why (which is actually a good thing from a security
standpoint).

>
> We're using Tomcat, but would prefer not to do Tomcat
> specific things if possible (which is why I'm using
> the securityfilter).
>
> Assistance would be greatly appreciated, as I'm
> getting resistance on the container security versus a
> check for login placed into each page of the app
> (which I understand is a bad idea).

Here are my arguments against writing a custom system:
1) Writing your own security system is more difficult than it would seem. It
is tricky to "batten down all the hatches" and make the system really
secure.
2) CMS and SecurityFilter implement the standard servlet spec interfaces,
which allows other components (like Struts) to access and use this
information.
3) CMS and SecurityFilter give you just-in-time logins for users that
bookmark pages or email links to each other (a key advantage of web apps,
IMHO). The difficulty in making this work and the value of having it are
often overlooked.
4) CMS and SecurityFilter don't require any special tags in the secured
files, etc. and don't require the introduction of interfaces or software
components that your project team must maintain.

I think it is good that you are looking at CMS and SecurityFilter -- there
is rarely a good reason to write your own system, and custom systems are
rarely as functional or easy to work with as standard CMS (or clones of it
like SecurityFilter). Sometimes there is a good reason to write your own
system, but I would guess that the number of custom systems out there far
exceeds the number of good reasons. ;-)

-Max
(author of SecurityFilter)

>
>
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>



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