On Sat, 15 Jun 2002, Les Hughes wrote:
> Date: Sat, 15 Jun 2002 08:32:53 +0100
> From: Les Hughes <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> Subject: RE: front controller pattern and security
>
>
> And of course, static role based security is only half the issue. Most of
> the time you want to be checking that the data actioned upon is in the right
> state for that action - I'm not just talk about the "who" can do "what" but
> to "whom" (data) and "when" (state). We use a inhouse solution for this
> problem at the mo alongside struts. Perhaps this is getting into struts-user
> land as opposed to tc-user but maybe Craig and others could comment?
>
Off the top of my head, I don't know of any generic frameworks for this
sort of security management -- the details sound like they would always be
pretty application specific.
> Bye,
>
> Les
>
Craig
>
> > -----Original Message-----
> > From: Martin Jacobson [mailto:[EMAIL PROTECTED]]
> > Sent: 14 June 2002 09:00
> > To: Tomcat Users List
> > Subject: Re: front controller pattern and security
> >
> >
> > John Gregg wrote:
> >
> > > Hi all.
> > >
> > > I've been thinking about how the j2ee front controller
> > pattern (used by
> > > Struts et al.) does/does not take advantage of url-based
> > authorization
> > > constraints in web.xml. I want to avoid having to check
> > roles in my own
> > > code as much as possible. At first I thought I could
> > declare a URL like
> > > /somewebapp/somerole/* to require the "somerole" role
> > before being allowed
> > > access to my controller servlet. Another URL would be
> > > /somewebapp/someotherrole/* but would map to the same
> > servlet. That servlet
> > > would then pick off the action at the end of the URL and execute it.
> > > However, while I can restrict access to the servlet, or
> > whatever other
> > > "physical" resource I'm trying to protect, what I really
> > want to protect is
> > > the action that's executed. Am I just stuck with
> > enumerating all possible
> > > actions in by web.xml (/somewebapp/somerole/someaction,
> > > /somewebapp/somerole/someotheraction, etc.)? Should I
> > instead make a filter
> > > that enforces this for me? I'm facing the same problem
> > with Apache SOAP's
> > > rpcrouter.
> > >
> >
> >
> > Surely, the way you describe, using servlet-mapping & auth-constraint
> > does exactly what you want?
> > In other words, you have one (controller) servlet declared,
> > and you use
> > servlet-mapping to declare all urls that invoke that servlet. In
> > auth-contstraint you declare the mapping between urls and user roles.
> > So, when a user invokes /app/manager/ac_details, the auth-constraint
> > would trigger an authorisation check to make sure the user was in the
> > indicated role. Then (if he's allowed), because the
> > servlet-mapping maps
> > this url to the controller servlet, the controller servlet is
> > invoked,
> > and, as you say, you can then determine what the action was
> > (ac_details)
> > by examining the url. This method does not restrict access to the
> > controller servlet directly, but does protect the functions
> > to be performed.
> >
> > Or have I misunderstood?
> >
> > Martin
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
