It's early in the morning at your job as a software developer for the Jim Bob Circle Pants Online Calendar (JBCPCalendar.com), and you're halfway through your first cup of coffee when you get the following email from your supervisor:

What? You didn't think about security when you designed the application? In fact, at this point, you are not even sure what a security audit is. Sounds like you'll have a lot to learn from the security auditors! Later in this chapter, we will review what an audit is, along with the results of an audit. First, let's spend a bit of time examining the application that's under review.

Although we'll be working through a contrived scenario as we progress through this book, the design of the application and the changes that we'll make to it are drawn from the real-world usage of Spring-based applications. The calendar application allows users to create and view events:

After entering the details for a new event, you will be presented with the 
following screenshot:

The application is designed to be simplistic, to allow us to focus on the important aspects of security and not get tied up in the details of object-relational mapping (ORM) and complex UI techniques. We expect you to refer to other supplementary materials in the Appendix, Additional Reference Material (in the Supplementary Materials section of this book) to cover some of the baseline functionality that is provided as part of the sample code.

The code is written in Spring and Spring Security 4.2, but it would be relatively easy to adapt many of the examples to other versions of Spring Security. Refer to the discussion about the detailed changes between Spring Security 3 and 4.2 in Chapter 16, Migration to Spring Security 4.2, for assistance in translating the examples to the Spring Security 4 syntax.

Please don't use this application as a baseline to build a real online calendar application. It has been purposely structured to be simple and to focus on the concepts and configuration that we illustrate in this book.

The web application follows a standard three-tier architecture consisting of a web, service, and data access layer, as indicated in the following diagram:

You can find additional material about MVC architectures in the Supplementary Materials section of the Appendix, Additional Reference Material.

The web layer encapsulates MVC code and functionality. In this sample application, we will use the Spring MVC framework, but we could just as easily use Spring Web Flow (SWF), Apache Struts, or even a Spring-friendly web stack, such as Apache Wicket.

In a typical web application, leveraging Spring Security, the web layer is where much of the configuration and augmentation of code takes place. For example, the EventsController class is used to transform an HTTP request into persisting an event into the database. If you haven't had a lot of experience with web applications and Spring MVC specifically, it would be wise to review the baseline code closely and make sure you understand it before we move on to more complex subjects. Again, we've tried to make the website as simple as possible, and the construct of a calendar application is used just to provide a sensible title and light structure to the site.

The service layer encapsulates the business logic for the application. In our sample application, we use DefaultCalendarService as a very light facade over the data access layer, to illustrate particular points about securing application service methods. The service layer is also used to operate on both Spring Security APIs and our Calendar APIs within a single method call. We will discuss this in greater detail in Chapter 3, Custom Authentication.

In a typical web application, this layer would incorporate business rule validation, composition and decomposition of business objects, and cross-cutting concerns such as auditing.

The data access layer encapsulates the code responsible for manipulating the contents of database tables. In many Spring applications, this is where you would see the use of ORM, such as Hibernate or JPA. It exposes an object-based API to the service layer. In our sample application, we use basic JDBC functionality to achieve persistence to the in-memory H2 database. For example, JdbcEventDao is used to save event objects to the database.

In a typical web application, a more comprehensive data access solution would be utilized. As ORM, and more generally data access, tends to be confusing for some developers, this is an area we have chosen to simplify as much as possible for the purposes of clarity.