Book Image

Spring Security 3.1

By : Robert Winch, Peter Mularien
Book Image

Spring Security 3.1

By: Robert Winch, Peter Mularien

Overview of this book

<p>Knowing that experienced hackers are itching to test your skills makes security one of the most difficult and high-pressure concerns of creating an application. The complexity of properly securing an application is compounded when you must also integrate this factor with existing code, new technologies, and other frameworks. Use this book to easily secure your Java application with the tried and trusted Spring Security framework, a powerful and highly customizable authentication and access-control framework.<br /><br />"Spring Security 3.1" is an incremental guide that will teach you how to protect your application from malicious users. You will learn how to cleanly integrate Spring Security into your application using the latest technologies and frameworks with the help of detailed examples.<br /><br />This book is centred around a security audit of an insecure application and then modifying the sample to resolve the issues found in the audit.<br /><br />The book starts by integrating a variety of authentication mechanisms. It then demonstrates how to properly restrict access to your application. It concludes with tips on integrating with some of the more popular web frameworks. An example of how Spring Security defends against session fixation, moves into concurrency control, and how you can utilize session management for administrative functions is also included.<br /><br />"Spring Security 3.1" will ensure that integrating with Spring Security is seamless from start to finish.</p>
Table of Contents (24 chapters)
Spring Security 3.1
Credits
About the Author
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface
Index

Authorization


Inappropriate or non-existent use of authorization.

Authorization is the second of two core security concepts that is crucial in implementing and understanding application security. Authorization uses the information that was validated during authentication to determine if access should be granted to a particular resource. Built around the authorization model for the application, authorization partitions the application functionality and data, such that availability of these items can be controlled by matching the combination of privileges, functionality, and data with users. Our application's failure at this point of the audit indicates that the application's functionality isn't restricted by the user role. Imagine if you were running an e-commerce site and the ability to view, cancel, or modify order and customer information was available to any user of the site!

Authorization typically involves two separate aspects that combine to describe the accessibility of the secured system.

The first is the mapping of an authenticated principal to one or more authorities (often called roles ). For example, a casual user of your website might be viewed as having visitor authority, while a site administrator might be assigned administrative authority.

The second is the assignment of authority checks to secured resources of the system. This is typically done at the time a system is developed, either through an explicit declaration in code or through configuration parameters. For example, the screen that allows viewing of other users' events should be made available only to those users having administrative authority.

Tip

A secured resource may be any aspect of the system that should be conditionally available based on the authority of the user.

Secured resources of a web-based application could be individual web pages, entire portions of the website, or portions of individual pages. Conversely, secured business resources might be method calls on classes or individual business objects.

You might imagine an authority check that would examine the principal, look up its user account, and determine if the principal is in fact an administrator. If this authority check determines that the principal who is attempting to access the secured area is, in fact, an administrator, then the request will succeed. If, however, the principal does not have sufficient authority, the request should be denied.

Let's take a closer look at the example of a particular secured resource, the All Events page. The All Events page requires administrative access (after all, we don't want regular users viewing other users' events), and, as such, looks for a certain level of authority in the principal accessing it.

If we think about how a decision might be made when a site administrator attempts to access the protected resource, we'd imagine that the examination of actual authority versus required authority might be expressed concisely in terms of the set theory. We might then choose to represent this decision as a Venn diagram for the administrative user:

There is an intersection between User Authorities (User and Administrator) and Required Authorities (Administrator) for the page, so the user is provided with access.

Contrast this with an unauthorized user:

The sets of authorities are disjoint, and have no common elements. So, the user is denied access to the page. Thus, we have demonstrated the basic principle of authorization of access to resources.

In reality, there's real code making this decision with the consequence of the user being granted or denied access to the requested protected resource. We'll address the basic authorization problem with Spring Security's authorization infrastructure in Chapter 2, Getting Started with Spring Security followed by more advanced authorization in Chapter 10, Fine-grained Access Control and Chapter 11, Access Control Lists.