Spring Security - holistic solution for securing web applications

Performance and should be considered as most important non-functional requirements while working on technical architecture. Usually enough consideration is done for performance while security is not contemplated that much. Security framework is plugged-in once complete application is already implemented. Typical approach is to have security checks scattered throughout the application. With increasing number of electronic transactions involving business critical data this trend needs to change. Business are feeling need for comprehensive security of data in rest and in motion. Increasingly it is becoming imperative to incorporate great security infrastructure in application. This is driven by business needs as well as laws governing compliance requirements for various industry e.g. HIPAA, GLM, SOX.

Home grown solution developed to apply security in a web application is not unusual. Few years back, I worked on an insurance application with custom security framework. It requirements well and the application was HIPAA compliant. But it was technically very challenging to perform , maintenance and tweaking of the framework was tedious. Moreover, implementing security in a similar application resulted in complete rewrite of security framework .

To alleviate these issues, spring framework has come up with excellent security framework. It provides out of the box security solution that can be used in majority of applications as-is. Framework is easy to understand and implement and security can be speedily applied to most of the applications. I used most in last sentence as in our case understanding framework was easy but application required lots of thinking and effort. We used spring security in a completely different avatar requiring loads of creativity and patience to get desired results. We faced problems during our journey but eventually tweaked spring security to suit our requirements. In this blog, I'll describe various spring security features for authentication and authorization and the tweaking we did to make framework suit our requirements.

Authentication with spring security works on filter-based approach and there are multiple mechanisms (Digest, Basic, CAS, DB, LDAP) to implement authentication. It is very easy to use spring security in a application developed with traditional JSP-based MVC framework viz. Struts. Spring security provides multiple encoding algorithms viz. base64, md5, SHA. Best part is that all this is easily configurable and actual processing is left to spring security. Mechanism to tackle frequent problems like concurrent session handling, logout, session fixation, remember-me are simple and easy to use in configurable manner. Spring security provides a chain of providers so that you can have your application authenticate via database and then via ldap if the previous one fails or any other combination as per your needs. Sprig security provides very easy approach to localize all the default error messages it provides, provides channel security if HTTPS is required and this can again be done via configuration. Spring security provides very easy Basic authentication for authenticating requests from web-services / XML-RPC requests where authentication information is provided in request header. We did require to do some tweaking because we are using GWT, AJAX framework, as we were required to customize Authentication entry point and exception translation filter so that AJAX response can be sent in case user is unauthorized rather than redirecting the user to login page as is normally done. Spring security has come up with all possible combinations for all security needs for example, if you need to do authentication via LDAP then you can use bind authentication of passwordencoder authentication as required.

Applying authorization to UI object using Spring Security is very easy, especially If you are using JSP based MVC framework like Struts. It is very easy to hide or display controls based on available permissions using tag libraries provided by Spring. But, since we are using GWT, an AJAX based framework we needed to come up with customized approach . Our approach is to access database on module load to fetch all permissions and save these in memory. Later, while UI creation, these permissions stored in memory are used for controlling display of UI objects.

To implement authorization on objects, spring security provides a db model which can be used in most of applications. Though, In our case because of stringent requirements for granular authorization on different objects, we were required to come up with customized db model and a custom approach. One more disadvantage we found with default approach is that Spring Security uses after-invocation to filter out objects. This means incase there are thousand of object then first all records are retrieved and then desired ones are filtered out. For us, this was a performance problem because of very high transaction volume in our application.

Owing to above mentioned reason, we tweaked db model. Additionally, we used spring method interceptor to enable Hibernate Filters and to set required parameters. Hibernate filters were used to filter out data at database layer itself so as to achieve performance benefits. Additionally , we used Mvel2, an expression language to enforce operation permissions on objects e.g. for delete on customer object. One more interesting fact in default functionality provided by Spring security is that it provides role voter. Incase, requirement is to have role definition and provide security on the basis of role then default implementation can be used. If application data is not huge in your application, then default ACL based approach should work fine.

Spring security helped us in other modules like Auditing. Since Spring security raises events for login, logout, session timeout, authentication failure we could easily capture these events for auditing purpose.

Since we are covering security I will briefly touch base on other additional measures for security e.g. using SSL for transport security, message encryption for message transfer security, partitioning and encryption of data in database. You would also be required to implement a solid auditing framework to audit and record all access to sensitive application.

Looking back through our express, I will recommend Spring security for any J2EE web application. Depending on requirements, you can use default security framework or tweak it as we did. My suggestion is to be ready for challenges and to get a firm knowledge of the framework incase you decide to tread the relatively difficult path of implementing granular security as we did.

[End]

GWT for RIA – boon for Java (dev)lovers

Recently, I have been working on porting Struts, uPortal based legacy application to GWT. This work was initiated a year back to replace unappealing, non-responsive and slow user interface. Other requirement was to make client side technology stack lighter. Presence of lots of client side technologies (Struts, uPortal, JSP, Tag libraries, Java Script, Configuration files, CSS, XSLT) made it cumbersome to implement simple UI changes.

After initial analysis, we were clear on requirement of more AJAX effect across application. It was further evident that AJAX framework should be preferred rather than writing AJAX "by hand". After evaluating some AJAX frameworks, we decided to go with GWT. Other frameworks like DOJO and YUI library are good in adding AJAX effect to existing application but they did not solve some problems related to fat architecture and big technology stack.

One of the primary reasons for going with GWT was its unique approach to develop complete application: client side, server side using Java. GUI development with GWT APIs is similar to Swing development and it is refreshing to forget JSP, JavaScript, and Struts and write everything using Java. I am very happy with experience so far and we have vastly improved presentation layer while retaining service layer.

With GWT, AJAX front-end is written in Java that gets compiled into highly optimized Java Script. Developers need not write Java Script while end users are provided with dynamic and standards-compliant AJAX experience. On deployment, JavaScript gets downloaded on the browser thus releasing the server side from handling presentation stuff.

I am overwhelmed by many developer friendly features of GWT. Usage of Java in presentation layer facilitates applying design patterns and creating reusable widget library. GWT approach for history management, internationalization, and service layer interaction is easy to understand and implement. I felt spoilt by choice of available tools, default support for all browsers and ability to debug AJAX in Hosted mode. I also noticed intangible benefits like elimination of training on multiple technologies, reduced dependence on technology experts, and reduced development cycle.

I have heard arguments that Flex is a better RIA choice than GWT. I think this may be because of lack of availability of all widgets in GWT. GWT does inherently provide lots of cool widgets but it is possible to use third party widget libraries if they are not sufficient. We used GWT-EXT, a very rich widget library.

I found some essential features i.e. lack of multiple module support, lazy loading of modules missing that may make GWT misfit for huge enterprise applications. I also faced some problems due lack of emulators for Java packages used in existing server side code.  Good thing is that there are workarounds available to solve these problems. I strongly recommend GWT if you are developing midsize application and need desktop-like look-n-feel.

Should I retire my application?

Application software as a product has very short shelf life. In a typical product, one goes through conceptualize, construct, QA, bug fixing cycle and one fine day it goes LIVE. Suddenly, there is mayhem with customers digging out issues QA never found, demanding features never signed off but are critical, reporting issues not reproducible in staging / development.

Eventually everything settles down with issues either fixed or workarounds provided. There are happy customers getting business benefits supported by happy developers providing enhancements for life. Right? Wrong after a lull period everyone starts complaining again.

Customers complain they are not getting required benefits from application; new features are breaking existing components. Technical supports guys complain that the workarounds are irritating; components just freeze at peak load. Developers complain it takes ages to deliver simple enhancements. And the list goes on.

Hence start talks of retiring and rebuilding application from scratch. Since everyone is unhappy it should be easy to decide in favor of retiring legacy application. Right? Wrong; I have never found it easy to retire a running application. I always find it better to rebuild specific components incrementally.

I find it tough to take a decision on retiring application and suppose everyone faces similar dilemma. Every situation is unique and decision will differ from project to project and client to client. I have a checklist of items to look for while deciding to retire or rebuild an application. I hope it would be helpful to someone making similar decision:

Desktop to web application

You have a desktop application developed couple of years back for target customers. There is great feedback and everyone is telling you about its great potential and how you should reach out. You learn about benefits of SaaS offerings but cannot move forward since application is not web enabled.

It is easy to decide to move to web enabled application but complexity arrives with possible choices. I worked on a project where client had a swing based desktop application that needed to be web enabled. We mulled on options to make it either browser based using Applet – Servlet communication / JWS or make it complete web application by rewriting complete solution using MVC framework. In that case we decided to go with JWS route since client was unsure of quantum of benefits and wanted to go live soon with minimal cost.

Problems with one layer

You have an application with multi-tiered architecture and majority of problems are reported in one layer. In this case we need to make a decision to improve or retire-rebuild this layer.

I worked on an application where problems were specific to Presentation layer. In that case, we replaced Struts, uPortal based presentation layer with GWT based web2.0 enabled presentation layer. You can read more about my experience in an earlier post here.

 

 

Home-grown solutions to standard technologies

Initially in my career, I worked on couple of very successful products developed with homegrown architecture. MVC frameworks like Struts were not readily available and many companies have come up with their own version.

One of these was a hugely popular insurance product suite. There were many requests for customization and enhancements. But, because of certain inherent flaws in core architecture, enhancements were either taking long time or were deferred. It was decided to rewrite product with WebWork, Hibernate and Spring. It turned out to be very good decision and helped in making product more popular. This was a big decision taken after careful consideration but there are simple cases. I recently worked on a project where we easily replaced home-grown wrapper component on Quartz with Quartz integration provided by Spring.

Redundant / over-designed features

Occasionally there are features in product never or rarely used. This leads to problems while implementing enhancements. Dependencies need to be fixed and tested in these seldom used features. Maintenance cost is skewed and money is being spent on useless stuff. In some cases, it may make sense to remove or simplify these components.

I worked in maintenance of a project with a component to show workflow change notifications on dashboard and to send them via email. Component served its purpose but had very complex subscription logic, notification control features with many options. Lots of issues were reported from production and most cases were due to lack of understanding. We redesigned this component and removed whole lots of complexity (and code) making component much easier to use.

Non availability of resources

There are products with no problem apart from the fact that they are built on technology for which there are not enough developers available. This leads to resource dependencies and it becomes very difficult to maintain application even if enhancement part is left. Sometimes,  in these cases it may make sense to shift gradually to newer technologies.

Modernizing application

Sometimes there are modern concept out there in market you just cannot ignore. For example, many application have been migrating to Service Oriented Architecture or OSGi off late. 

 

I covered some scenarios but know there are many left. It would always be difficult to retire an application and in each case proper cost benefit analysis needs to be done. Sometimes, retiring-rebuilding may look better option but on probing further it may emerge that existing component can be improved.

I worked on a text search component in a recruitment application. It took hours and sometimes days to index resumes and other documents. Customers and technical support was unhappy and initially it looked like worth rewriting. But the product has just started getting real customers and it was decided to wait. It worked with some minor fixes and workarounds for more than a year when it was eventually rewritten when more information was available and other components were being modified. I told you every situation is different and there are no hard and fast rules.

[End]