Re: [ajug-members]: User authentication in web app

[Rob Kischuk <rkischuk@gttx.org>]

You mention checking the authorization of the user at 2 levels - the 
presentation tier, to give the user a clean view of what they can do, 
and the back end, to ensure they don't do things they shouldn't be able 
to do.  The first thing to understand is that J2EE security readily 
supports the association of users and roles, and this information is 
kept as part of the user's session.

For keeping your view clean, the most direct way to check authorization 
is with HttpServletRequest.isUserInRole( String ) - which returns true 
if the user is in the requested role, otherwise false.  By embedding the 
code you want show inside an if statement:

<% if (req.isUserInRole("admin")) { %>
   <show stuff>
<%}%>

you can ensure that the content is shown only to those who are 
authorized to see it.  For those who don't like scriptlets in their JSP, 
the request taglib from the jakarta taglibs project 
(http://jakarta.apache.org/taglibs/index.html) has a simple tag that 
fits the bill:

<req:isUserInRole role="admin">
  <show stuff>
</req:isUserInRole>

For securing your app on the back end, you have a couple of options.  If 
your security can be described in patterns (like if all admin 
functionality is under the /admin/ path, or admin.so is a struts action 
that handles admin functionality), you can declaratively specify the 
secured resources and allowed roles in your web.xml, and the container 
will ensure that only authorized users access those resources.  If, 
however, you have something that is not easily described with a pattern 
(such as a struts dispatch action), you can also use 
request.isUserInRole() in your servlet or struts action - if a user 
isn't authorized, redirect them to the 403/Forbidden error (or whatever 
action you want to take).  Struts can apparently also handle some 
security with role-based authorization, but I've never really messed 
with it.

You could conceivably write a struts action to show different pages 
based on the user, but I've found that many situations are best solved 
by using the same page, selectively omitting items that the user isn't 
authorized to see.

-Rob

Scott P. Smith wrote:

>Rob & Chandra,
>
>That's great information.  Thanks.
>
>At my last job, we had pages where different parts of the page had
>different permissions associated with them.  So two different people
>with different roles would see different options on the page.  Some
>roles could just view certain data while other roles could edit.  We
>chose to use entirely custom logon/authentication with our own custom
>tag library that would hide or show portions of the page based on the
>user's role.  Of course, the back end (we used struts) would also check
>the user's permissions against the action he was trying to perform.
>
>Can container managed security handle this kind of sub-page level access
>control?
>
>I can image that struts could display a different page, based on the
>user's role, but I don't think it could do that back when I was using it
>(3 years ago).
>
>I have never used container managed security so I'm picking your brains,
>while I have the chance.  
>
>Thanks,
>
>Scott
>  
>