AppFuseSecurityMethods

This is version 3. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

This document is a work in progress, don't count on this actually working yet.

This How To will walk you through the steps of adding Acegi Security role based Method Invocation authorization to your AppFuse project. Since that sentance already makes it sound like we are doing something complicated, let's break that down so we can see what we are doing and why it is useful.

Acegi Security is a security framework that is build using the techniques of the Spring Framework and is made to integrate easily into projects that utilize Spring, such as any application built on AppFuse 1.4 or newer (if your AppFuse app is older than 1.4 there is a tutorial for migrating your app to use the Spring Framework). The first level of Acegi integration into AppFuse is authentication and authorization to access URI's based on user roles, and this tutorial will assume you have already completed the migration from container managed security to use Acegi authentication. The next level is to grant or deny user access to methods of our service classes based on the user's role(s). Once you have completed this you may want to go on to adding Access Control List authorization for a more fine grained control.

Table of Contents

• [0] Prerequisites
• [1] (Optional) Add acegi .jar to your Eclipse classpath
• [2] Add public Methods
• [3] Prepare your Actions
• [3] Configure the MethodSecurityInterceptor

Prerequisites [#0]

You will also have to replace container managed security with the Acegi FilterInvocation Security Interceptor.

Add acegi .jar to your Eclipse classpath [#1]

myproject/lib/spring-1.1.3/acegi-security-0.7-SNAPSHOT.jar

Add public Methods [#2]

Prepare your Actions [#3]

import net.sf.acegisecurity.AccessDeniedException;

...

    /**
     * Override the execute method in LookupDispatchAction to parse
     * URLs and forward to methods without parameters.  Also will
     * forward to unspecified method when no parameter is present.
     * <p/>
     * Will forward to a 403 server error in the case the user does
     * not have authorization to access a manager method being invoked. 
     * <p/>
     * This is based on the following system:
     * <p/>
     * <ul>
     * <li>edit*.html -> edit method</li>
     * <li>save*.html -> save method</li>
     * <li>view*.html -> search method</li>
     * </ul>
     *
     * @param mapping  The ActionMapping used to select this instance
     * @param request  The HTTP request we are processing
     * @param response The HTTP response we are creating
     * @param form     The optional ActionForm bean for this request (if any)
     * @return Describes where and how control should be forwarded.
     * @throws Exception if an error occurs
     */
    public ActionForward execute(ActionMapping mapping, ActionForm form,
                                 HttpServletRequest request,
                                 HttpServletResponse response)
            throws Exception {
        
        // Capture an AccessDeniedException thrown by Acegi Security 
        //    and redirect to the 403 server error page
        try {
            
            if (isCancelled(request)) {
                ActionForward af = cancelled(mapping, form, request, response);
                
                if (af != null) {
                    return af;
                }
            }
            
            MessageResources resources = getResources(request);
            
            // Identify the localized message for the cancel button
            String edit = resources.getMessage(Locale.ENGLISH, "button.edit").toLowerCase();
            String save = resources.getMessage(Locale.ENGLISH, "button.save").toLowerCase();
            String search = resources.getMessage(Locale.ENGLISH, "button.search").toLowerCase();
            String view = resources.getMessage(Locale.ENGLISH, "button.view").toLowerCase();
            String[] rules = {edit, save, search, view};
            
            // Identify the request parameter containing the method name
            String parameter = mapping.getParameter();
            
            // don't set keyName unless it's defined on the action-mapping
            // no keyName -> unspecified will be called
            String keyName = null;
            
            if (parameter != null) {
                keyName = request.getParameter(parameter);
            }
            
            if ((keyName == null) || (keyName.length() == 0)) {
                for (int i = 0; i < rules.length; i++) {
                    // apply the rules for automatically appending the method name
                    if (request.getServletPath().indexOf(rules[i]) > -1) {
                        return dispatchMethod(mapping, form, request, response, rules[i]);
                    }
                }
                
                return this.unspecified(mapping, form, request, response);
            }
            
            // Identify the string to lookup
            String methodName =
                getMethodName(mapping, form, request, response, parameter);
            
            return dispatchMethod(mapping, form, request, response, methodName);
        } catch (AccessDeniedException ade) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN);
            return null;   
        }
    }

The second consideration for Actions is that public actions (any action that does not require the user to be logged on) can only access public methods on our manager beans. When AppFuse comes out of the box the only action that needs to be modified is SignupAction. We will need to remove the code that automagically used to log in a user after signup. It would be possible to still do this, but it is fairly complicated and it's not really that important to me to make the user not have to log in right after creating his account. But the problem with leaving that code in is that is would cause one of the decorator pages to try and access UserManager.getUser() which is protected and an AccessDeniedException will be thrown since our user is not yet logged in. So remove this section of code from SignupAction:

            // Set cookies for auto-magical login ;-)
            String loginCookie = mgr.createLoginCookie(user.getUsername());
            RequestUtil.setCookie(response, Constants.LOGIN_COOKIE,
                    loginCookie, request.getContextPath());

Configure the MethodSecurityInterceptor [#3]