Formerly Acegi Security System for Spring, Spring Security
is a powerful, flexible, and widely used framework for authentication and
authorization in your Java applications. If you are just starting with Spring
Security then the Spring Source1 getting started documentation and
tutorials are a great way to get your feet wet.
Once you understand the basics of how to implement a basic
security framework and the wealth of options at your fingertips, the questions
usually arise: “Which parts of this framework do I need to use?”, “What are
they for?”, and “When do I need to use them?”.
For many applications there are 3 layers of authorization
that we typically need to be concerned about when implementing Spring Security.
- HTTP Request Authorization – verifying that a
user is authenticated (if necessary) and authorized to access a specific URL.
- Service Layer Authorization – verifying that a
user is authorized to access a specific method, class, or service.
- Component Authorization – verifying that a user
is authorized to see or use a specific component, operation, logic, or data.
These are the core components of the Spring Security
framework and together are sufficient to provide reasonably complete
authorization control for your application. Each layer serves a specific
purpose and works best for that purpose. Attempting to shoe-horn all your
authorization components into a single layer, using them to do more than they
are intended to do will cause needless complication.2,3
HTTP Request
Authorization
The basic tutorial example for security-app-context.xml4,5
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/security"
xsi:schemalocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.1.xsd">
<http use-expressions="true">
<intercept-url access="permitAll" pattern="/index.jsp">
<intercept-url access="hasRole('supervisor')" pattern="/secure/extreme/**">
<intercept-url access="isAuthenticated()" pattern="/secure/**">
<intercept-url access="isAuthenticated()" pattern="/listAccounts.html">
<intercept-url access="isAuthenticated()" pattern="/post.html">
<intercept-url access="denyAll" pattern="/**">
<form-login>
<logout>
</logout></form-login></intercept-url>
</intercept-url></intercept-url></intercept-url>
</intercept-url></intercept-url>
</http>
<authentication-manager>
<authentication-provider>
<user-service>
<user authorities="supervisor, teller, user" name="rod" password="koala">
<user authorities="teller, user" name="dianne" password="emu">
<user authorities="user" name="scott" password="wombat">
<user authorities="user" name="peter" password="opal">
</user></user></user></user></user-service>
</authentication-provider>
</authentication-manager>
</beans:beans>
The basic example provides a simple template for setting up
user accounts, roles, and permissions based on URL patterns in your
application. Although most real-world implementations will replace the
authentication-provider due to the limitations of the example, the
intercept-url example is reasonable to use with almost any framework that
provides different views based on the provided URL.
Purpose
The primary focus of the HTTP Request Authorization layer is
to provide catch-all security for your application to prevent unauthorized
users from directly linking to, and accessing functions that they are not
allowed to access. This removes the necessity of adding custom authentication
code to every page of your application (depending on your framework and architecture)
and gives you a universal way to limit the severity of access/authentication
defects by forgetting to include or making mistakes with your authentication
code.
Limitations
The usefulness of this layer drops dramatically as
application complexity increases and each distinct URL provides a wealth of
functions to the user. Monolithic application frameworks that are built
entirely around a single URL may only find the basic authentication service
useful, whereas applications designed to segment functionality into different
URLs by role will get the most value out of it.
Service Layer
Authentication
The basic tutorial example for security annotations in
classes and methods:3
public interface BankService {
public Account readAccount(Long id);
public Account[] findAccounts();
@PreAuthorize(
"hasRole('supervisor') or " +
"hasRole('teller') and (#account.balance + #amount >= -#account.overdraft)" )
public Account post(Account account, double amount);
}
The basic example demonstrates annotating a method with a
preauthorize Spring EL expression. This provides a powerful framework to
provide complex security rules around both methods and classes and ensure your
service operations are secure.
Purpose
The primary purpose of Service Layer Authentication using
annotations or interceptors is to safeguard access to services or operations
that should only be accessed by certain roles. This allows you to ensure that
only administrators can access administrative functions, read-only users cannot
access write operations, and to mitigate the chance that coding mistakes may
provide accidental access to services and operations that a role should not
have access to. It is best used as a safeguard to prevent unintentional access
to sensitive services.
Limitations
Due to the nature of the class and method annotations,
Service Layer Authentication does not provide a useful interface into the
visibility of the services it protects. It provides reactive security to negate
attempts to access a service, it does nothing to provide proactive information
about which roles can access the service. Common questions about Service Layer
Authentication often ask about how to catch the security exceptions that occur
or use the annotations to make control-flow decisions6,7. The answer
to those questions is complicated, but more importantly it should be
irrelevant. This layer is not intended to provide information to make those
decisions, and if the application is built well it should never be visible to
the user. It is best used only as a safeguard to avoid the consequences of
mistakes made in the HTTP Request Authentication, and the Component
Authorization layers.
Component
Authorization
An example of JSP Taglib security:8
<security:authorize ifAnyGranted="ROLE_ADMIN">
<tr>
<td colspan="2">
<input type="submit" value="<spring:message code="label.add"/>"/>
</td>
</tr>
</security:authorize>
An example of inline security:9
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
if (auth != null) {
if (auth.getPrincipal() instanceof UserDetails) {
report.setUser(new User(((UserDetails) auth.getPrincipal()).getUsername()));
} else {
report.setUser(new User(auth.getPrincipal().toString()));
}
}
These examples demonstrate two quick methods of using
Component Authorization, through the use of the Spring Security JSP Taglib and
using the Spring Security java API.
Purpose
This layer provides component-level security and allows you
to make control flow decisions based on role. It is the connecting layer
between the page-based HTTP Request Authorization layer and the method and
class level of the Service Layer Authentication that is vital for any
application that provides heavyweight or multi-function URLs. This is the
developer’s security layer that allows you to turn on and off components or
make decisions at any point in your code to provide access to specific
functions, links, or workflows.
Limitations
Using Component Authorization is repetitive and requires an
intimate understanding of which roles have access to which operations and when.
It is not optimal to use to provide page based security and basic
authentication, because that is better handled with the HTTP Request
Authorization layer which is easier, universal, and more reliable. It is not
optimal to provide class a method layer security, because that is better
handled with the Service Layer Authentication which can annotate interfaces,
abstract classes, and interceptors and does not require as much repetition or
context-related knowledge to be applied effectively.
Final Thoughts
Spring Security is a useful and powerful tool, but it is
best used when each type of security layer it provides is used effectively and
for the purpose that it was designed. A carefully considered multi-prong
approach to securing your application will provide a simpler, more elegant, and
more secure solution.
References
