Just authenticate() and hasRole() methods on our user object and utilizing
the session.

I think the java community added too much functionality to the container
level authentication earlier on, and people have become increasingly tempted
to use that (the whole Realms thing) for application level authentication.
That issue snowballed, and now there is a lot of container level
authentication functionality but it is like using a sledge hammer to drive a
nail IMO.

Realms is good for protecting an entire site (for example before launch or
adding extra protection to a backoffice section or something - htaccess
style).

Of course if you need single signon or to authenticate against ldap or
something the jaas style authentication is great, but how often does that
come up in web apps. All just my opinion of course.

-- Eric


> -----Original Message-----
> From: Adam Lipscombe [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 17, 2004 11:04 AM
> To: 'Struts Users Mailing List'
> Subject: FW: Specifying JAAS permission on a per-action basis
> 
> Sorry, I forgot to ask - 
> 
> Are you still using JAAS/Tagish authentication to log a User 
> in and set up a
> Principal etc?
> If not how do you do this?
> 
> TIA -Adam
> 
> 
> -----Original Message-----
> From: Adam Lipscombe [mailto:[EMAIL PROTECTED] 
> Sent: 17 June 2004 16:02
> To: 'Struts Users Mailing List'
> Subject: RE: Specifying JAAS permission on a per-action basis
> 
> 
> Many thanks Eric - its easy when you know how :-)
> 
> 
> I am interested to know why you chose this approach over the  tagish /
> http://www.mooreds.com/jaas.html solution? Did you hit problems ?
> 
> 
> TIA - Adam
> 
> 
> 
> 
> -----Original Message-----
> From: Eric Dahnke [mailto:[EMAIL PROTECTED] 
> Sent: 17 June 2004 15:33
> To: 'Struts Users Mailing List'
> Subject: RE: Specifying JAAS permission on a per-action basis
> 
> 
> 
> I just did this, and found it extremely simple. I eventually 
> went away from
> the tagish / http://www.mooreds.com/jaas.html solution. 
> 
> Three steps is all it takes:
> 
> -1- add this to your struts-config
> 
>     <controller
>  
> processorClass="com.ourcompany.portal.site.struts.action.Custo
> mRequestProces
> sor"/>
> 
> -2- Code
> 
> // The Struts Tiles plugin implements its own 
> RequestProcessor, so if you
> want // to use your RequestProcessor alongside the Tiles' 
> RequestProcessor,
> make // sure your processor extends TilesRequestProcessor instead of
> RequestProcessor public class CustomRequestProcessor extends
> TilesRequestProcessor {
> 
>     protected boolean processRoles(HttpServletRequest request,
>                                    HttpServletResponse response,
>                                    ActionMapping mapping)
>             throws IOException, ServletException {
> 
>         // Is this action protected by role requirements?
>         String roles[] = mapping.getRoleNames();
>         if ((roles == null) || (roles.length < 1)) {
>             return (true);
>         }
> 
>         // Check the current user against the list of required roles
>         HttpSession session = request.getSession();
>         User user = (User) session.getAttribute("user");
> 
>         if (user == null) {
>             response.sendRedirect("noSessionAvailable.do");
>             return false;
>         }
> 
>         for (int i = 0; i < roles.length; i++) {
>             if (user.hasRole(roles[i])) {
>                 return (true);
>             }
>         }
> 
>         response.sendRedirect("errorNotAuthorized.do");
>         return (false);
>     }
> 
> }
> 
> -3- add roles attributes to your action elements in struts-config
> 
>         <action path="/billingInformationEdit"
>             type="org.apache.struts.actions.ForwardAction"
>             parameter="/pages/billingInformationEdit.jsp"
>             roles="registeredUser"
>             >
>             <set-property property="secure" value="true"/>
>         </action> 
> 
> 
> HTH - Eric
> 
> 
> > -----Original Message-----
> > From: David Friedman [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 17, 2004 9:15 AM
> > To: Struts Users Mailing List
> > Subject: RE: Specifying JAAS permission on a per-action basis
> > 
> > Pow2ACL http://pow2acl.sourceforge.net/index.html
> > might fit your JAAS high-end needs.   It also integrates
> > with Struts.
> > 
> > Regards,
> > David
> > 
> > -----Original Message-----
> > From: Adam Lipscombe [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 17, 2004 9:02 AM
> > To: 'Struts Users Mailing List'
> > Subject: Specifying JAAS permission on a per-action basis
> > 
> > 
> > Folks,
> > 
> > 
> > I am using JAAS with the Tagish libraries to authenticate 
> users via a 
> > JDBC lookup. This works.
> > 
> > 
> > What I need to do now is to specify permissions on an 
> action-by-action
> > basis, but I am unclear about how this is achieved...
> > 
> > Dan Moore's excellent tutorial at http://www.mooreds.com/jaas.html 
> > shows an example of setting permissions via a policy configuration
> > file ("Example 8.
> > Sample JAAS policy file").
> > 
> > I have also read that its possible to specify permission 
> via a "roles"
> > attribute on the action mapping definition in the struts-config.xml 
> > file.
> > 
> > 
> > Does anyone know if these approaches to permission setting are 
> > complimentary or mutually exclusive?
> > Does anyone know which is the best?
> > 
> > I would prefer to set the perms in struts-config if 
> possible, if only 
> > to keep all the config in the same file. An example of setting
> > perms this way
> > would be great.
> > 
> > 
> > 
> > TIA - Adam
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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

Reply via email to