Pattern Name: Web Application Security Filter
Classification: Structural Filter
Intent:
Isolates authentication and authorisation from the application by filtering requests before they are received by the application so that authentication and authorisation may be easily applied to existing applications and managed seperately from other aplication concerns.
Motivation:
Incorporating authentication and authorisation security protocols into an Internet application is generally complex and when done improperly can lead to significant exposure to abuse and maluse. Due to the complex nature of implementing these security features significant risk is encountered when security code is combined with application code. This pattern is based on the generic filter and observer patterns allowing the seperation of security concerns from the development and management of the application and hopefully providing a better quality of service.
Filters provide an excellent opportunity for seperating security concerns from your web application. Because they intercept the incoming requests to your site before the site even sees them you can even apply the same filter pattern to existing sites without too much alteration. Combined with the power of directory services the pattern can be applied to both authentication and authorisation.
A filter is a special type of the decorator pattern because it allows the data being transmitted not only to be decorated but altered or even replaced altogether. Security functions naturall lend themselves to filter type implementations, perhaps the most well known type of filter implented today is the NetFilter or firewall. Network filters while suitable for addressing network traffic issues are not really suitable for application security, which after the network and operating system produce the most opportunities for security breaches.
Also Known As:
No alternate designs or implementations meeting the pattern are currently known
Applicability:
Any hosted application has the potential to bennefit from deployment of an implementation of this pattern. Also due to the generic nature of this pattern it would suit almost any web aplication container where the container supports filtered access to its hosted applications.
In addition to the basic objectives this security filter pattern can be used to address any olf the following requirements:
- When security is required to be handled external to the application.
- Where it is advantageous to have the same security implementation across multiple applications.
- If security factors need to be isolated to demonstrate security processes for audit.
Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams can be used for this purpose.
Participants: A listing of the classes and objects used in this pattern and their roles in the design.
Collaboration: Describes how classes and objects used in the pattern interact with each other.
Consequences: This section describes the results, side effects, and trade offs caused by using this pattern.
Implementation: This section describes the implementation of the pattern, and represents the solution part of the pattern. It provides the techniques used in implementing this pattern, and suggests ways for this implementation.
Sample Code:
This section has a deliberately brief snip of a filter and its associated filter classes. This is an example of simplified function to higlight the general idea and not how it would be implemented for real. In reality the application container that you are using will already have something to base this on like javax.servlet.Filter so try and use that or something similar.
/*
* Filter.java
*
* @author Michael Chester
* @date 2007-03-09
*
* Filter interface used to chain filters, and eventually an
* application adapter.
*
* Filter class used to illustrate a simple interpretation on the
* securilty filter pattern, a factory should initialise the
* private attributes.
*/
public interface FilterInterface {
public void doProcess(Session session, Request request,
Response response);
}
public class EntryGate implements FilterInterface {
/**
* doProcess the filter action
*
* @param session for the current request
* @param request the request that was sent through
* @param response to fill out if authorisation fails
*
* @returns nothing
*/
public void doProcess(Session session, Request request,
Response response) {
response.setResponse("performing filter");
if(authorisor.isAuthorised(session, request, response))
if(validator.isValidated(session, request, response))
filter.doProcess(session, request, response);
}
/**
* Holds value of property validator.
*/
private Validator validator;
/**
* Holds value of property authority.
*/
private Authorisor authorisor;
/**
* Holds value of property filter.
*/
private FilterInterface filter;
}
/*
* Authorisor.java
*
* @author Michael Chester
* @date 2007-03-09
*
* Authorisor interface and class used to illustrate the role and
* function of the authorisation concrete class.
*/
public interface Authorisor {
public boolean isAuthorised(Session session, Request request,
Response response);
}
public class AuthorisorExample implements Authorisor {
/**
* isAuthorised verifies the identity of the requestor
*
* @param session for the current request
* @param request the request that was sent through
* @param response to fill out if authorisation fails
*
* @returns true if authorised, false otherwise
*/
public boolean isAuthorised(Session session, Request request,
Response response) {
/* authenticate on token */
if(session.getAuthenticationToken() != null)
if(session.getAuthenticationToken().equals("validToken"))
return true;
/* or authenticate on identity */
if(request.getIdentity() != null)
if(request.getIdentity().equals("validUser")) {
/* and set a token to validate on next request */
session.setAuthenticationToken("validToken");
return true;
}
/* otherwise the identity is not authorised */
response.setResponse("user not authorised");
return false;
}
}
/*
* Validator.java
*
* @author Michael Chester
* @date 2007-03-09
*
* Validator interface and class used to illustrate the role and
* function of the validation concrete class.
*/
public interface Validator {
public boolean isValidated(Session session, Request request,
Response response);
}
public class ValidatorExample implements Validator {
/**
* example of a request validator, put your code here
*
* @param session for the current request
* @param request the request that was sent through
* @param response to fill out if authorisation fails
*
* @returns true if authorised, false otherwise
*/
public boolean isValidated(Session session, Request request,
Response response) {
/* return true if the task matches */
if(request.getTask() != null)
if(request.getTask().equals("validTask")) return true;
/* false otherwise */
response.setResponse("request is not valid for user");
return false;
}
}
Known Uses:
Due to the nature of security applications and the way that this pattern is applied no implemented uses are mentioned here. However a number of applications are currently using this pattern hosted on the Apache Tomcat Servlet Container engine using implementations based on extending Tomcat’s own filter implementation.
Related Patterns:
This pattern is essentially an extension to or application of the already existing generic filter patterns.