Hard Code

Security is one of the key aspect of an application, especially web application. In our application we intend to integrate Spring Security as we are already on Spring framework. Alternative was Apache Shiro. But we prefer Spring Security. Here is how we can integrate Spring Security with Spring MVC and Thymeleaf. The first step to this integration is to include the Spring Security and Thymeleaf Spring Security jars into our application. This can be done by adding Maven dependencies. Here is the snippet from the parent/pom.xml file. Listing 1 - parent/pom.xml - snippet <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- SPRING SECURITY --> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-config</artifactId> <version>${spring-security.version}</version> </dependency>...

This is going to be a series of posts in which I will try to demonstrate how to build a complex modular Spring web application. We will use progressive enhancement to slowly improve and build this application. So what are we going to build? OK here is a small set of requirement we will try to cater : Requirements Sign in user Sign out user Create a lead Edit lead List lead Copy lead View History of lead changes Send mails to these leads as part of some camapign Delete lead Some non functional requirements I will look into are: Modular application module - so that it should seamlessly include a new module. Lets say tomorrow we want to include an opportunity module it should work by dropping in a jar with views, navigation, menu items, context menu etc - just with server restart. Must be able to support NoSQL stores with minimal changes. I have generally selected the following as my tool and technologies: Spring Framework 3.1.2 - core framework Spring DATA - For data access Thymeleaf for...

This bean is configured as shown below: <bean id="securityContextPersistenceFilter" class="org.springframework.security.web.context.SecurityContextPersistenceFilter"/> This bean has two main tasks and they are very important In a typical web application like Skyphoto the user will login once and then subsequently do several operations or click several links and buttons generating several authenticated requests to the server. Since the user was authenticated once it is important to store the security context somewhere and by some means. Otherwise he/she has to authenticate for each request and will sooner or later never use Skyphoto. In a typical web application you will store an user object in HttpSession and each time a request comes in, the server identifies this session with a session id and you get the user object. It is the responsibility of the server to cache/store and manage these session objects during the lifetime of the session. “In Spring Secur...

Going back to the filter chain configuration in my last post, you can see a chain filters configured as shown below: <bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy"> <sec:filter-chain-map path-type="ant"> <sec:filter-chain pattern="/SkyPhotoWeb/**" filters=" securityContextPersistenceFilterWithASCFalse, basicAuthenticationFilter, exceptionTranslationFilter, filterSecurityInterceptor" /> <sec:filter-chain pattern="/**" filters=" securityContextPersistenceFilterWithASCTrue, formLoginFilter, exceptionTranslationFilter, filterSecurityInterceptor" /> </sec:filter-chain-map> </bean> Let us assume that a request is send as http://www.skyphoto.com/SkyPhotoWeb/dosomething.html the request runs through the filters as shown in picture below: In my next post I will explain all these and few other important filters in greater detail.

DelegatingFilterProxy The DelegatingFilterProxy is a special filter provided by the Spring framework.It acts as a bridge connecting the web container and spring application container. In other words it helps pipeline request processing from the web container filter to a bean in Spring web application context. DelegatingFilterProxy is configured in the web.xml as shown below: <filter>     <filter-name>springSecurityFilterChain</filter-name>     <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>   </filter>   <filter-mapping>     <filter-name>springSecurityFilterChain</filter-name>     <url-pattern>/*</url-pattern>   </filter-mapping>       DelegatingFilterProxy is essentially a dumb filter and implements no logic. Its sole responsibility is to delegate the Filter's met...

So far we have been quick to setup Spring Security and apply it in our application. But behind that minimal configuration and non-invasive behavior lot has been happening behind the scenes. It is time to uncover the activities under hood, draw some diagrams to understand the framework and move ahead in style. I will not draw out all the balls from the magic box now. Instead will slowly take out one ball at a time to make it slow and easy to comprehend and assimilate. Let us go back to the web.xml configuration. You will see that we have configured a DelegatingFilterProxy . This filter is named 'springSecurityFilterChain'. The delegating filter proxy looks for a bean named 'springSecurityFilterChain' in the root Spring web application context. So note that this name is kind of a reserved bean name and should not be used elsewhere. The delegating filter proxy as the name suggests delegates the entire security processing then to the beans declared in the Spring web appl...