My current project is using Liferay 5.2.3 as a Portal container and Spring Security 3 to secure portlets. We are not using Liferay’s built-in permission systems as we expect to deliver our portlets on many different portal platforms. Therefore we decided to use Spring Security, specifically the 3.0 version, as Spring 3 supports the JSR-286 specification.

In the RC1 version of Spring Security 3.0 (SS3), the Portlet jar was dropped that was available in v2.0.5 (spring-security-portlet-2.0.x.jar).  That leaves us with a dilemma when it comes to securing portlets using SS3.  To implement security in a portlet in a JSR-168 context one would have to re-implement everything in the portlet jar to use an interceptor based way of adding an Authentication to the SecurityContext.

Rather than taking that path, Spring 3 supports JSR-286 portlet specification which allows for portlet filters.  Since a common way to implement security is through security filters, a portlet filter method seems like a viable alternative.  There is one main issue with using portlet filters in that Spring cannot be used to create or inject dependencies into the portlet filter.  (Maybe it can but I wasn’t able to get it to work).

Thus, I’ve created a PortletSecurityFilter filter that more or less follows the SS3 security process used in the Servlet side implementation (AbstractAuthenticationProcessingFilter).

What’s the point of doing this?  Well, we need to deploy our portlet to multiple portal containers.  Thus, if we use SS3 we can easily control our portlet roles and not have to rely on the portal implementation.

Process

The whole point of this exercise is to push an Authentication into the SecurityContext for SS3 to use later when verifying Role information.  We’ll create a PortletSecurityFilter to accomplish this push.

Warning, many might think of this as a hack to fool SS3.  If you’re okay with that then keep reading.

Portlet Lifecycle Location

The first question is in what portlet lifecycle should the filter live?  That depends but the best location is during the Action Phase.  Adding the filter at this point sets the SecurityContext early enough for both the Action and Render phases meaning SS3 will work for both annotation driven security as well as jsp rendering security.

PortletSecurityFilter

Below is the code for the PortletSecurityFilter.  Note that you will have to implement your own AuthenticationDetailsSource and AuthenticationManager for this to work.  You’ll notice this also throws the Authentication token onto the PortletSession for use in later requests.

package com.your.package.name;

import java.io.IOException;

import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletException;
import javax.portlet.PortletSession;
import javax.portlet.filter.ActionFilter;
import javax.portlet.filter.FilterChain;
import javax.portlet.filter.FilterConfig;
import javax.portlet.filter.PortletFilter;

import org.apache.log4j.Logger;
import org.springframework.security.authentication.AuthenticationDetailsSource;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;

/**
 * Implements security behavior for Spring Security 3.0.  Adds an Authentication to the
 * SecurityContext and to the PortletSession.  Spring Security picks up the
 * Authentication when it meets annotated methods with the @Secured annotation.
 */
public class PortletSecurityFilter implements PortletFilter, ActionFilter {

    private static Logger logger = Logger.getLogger(PortletSecurityFilter.class);
    private static final String SECURITY_TOKEN = "SECURITY_TOKEN";

    private AuthenticationDetailsSource authenticationDetailsSource = new PortletAuthenticationDetailsSource();
    private AuthenticationManager authenticationManager = new PortletAuthenticationManager();

    @Override
    /**
     * Follow the Spring Security method for an AuthenticationFilter.
     * @see AbstractAuthenticationProcessingFilter
     */
    public void doFilter(ActionRequest request, ActionResponse response, FilterChain chain) throws IOException, PortletException {
	if(request.getUserPrincipal() == null) {
	    // If no UserPrincipal from Portal stop the chain here.
	    return;
	}
	Authentication auth = (Authentication) request.getPortletSession().getAttribute(SECURITY_TOKEN);
	if(auth == null) {
	    PreAuthenticatedAuthenticationToken authToken = new PreAuthenticatedAuthenticationToken(request.getUserPrincipal(), request.getRemoteUser());
	    setDetails(request, authToken);
	    auth = authenticationManager.authenticate(authToken);
	}

        if(auth.isAuthenticated()) {
	    successfulAuthentication(request, response, auth);
	    chain.doFilter(request, response);
	    return;
        }
    }

    /**
     * Default behavior for successful authentication.
     *
     *	Sets the successful Authentication object on the {@link  SecurityContextHolder}
     *	Sets the Authentication onto the PortletSession
     *
     *
     * @see AbstractAuthenticationProcessingFilter
     * @param authResult the object returned from the  attemptAuthentication method.
     */
    protected void successfulAuthentication(ActionRequest request, ActionResponse response,
            Authentication authResult) throws IOException, PortletException {

        if (logger.isDebugEnabled()) {
            logger.debug("Authentication success. Updating SecurityContextHolder to contain: " + authResult);
        }
        SecurityContextHolder.getContext().setAuthentication(authResult);

	PortletSession session = request.getPortletSession();
	session.setAttribute(SECURITY_TOKEN, authResult);
    }

    /**
     * Implementation of setDetails.
     *
     * @see UsernamePasswordAuthenticationFilter
     * @param request that an authentication request is being created for
     * @param authRequest the authentication request object that should have its details set
     */
    protected void setDetails(ActionRequest request, PreAuthenticatedAuthenticationToken authRequest) {
        authRequest.setDetails(authenticationDetailsSource.buildDetails(request));
    }

    @Override
    public void destroy() {
	System.out.println("Action filter destroy.");
    }

    @Override
    public void init(FilterConfig arg0) throws PortletException {
	System.out.println("Action filter init.");
    }
}

portlet.xml

The next step is to add this portlet filter to the portlet.xml file.  After you have declared your portlets, insert the following filter declaration:

Spring Security 3.0 Configuration

We have to enable SS3 by creating an applicationContext-security.xml file.  Basically, all we really have to do is enable secure annotations so if you don’t want to create a new file than just throw this into your current applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
 http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"

>
<security:global-method-security secured-annotations="enabled"/>
<security:authentication-manager alias="authenticationManager" />

</beans>

web.xml

Finally, if you added a new applicationContext than you’ll need to add that to your web.xml as a new contextConfigLocation.  That path will depend on where you put the file but one path might be:

/WEB-INF/context/applicationContext-security.xml

Add Security

Now all you need to do is add @Secured notations to your protected services or <security:authorize> tags to your jsp.  Assuming you created an AuthenticationManager that added the proper GrantedAuthorities than your security should now work.

I did this with Liferay portal v5.2.3 and successfully secured my portlet outside of Liferay.  Of course Liferay provides you with methods to expose your portlet permissions and administer them through Liferay control panel but we did not want to use that method.

The Quality Analyst (QA) role in an Agile environment has significant importance.  In Agile, the QA is part of the development team and included from the start of the project.  QA is expected to be as up-to-date on requirements and system state as any developer.  QA is also continuously reviewing completed tasks and stories to near real-time feedback.  If there is one concept in Agile it is fast and continuous feedback on all fronts, QA is essential for this to become reality.

When running a mixed Agile/Waterfall development environment it can be difficult to engage the QA resources at the correct moment.  Generally QA is accustomed to having some large period of time, say six weeks, at the end of development where they test the entire system.  The argument for this type of testing is that at this point the code is “locked down” and thus they can test the system in peace (not pieces) without worrying about pesky developers changing things on them.  While this is a fine notion, it rarely happens and development often runs over the QA cycle.  Or, more importantly, QA finds issues that simply must be fixed.  In standard QA parlance, the QA team should start their testing from scratch after the changes are made to the code.

Agile QA

Agile has the idea of production ready functionality at the end of every iteration.  To do that, QA must be involved at the iteration level and be testing functionality as it develops.  If done correctly, at the end of the iteration the stories and components are ready to deploy to production.  Thus, unless major changes occur, these items only need regression testing from this point forward.

Embedded QA

Since QA is part of the development team, they are often co-located with the development team as well.  This gives the QA person a significant advantage, they are present when requirements changes are taking place and can express their opinions in real-time rather than after the fact.  The QA person can also help refine requirements by providing the customer’s view of the application.

Automated Testing

Once components are production ready, automated test scripts are created to compile a full suite of regression tests.  These automated tests combined with the developers Unit and Integration tests help ensure that any changes made during the current and future iterations do not adversely affect the previously tested code.

Deployment to Production

As with any project, the final push to production is often a hectic and hurried endeavor.  QA is usually under pressure to certify that the application works.  While Agile projects are sometimes (but hopefully not) just as frenzied, the existence of thoroughly tested components, automated QA test and development unit tests help ease the burden on the QA team.  While a full system test is still advisable before deploying to production, since QA has been involved from the beginning and is aware of all requirements modifications that have occurred throughout the life of the project, this task is not as onerous as in non-Agile environments.  There is not a lot of back and forth between QA, development and BAs about requirements changes that were not adequately documented.

Often times the true QA cycle, where code is “frozen”, can be cut down to one to two weeks as the QA team feels very comfortable with where the application is at when the cycle begins.

The Business Analyst role changes significantly in the Agile process.  Rather than doing all the requirements gathering up front and handing off the document to development, the BA becomes an essential part of the Agile team.  Often times this role is called the on-site customer or subject matter expert.

While the concept is great, the reality is that likely the BA has more than just this project on their plate and cannot devote 100% of their time to the project once it has begun.  This is fine as once the main portion of the requirements have been specified, the BA workload goes down but gets far more important.  While in the requirements gathering phase, if the BA has to take time to do other tasks, no one is really affected by the lost time.  If however, during the development phase the BA becomes unavailable, the project can be severely affected.

Availability is the Key

The BA can work on other issues if s/he is available to answer questions and make decisions in real-time for the project in progress.  The other main deliverable is requirements for the upcoming iteration.  As long as these two responsibilities are maintained, the development team will not notice that the BA is working more than one project.

Drive the Sports Car

Another new notion to BAs who wind up on Agile projects is the ability to control the direction of the project while it is in progress.

In the waterfall world, the project was much like launching a rocket, the BA loaded the payload with requirements, set the fuse, and blasted off the development.  Then they stepped back and either admired their great work hitting its target directly at some predetermined point in the future, or more likely they saw their rocket swerve off course and blow up in the ocean.  There was little to no control over the project and they didn’t even believe it was necessary.

With Agile, it is akin to stepping behind the wheel of sports car, in the right hands the car can perform wonders, in the wrong hands you still fly off the road, down a cliff, and crash into the ocean.  However, given proper fuel at appropriate times, gently nudged in the correct direction while accelerating quickly (but controlled), soon you’re cruising at 150 MPH and can make minute adjustments to keep you on the right track.

BA Role

What does all this mean for the BA role?  Essentially the BA is responsible for requirements and business decisions.  Requirements are tracked through the ALM system and should be in place a few days before iteration planning begins.  The BA also prioritizes requirements by their business value so the development team knows what is most important.  The BA should always be ahead of the development team and always available for questions.

The Project Manager (PM) role in an Agile environment is significantly different than in other development environments.  In most environments the PM role is a team leader who has control over all aspects of the development process.  Sorry to say that on an Agile project the PM is no longer the team leader but is a team member.  This is actually a good thing as the PM has a much more significant role than before in that their job is to ensure the team has a smooth road ahead of them and deflect any destabilizing forces.  No more will you have to file a report explaining why developer X took three hours to complete a task when the estimate was two hours.  No longer will you waste everyone’s time trying to “motivate” developers to work “smarter” while they look at you as if you were a crazy ranting lunatic.  Instead, the developers are self-motivated and inherently work productively.  They oftentimes will needle you as to what value you delivered today.

A quick review would likely help the PM acclimate to their new role.  For starters, since developers self-manage the tasks they work on, it is impossible to schedule individual developers to individual tasks.  So project plans simply become high level timeframes and milestones rather than highly detailed resource management schedules that are never realized.  Also, since all the work tasks are not known up front, it is again impossible to create a meaningful detailed project plan.

Now that all your time has been freed up from updating a project plan with what actually happened (backward looking) it is time to start looking forward and determining what problems will occur in the immediate, near-term and long-term timeframes that can be “managed” away.

The first problem is to ensure an adequate, properly prioritized flow of requirements (stories) to the development team at the appropriate times.  Ideally, within an iteration based development team, enough stories to fill an iteration (plus a few extra) should be ready at least a couple days before the iteration begins.  It is your role to ensure that the requirements meetings take place, that prioritizations are in place and communicated, and that the ALM system is updated with the stories before iteration planning begins.

The second problem is usually around deployment and testing environments.  These usually require a large amount of time that occupies a developer in ensuring that environments are configured correctly, fixing issues and meeting with infrastructure engineers to ensure the development team’s needs are met.  The PM should take over the management of this process and only involve the development team when technical questions need answers.  Here is a where a traditional project plan can be helpful since infrastructure is usually more of a linear, step by step process.

The third problem is really an abstraction of the second problem, dealing with outside group integrations.  Since it is unlikely that outside groups are working in an Agile fashion, they will likely require project plans and many meetings to perform integrations with the new development project.  Again, the PM can take over the interactions with outside groups, supply project plans and ensure that the outside group’s timeframe matches the agile project’s timeframe.  Exact timeframe matchups are unlikely but getting within a few days (or weeks)  is usually possible.

The final problem may actually be the largest problem and that is managing the project scope.  Since no large planning effort occurred up front, it often seems simple to add new requirements and pile on functionality.  The PM needs to act as a gateway through which work not related to the project fails to pass through.  Similarly, the PM must ensure that changes to requirements are adequately estimated and prioritized, and that if new requirements are prioritized into a release, than an equal amount of existing requirements are prioritized out of a release (or some other accommodation made).

Remember, the PM role is no longer where are you at today and how does that affect the schedule for I am the supreme leader of the team, but instead it is how have I contributed to team today and what problems are out on the horizon that need to be planned for now to minimize their risks.  If the PM does their job correctly, the development team will run like clockwork, iteration to iteration on to deployment of releases and won’t even mind that the PM is there.

Any way to tell grails to treat individual classes as a “Service”?

If you receive this message when Tomcat starts through Eclipse:

WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property ‘source’ to ‘org.eclipse.jst.j2ee.server:YOURAPPXXXXX’ did not find a matching property.

Then follow the simple steps to fix it.

1. Double click on your Tomcat from the Servers view to open the Tomcat editor window.
2. Under Server Options on the lower left, click the checkbox for Publish module contexts to separate XML files
3. Save and restart.
4. Hopefully this fixes your problem.

Upon reflection, it came down to one thing, the development groups that attempted to conform to the Universal (Waterfall) process basically got nowhere and had large numbers of developers creating very little besides documentation.   Conformance with the process led to poor performance.

My group bypassed the process and treated it more like an interface, we delivered all the required documents in the process to the minimum possible acceptable level.  We also insisted that the product/business groups participate in the development process by coming to the daily standup and spending some time in the dev lab.  Our group was acknowledged throughout the division as having high performance.

My conversation with my manager about the way my team works at my review:

Manger:  Your group can continue to use its development process as long as you conform to the Universal process.

Me: We are conforming to the Universal process, we delivered all the required documents necessary to deploy the application to production.

Manger: That’s true, but you didn’t conform to the process.

Me: I can’t conform to the process and continue to use our Agile processes, they’re incompatible.

Manager: Than you’d better learn to conform to the Universal process.

Me:  You just said I could continue to use our Agile processes, but we can’t do that if we have to wait months for perfect requirements and then be unable to communicate with our business partners.

Manager:  It will be in your best interest.

Me:  I understand.

So what I realized was upper level management didn’t care much for performance if it didn’t follow their development process.  I can understand that theorhetically, but everyone knew we were under the gun to deliver a massive project by 1/1/09 that if it failed the company was likely to lose a Fortune 50 client.  Using the Universal process would never have worked and everyone looked the other way while we cranked out the app.  Then on judgement day you get knocked for not following the process.

Advice:  if you want to further your career as a manager in a large company, conform to the processes and use your excuses that no one else delivered for the reason your team didn’t perform.  All those people got promotions this year.

Steps for experienced Java developers to get up to speed on Grails in 3 days:

Day 1:

1) Find a Grails book such as this free online book (http://www.infoq.com/minibooks/grails) or the one I used(http://www.amazon.com/Definitive-Grails-Second-Experts-Development/dp/1590599950/ref=sr_1_1?ie=UTF8&s=books&qid=1239831441&sr=1-1).

2) Follow the directions to get Grails installed on your system.  I’m assuming you already have a Java workspace built out likely using Eclipse or IntelliJ.

3) Realize that Grails is built on Groovy, a scripting language, and its purpose is to either generate your code for you or generate it dynamically at runtime.

Day 2:

1) Start running through the book, you should probably be able to work through all the relevant examples to building a web application in about a day.

2) Came to the realization that you could have all your domain validation embedded in the domain object extremely easily.  Cool, something I’ve always wanted.  

Day 3:

1) Start writing your own app.

2) Get your head around conventions being the way everything is done.  Learning the conventions and getting used to them is the hardest part.

3) Be amazed by how fast you can build out a domain and CRUD view/edit screens.

Now it’s really that simple.  Maybe later this week we’ll see how difficult it is if you want to make customizations to all this generated code.