May 31, 2012

Security annotations in Spring Controller methods


There are few things you need to know for securing your controller methods using security annotations.You will need to first configure global-method-security in you context

<sec:global-method-security    secured-annotations="enabled" pre-post-annotations="enabled"/>

If you method annotations are @Secured set secured-annotations=enabled and if you plan to use @PreAuthorize or @PostAuthorize enable pre-post-annotations=enabled.

The placement of this tag is also important, you need to place this tag in your mvc-context.xml instead of security-context.xml, your mvc-context.xml is the one configured for the DispatcherServlet.

Web.xml

<context-param>
              <param-name>contextConfigLocation</param-name>
              <param-value>/WEB-INF/spring/mvc-context.xml /WEB-INF/spring/security-context.xml</param-value>
       </context-param>
<!-- Processes application requests -->
       <servlet>
              <servlet-name>appServlet</servlet-name>
              <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
              <init-param>
                     <param-name>contextConfigLocation</param-name>
                     <param-value>/WEB-INF/spring/mvc-context.xml</param-value>
              </init-param>
              <load-on-startup>1</load-on-startup>
       </servlet>


There are suggestions to place global-method-security tag after component-scan tag in your context, but I didn't think it made any difference in my case.

<context:component-scan base-package="com.ironmountain.imconnect" />
<sec:global-method-security    secured-annotations="enabled" pre-post-annotations="enabled"/>



After this, you might hit Add CGLIB to the class path exception during initialization:

Initialization of bean failed; nested exception is org.springframework.aop.framework.AopConfigException: Cannot proxy target class because CGLIB2 is not available. Add CGLIB to the class path or specify proxy interfaces.


If so, you will need to add dependency for CGLIB.

The reason you need CGLIB is that, by default, Spring uses Java Dynamic Proxies to implement Aspect Oriented Programming support. This requires you to "program to interfaces rather than classes".
But we like to leverage component-scan wiring for controllers using @Controller annotation, which means controller are concrete classes and not implementation classes.
Meaning we need to generate class level proxies for security annotated classes, which requires CGLIB dependency.

So all this got my security annotation to work for access denied scenarios, but for  success scenarios I still got this error after the method was properly executed.

No mapping found for HTTP request with URI [/imchome/app/users] in DispatcherServlet with name 'appServlet'

My controller was declared as
@Controller
@RequestMapping(value = "/users")
public class ManageUsersController implements InitializingBean
{

And I had configured Tuckey’s URLrewriting filter to clean the URL from /imchome/app/users to /imchome/users.

My Controller worked perfectly fine, if I removed the secured annotations.

After hours of debugging, I realized that the problem was that my controller was implementing InitlizingBean interface.
By implementing InitlizingBean interface my controller became an implementation class, which should be wired through interface using spring’s dynamic proxy. Since I was creating the controller using component-scan as a concerete class, it was giving problem.

My solution was to not have my controller implement InitlizingBean.

So to get the security annotation to work (Spring AOP), you either need to have an implementation class created through its interface using Spring’s dynamic proxy or have a concrete class which generates a dynamic class proxy using CGLIB. PS: even if you implement a blank interface, you will need to follow the first option.

May 21, 2012

Portal - Crushed under its own weight

Enterprise Portal is a web interface that provides single-entry for the enterprise’s products and services to its end users.Sounds like a simple web-page with links to enterprise’s applications, but then you hear about Portal Technology, Portal Server, Portal Standards, Portal Developers …., and  the scariest  of all "Portal Cost". It makes you wonder, how can a simple webpag,e be so outrageously expensive and highly complex.

It may have something to do with the way Portal Products are sold. Portal vendor sell Portal as packaged bundle of tools that allow enterprises to quickly develop and deploy their portals. A typical Portal toolset consists of tools for Content Management, Identity & Access Management, Personalization & Customization, Federation and Integration.

 All these tools do sound like something an enterprise would need, I am not sure i fthat is always the case.The fact is that inspite of the high investment in Portal, most enterprises are far from reaping its benefits. 

·         Not so quick development and deployment: Due to high cost and bulky infrastructure, there are usually limited shared test environments, causing projects to contend for testing time and wait for availability of test environment. It is hard to make all portal components available on developer’s workstation, this impacts development and unit testing time, impacting project schedule and code quality.

·         Limited Skillset availability : Portal technology requires specialized skillset that are hard to find. Also, in most cases there is need for engaging product consultants, which adds to the cost and can be time consuming.

·         Not so easy: The so called out-of-box and ready to use portal features don’t look as easy when it comes time to implement them. Application Integration is one of the basic capabilities of most Portal products, but technologies for integrating non Portal apps like WebClipper and WSRP are way too complex to implement. There are times when vendors themselves discourage to use these solutions.

·         Not real use-cases that can leverage Portal paid-for features like Personalization.

If one is to compare the investment in Portal vs the features that enterprises actually leverage, it becomes apparent that existing Portal is way too complex solution for the problem in hand (single entry point).

It has been over a decade since Portal products came to market; a lot has changed since, especially in open source world. There are better technology options for quick development and deployment of portal features. Some suggestions of open source alternatives for building your own portal on a regular Application server (I used VMWare’s tcServer):

Web2.0 toolkits –ExtJS -Provide easy and customizable User Interface, which is way cooler and easy to implement then Portlets. It comes with an excellent Portlet APIs that will have you Portal up in no time, even on an Apache WebServer, thaz too skinny..
ExtJS also have great support for application integration (alternative of Portlet)-  ExtJS Tab Panel allows you to open a browser-like tab within the your application, which can be managed independently. 
We also used ExtJS iFrame Architecture to embed an existing app (alternative of WebClipper/WSRP)

Spring Security provides an excellent option for Identity and Access Management.
Spring MVC/ REST services – Rendering services for UI.
Federated Search – Solr is an excellent solution for federated search.
Content Management - Alfresco

I think enterprises should re-assess their ROI from Portal investment against these Open Source alternatives. Enterprises are in a better position to avail the flexibility of selecting just the right tools that meet their specific Enterprise Portal needs and thus keep the their cost low and stay lean.