struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <co...@Bspark.com>
Subject RE: Authentication and Authoirzation
Date Wed, 04 Oct 2000 19:52:49 GMT
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: October 4, 2000 2:26 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Authentication and Authoirzation
> 
> Melroy Rodrigues wrote:
> 
> > Hi,
> >
> > Does anyone know if I will be able to use the
> > RDBMSRealm for authentication and then the ACls
> > in web.xml for authorization with Struts?
> >
> > Thanks
> > Melroy
> 
> You can certainly use the container-managed security features of the
> Servlet 2.2 specification in a Struts application.  The 
> reason I did not
> do so in the example is that, unfortunately, how you tell 
> your container
> where to find the list of users and their roles is specific to each
> container (not portable).  For example, Tomcat lets you configure an
> appropriate Realm implementation -- other containers do it 
> differently.
> 
> Struts, on the other hand, does not care how authentication 
> is done, and
> it doesn't enforce the authentication and access control rules because
> the container does it for you.

There is a fundamental problem in using the declarative (path-based)
security feature of Servlet 2.2 containers, in an environment running both
Servlets and JSPs. This is the approach we tried initially, but we gave it
up for another way... The problem is that when your servlets redirect to
JSPs the browser doesn't know anything about it, and assumes all relative
resource references (hrefs, etc.), are off the original path.

I initially had a setup where user requests would come in via a url like
  /cmd/action/subaction
where /cmd would be mapped to the ActionServlet servlet. Before the action
handler would ever get the request, the servlet engine (Resin in our case)
would authenticate and authorize the user based on the permissions we had
set up in the web.xml file based on the incoming path (so we could have
different roles required for various action and subaction combinations). The
action servlet would then direct the request to the right struts action
handler, which would forward to the appropritate view JSP. It was all
declarative and worked great in that respect. But the problem was that the
user's browser would still think that the returned page was at a path
'/cmd/action/subaction'. The JSP would think it was at a path '/'. So any
urls in the JSP file could not be relative. This is much too big a
constraint on the HTML coders. One approach we tried that _almost_ worked
was to come in on a request like
  /r.do?red=/cmd/action/subaction
where r.do was an action handler that did a redirecto to the url specified
by the 'red' parameter. This url would then be checked by the servlet
engine. This worked in all cases except where the user was forced to log in
by the servlet engine. The engine would store the redirected request path
(/cmd/action/subaction), redirect the user to the login page, and then do a
redirect back to the stored path, but now the browser would come in by the
second form of the request path (/cmd/action/subaction), and the issue with
JSPs and relative paths would rear it's head again.

What I am now doing is coming in with a url like
  /action-subaction.do
which is mapped in the action.xml in a standard fashion. What is changed
however is that I also added a 'validRoles' param in each mapping that we
want to restrict access on, and have a customized ActionServlet subclass
that checks if the user is in the proper role, forcing a login if needed,
and involves the servlet engine. I.e. it calls getUserPrincipal, knows the
user is not logged in if that returns null, redirects to a loging page in
that case, which has the special Servlet 2.2 'j_security_check' action. When
the engine gets that request, the user is authenticated. When the user gets
redirected back to the original URL, the ActionServlet then calls
IsUserInRole to see if the user is in one of the specified roles.

So does this have any sort of advantage over rolling your own
authentication/authorization, since it is almost all the way there? I think
it does in that it integrates into the engine's authentication/authorization
realm. Something like WebLogic (which we are not using at this point due to
bugs) has a decent number of authentication realms. We are using Resin, and
did write an LDAP authenticator plugin.

That was a lot of writing, I hope this was of use to someone!

Mime
View raw message