I implemented a Struts controlled authentication mechanism because I needed
a custom authentication routine not
already available via any servlet container.  In addition, because there is
no standard for implementing custom
container-based authentication (different API's in every container) and I
want to guarantee portability of my 
web app, I opted for writing a set of custom Struts actions and subclassing
the Struts 1.1 RequestProcessor to
implement my custom authentication and authorization.  The RequestProcessor
has some good pre-defined hotspots 
for adding in authentication and authorization:

      1. I created a custom ActionMapping that has accessors and mutators
for 
         <set-property property=UserAuth value=[true | false]>.  This allows
me to declaritively define in 
         struts-config.xml whether an Action requires the client to
authenticate first.

        2. I overrode (overrided??) processPreprocess() to check the
ActionMapping (ActionConfig) for the presence
         of the UserAuth property (see #1).  If UserAuth is true, then the
HttpSession is checked for the presence of 
         a custom SecurityToken (functionally based on the Catalina
GenericPrincipal).  
         If the token is unavailable, Struts forwards to the login form with
the originally requested Action as
         a parameter (via a pre-populated ActionForm to allow for
continuation of workflow).
         If the token is available or UserAuth is false, the originally
requested Action is processed.
         
      3. The login form submits to a LoginAction that checks credentials and
stores the SecurityToken in the 
         HttpSession and then forwards to the originally requested Action.
This prevents authentication from
         interrupting the desired workflow.

      4. In Struts 1.1, the ActionMapping (ActionConfig) has accessors and
mutators 
         (getRoleNames(), getRoles(), and setRoles()) so that role-based
authorization can be 
         declaritively defined for Actions within struts-config.xml
(although, the Struts 1.1b DTD does not define the 
         necessary XML attribute for Action to allow one to use this - I had
to add it myself to the DTD).
         
        5. The RequestProcessor has another hotspot (method) for checking
authorization via "roles".  I also overrode
         processRoles() to check the roles stored in my custom SecurityToken
against the roles defined in the ActionMapping
         (ActionConfig). 

The following pros and cons were acheived in implementing Struts-controlled
security over container managed security:
        1. Pro: Retained the ability to declaritively define security
parameters for both authentication and authorization in
         an app-specific config file (struts-config.xml)
 
      2. Pro: Portability between servlet containers (as long as Struts 1.1
is used)

      3. Con (possibly): Struts-based security may be more resource
intensive by constantly having to check for 
         UserAuth presence in processPreprocess() even for Actions (and any
request) where it is not defined. 
         Container managed security may be implemented more efficiently on
the back-end, but it varies between containers.
         Toss-up in my book.

I welcome any and all comments.

Jason




-----Original Message-----
From: Joe Germuska [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 09, 2002 7:33 AM
To: Struts Users Mailing List
Subject: Re: container managed security


At 5:48 PM +0200 2002/07/08, J�rgen Weber wrote:
>Hello,
>
>I am into evaluating Struts.
>
>The struts-example.war does authentication for its users programmatically.
>
>Why doesn't it use container managed security?

I would assume simply because that's easier for an example.  There's 
nothing preventing anyone from using container managed security for 
Struts.

Do you see ways in which the Struts framework can do anything useful 
to make it easier to implement container managed security?  I can 
imagine perhaps having a SecureActionMapping subclass of 
ActionMapping that might allow declarative access control based on a 
user role or something -- but I haven't needed that kind of security 
in an app yet, so I haven't really learned all the details.

If you need it, maybe you can build it, and then contribute it back 
to the project?  That's how these things grow after all...

Joe

-- 
--
* Joe Germuska    { [EMAIL PROTECTED] }
"It's pitiful, sometimes, if they've got it bad. Their eyes get 
glazed, they go white, their hands tremble.... As I watch them I 
often feel that a dope peddler is a gentleman compared with the man 
who sells records."
        --Sam Goody, 1956
tune in posse radio: <http://www.live365.com/stations/289268>

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

Reply via email to