Spring Security 2 Explained. Part 1. The filters.

The following article will try to explain Spring security with detail.

The vast majority of Spring Security articles and books, explain the framework making emphasis in the easy of configuration and use. Which is great for almost everything. However to really understand what is going on, i need to go a little deeper and study the elements tha actually participate on the framework.

I will make a very simple application and try to explain what happens in Spring Security through the different paths of executions i do.

The first thing to do is to add the security filter and context configuration to your web.xml file.

This is my web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<display-name>articleSpringSecurity</display-name>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/security.xml
</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<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>
</web-app>

Here, the Delegating Filter Proxy is the entry point into Spring Security. It's actually not a Spring Security Filter, but a Spring Web Filter, is just that in this case we are using it to delegate to the security filters we will define in the Spring Application Context “security.xml”

Defining the simplest Spring Security Configuration File:

security.xml

<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">
<http auto-config='true'>
<intercept-url pattern="/**" access="ROLE_USER" />
</http>

<authentication-provider>
<user-service>
<user name="carlo" password="carlo" authorities="ROLE_USER" />
</user-service>
</authentication-provider>

</beans:beans>

This file will include Spring security in our Application.

Let's explain what is on this file, by accessing our application. Pointing to the base path of our web application automatically shows us a login form. How does this happen?.


The XML element http with auto-config= “true” defines the following:

First of all Spring will automatically register the following servlet filters:

HttpSessionContextIntegrationFilter
LogoutFilter
AuthenticationProcessingFilter
DefaultLoginPageGeneratingFilter
BasicProcessingFilter
SecurityContextHolderAwareRequestFilter
RememberMeProcessingFilter
AnonymousProcessingFilter
ExceptionTranslationFilter
SessionFixationProtectionFilter
FilterSecurityInterceptor


These filters execute from top to bottom and carry the following resposibilities:


HttpSessionContextIntegrationFilter job is to create a default SecurityContext. It tries to read the context from the Session, and if there isn't any, it creates a new Instance of SecurityContextImpl and put it in the ThreadLocal SecurityContextHolder. The it passes Control to the next filter in the Chain.
After returning from the chain, this filter consults the SecurityContextHolder for the SecurityContext in it to see if it has changed during request processing.
I SecurityContext has changed and authentication is not anonymous, then the new SecurityContext is stored in session.


LogoutFilter. This filter consults the URL invoked to see if it is a URL that requires logout. The default Logout Requring URL is j_spring_security_logout. So if you invoke this URL in your application you are explicitly asking to logout from the application. If the URL is for logut, the This filter delegates in handlers the actual logout process. By default it delegates to SecurityContextLogoutHandler and TokenBasedRememberMeServices. The first Handler invalidates the Session, and the second handler, deletes the remember me cookie (set age to 0)


AuthenticationProcessingFilter. This is one of the most important filters. Its job is the following. First it it checks if the Invocation URL is for a login petition, it does this by consulting if the URL matches the default /j_spring_security_check URL.
If the previous step requirement is met, then this filter looks in the request parameters for a Username and a password (in the request parameters j_username and j_password respectively). Then it creates an UsernamePasswordAuthenticationToken which is an Implementation of an Authentication Class, so it set the authentication Principal to the username and the Authentication credentials to the passoword provided.
Then it puts the username in the session under the name SPRING_SECURITY_LAST_USERNAME. The next important Step is to call the AuthenticationManager's authenticate method with our newly created Authentication Object.
From the preceding paragraph we can see that the first time we access the application home, the filter will stop it's processing in the point where it checks if the invocation URL is an authentication petition. The home page is not the URL for authentication (which we now know is j_spring_security_check) so this filter won't do anything (right now) but to continue to the next filter.

DefaultLoginPageGeneratingFilter. This Filter is almost explained by its name. It's function is to generate a default login page when required. With "when required" I mean when the URL invoked corresponds to the default URL for login page which is /spring_security_login. When this filter detects that this URL is being invoked it renders a default login page. When we first invoke the application home we are not invoking this URL. So why does it show the login Page. We'll see why soon enough.


BasicProcessingFilter. This filter's job is to check if the request has standard http authentication headers. If it does, it creates a new Authentication (UsernamePasswordAuthenticationToken) object from it, and like the AuthenticationProcessingFilter, it delegates to the AuthenticationManager's authenticate method the authentication job. If authentication fails, the filters sets the SecurityContext to null.

SecurityContextHolderAwareRequestFilter. This filter wraps the Servlet request in a SavedRequestAwareWrapper. This wrapper somehow maintains a saved request, but I don't know what this wrapper exactly brings to the table.


RememberMeProcessingFilter. This filter's job is to query the security context to see if there is an Authentication Object on it, if not, it will create (or try to) a new one, by calling the autoLogin method of AbstractRememberMeServices which will retrieve a Remember Me cookie and try to authenticate using it.
The cookie's default name is SPRING_SECURITY_REMEMBER_ME_COOKIE. If the filter finds this cookie, it decodes it, make some validations and call the userDetailsService with the cookie information. If the userDetails returned is valid, The RememberMeServices creates a new RememberMeAuthenticationToken that return to the filter and the filter saves it into the SecurityContext.

AnonymousProcessingFilter. This simple filter, detects if there already is an authentication object in the security context. if there is not any, it creates a new one (AnonymousAuthenticationToken) with the username "guest" and the rol "ROLE_ANONYMOUS" (this names can be overriden).


ExceptionTranslationFilter. This filter is in charge of Capturing and initiating the handling of any security exceptions that may come from the application (AccessDeniedException,AuthenticationException). The filter serves as a translator between the Java Exceptions and the Http Errors. If the filter detects an authentication Exception (Basically No Authentication Object) it initiates the authentication mechanism by invoking the authentication entry point to show the login page. If the exception is a AccessDeniedException, the filter first checks if the authenticated user is Anonymous. If it is, it follows the same path as if there wasn't any authentication at all. If it isn't anonymous, it basically means that a USer with some privileges is trying to access resources that he can't. So an access denied exception is returned to the browser

SessionFixationProtectionFilter. This filter checks if there is a user authenticated but there is not a Session attribute associated with the securityContext. This can happen if the user is not authenticated from the start of the request but is authenticated during the duration of the request thread. If this is the case, the filter creates a new session with the information required.

FilterSecurityInterceptor. This is the Filter version of the AbstractSecurityInterceptor. it delegates to it's super class (the mentioned AbstractSecurityInterceptor) the authorization to access the required resource. If it can not access the resource the AbstractSecurityInterceptor will throw an accessDeniedException. We'll cover the AbstractSecurityInterceptor in detail in the next par of this Article.

Running Java App in Debugging Mode

Without an IDE, to Run An Application In Debug Mode you do the following

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=11550,suspend=n "your-program"

The Application "your-program" Starts and listens for connections on the 11550 port for debugging.

Implementing Strategies with Enums.

Implementing Strategies with Enums.

As most Design Patterns, Strategy pattern is an incredibly useful pattern to express polimorphic behaviour.
I don't pretend to explain Strategy pattern on this post. My intention is only to show you a nice way of implementing the pattern using a Java Enum.

Sometimes the difference between strategies is small, and you have control over all the strategies. (There is no intention that a client implements its own strategy).
Also, usually each strategy comes in the form of a Singleton instance.
It would be nice to have all Strategies in a common place, sharing a common namespace.

All the previous can be addressed with the use of the Enum construct in Java 1.5+

Let's suppose a Voice "strategizable" class, with two concrete strategies Screaming Voice and Whisper Voice

This is how we would do this with an Enum.

public enum Voice {
SCREAM(){
@Override
public String say(String say){ return say.toUpperCase()+" !!";}
},
WHISPER(){
@Override
public String say(String say){return say.toLowerCase()+ " please ";}
};
public abstract String say(String say);
}

There we have our two Strategy implementations under the same namespace (the ENUM type), singleton guaranteed. To test the startegy we have the following test case.


package misc;

import org.junit.Test;
import static org.junit.Assert.*;

public class VoiceTest {
@Test
public void testVoice() {
// if in good mood
VoiceUser user = new VoiceUser(Voice.WHISPER);

// if in bad mood
VoiceUser user2 = new VoiceUser(Voice.SCREAM);

assertEquals("do that please", user.askSomeone());
assertEquals("DO THAT !!", user2.askSomeone());
}
}

class VoiceUser {
public VoiceUser(Voice voice) {
this.voice = voice;
}

Voice voice;

String askSomeone() {
String string = "Do that";
return voice.say(string);
}
}

From which Jar is a class Loaded

I post this for future reference.

public class Main {

public static void main(String[] args) {
System.out.println(findJar(System.class));
}

public static String findJar(Class clase) {
String name = clase.getName();
name = name.substring(name.lastIndexOf('.') + 1) + ".class";
String jar = clase.getResource(name).toString();
return jar;
}

}

Fast Flex Cairngorm Explanation

Flex Cairngorm fast explanation

As an experienced Spring and Spring MVC developer, i started my new Flex-Java based personal project with the idea of using a flex framework that encourages the same kind of patterns that i'm used to.
I took on the Cairngorm framework from de Adobe people.

I'll try to establish correspondences between Cairngorm elements and Spring MVC elements.

The elements:

The elements that form part of a Flex Cairngorm Architectura are the following:

View: The view is normally an mxml file. The view shows the data to the user and receives his interactions. The view allows to initiate updates of the model. When an update is to happen, it generates an appropiate event informing of this. The view holds a binded reference to the model that is automatically updated on change. This Object corresponds to the JSPs (Or any other view technology) in Spring MVC.

Model Domain Objects: Are the objects that form part of the Model of the application, are the objects on which the application logic is applied.

Events: Is the flex preferred way of communicating that an action must be taken due to something happening. In cairngorm, the Event object usually carry a Model Object reference on it. This object corresponds, more or less, to the HttpRequest that is sended to the Servlet Container on the Submit event.

Front Controller. As in the major of MVC frameworks, the front controller is the central piece that ties together and routes flow between the view and the business logic. If you are familiar with Spring MVC, this Object corresponds to the DispatcherServlet of Spring.

ModelLocator: In Flex, a Model locator is a Registry that contains references to the different model objects.

Command Objects: Following the GoF Command design pattern, Cairngorm Command Objects are objects that implements an execute method, and are selectively invoked by the front Controller to carry on certain business logic. In normal cairngorm applications, the command object basicaly only extracts the model object from the Event object and passes it to a Business Delegate Object. If you are experienced with Spring MVC this Command Object corresponds to the Controller in the Spring MVC Framework.

Business Delegate: This object's job is to hold a reference to the (usually remote) Service that is going to be called. (Usually this reference is obtained from a ServiceLocator). The business delegate Calls the remote object, and on response, invoke's the Command Object's result method, which is in charge of updating the model in the Model Locator.

Groovy Dynamic Typing

Groovy Dynamic Beahaviour.

As oposed to Java, Groovy is dynamically typed. Which basically means that the type is not checked at compile time, but instead only at runtime.
Besides some drawbacks, this allows to do many cool things including Duck Typing.
The principle of duck typing is that "if it quacks like a duck it's a duck". this basically means that the behaviour of the Object is based on the use it has on the application, not on its specific type.
In essence this allows to call an object's methods without knowing (at compile time) that these methods exist. In Runtime the methods are invoked. Note that this works even with two different unrelated (No hierarchy or interfaces shared) objects, that implements the method, and precisely this is the beauty of it.

For example

[CODE]
def metodo(anything){
anything.call(144)
}

metodo{
println it
}

def clos2= {println it+it}
metodo(clos2)

class X{
public def call(value){
println value*3
}
}

metodo(new X())
[/CODE]

As you can see, the method "metodo" is called three times with different types.
The first two times is called with a Closure, one inline closure and other declared closure.
And the third time with a totally different object X. That happens to implement the methdo in its own way.

Understanding workflow languages

Using JBPM as a starting point and taking a look at its documentation, I’ve realized that it’s not really that hard to build a very simple Workflow Model. It basically consists of the following classes.

Node: Each Step in the workflow flow is defined by a node. A node is a Command object (Command Design Pattern) and has references to the incoming transitions and to the outgoing transitions.

Transition: A directional link that links two nodes together.

Execution: An execution is the context that the workflow is currently working on. An execution has a reference to the node it is at the moment. Transitions pass this context from node to node.

So the workflow basically works this way.

An Execution object is instantiated with a reference to the first node. From that point on, the execution of the flow is controlled by events passed to the Execution Object.
In general, Nodes are responsible for sending events to the Execution Object, determining what the execution of the process will do next.

So this is a very simple example of a workflow Model implementation. In Pseudo.

Class XNode implements Node{
Public execute(Execution exe){
doSomething…..
exe.event(“transicionA”)
}
}
Class Execution{
Node currentNode;
Public event(Event e){
currentNode.getTransitionForEvent(e).take(this)
}
}
Class Transition{
Node origin;
Node destination;
Public take(Execution e){
destination.execute(e)
}
}