[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



That's great.  Thanks much.

On Tue, 2004-03-16 at 13:12, Rob Kischuk wrote:
> 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
> >  
> >
> 
>