Security with AOP
Security is one of the most important elements of an application. The word
"security" covers two concepts:
-
Authentication is the verifi cation's process of a principal's identity; a
principal is typically a user. A principal in order to be authenticated
provides a credential that is the password.
-
Authorization, on the other hand, is the process of granting authorities, which
are usually roles, to an authenticated user.
Once a user is authenticated and has roles, he or she can work on the
application and perform the actions permitted by an access control list, which
according to the user's roles allows certain operations.
Before Spring Security, the rules of who can do what were usually implemented
using custom code and an in-house framework, or using JAAS. Usually, the fi rst
type of implementation was a consequence of the second type's diffi culty.
Unfortunately, though custom-type security fi ts its purposes, it lacks in its
main aim. This is because it's safer to employ a much-used framework that is
constantly updated and corrects security problems, rather than having an
in-house framework that might be barely tested. Beside these considerations,
which should be carefully take into account, defi ning and applying security
rules without AOP means causing code tangling and code scattering.
I n fact, AOP applied to security solves most of the common practical problems
concerning security. In order to solve them we use Spring Security 2.0.x
(formerly Acegi Security System for Spring), confi guring it properly to carry
out most of the work according to the application's needs. We will see its
confi guration in Chapter 7. Now let's look just at some parts where AOP
intervenes in its confi guration.
For now, we will not deal with the authentications and roles attribution.
Instead, we will start from the point at which the decision is taken to
authorize a user and to provide him or her with roles to access a certain
resource. Taking an actual decision whether or not to allow the user (based on
its roles) gain access to the secure resource is the responsibility of the
access decision manager.
An access decision manager implements the AccessDecisionManager interface, and
in order to carry out his or her job, the manager needs a group of voters which
implement the AccessDecisionVoter interface.
The AccessDecisionManagers provided by Spring are:
-
A ffirmativeBased: At least one voter votes to grant access
-
ConsensusBased: A consensus of voters votes to grant access
-
UnanimousBased: All voters vote to abstain or grant access
If none of them is specifi ed, we employ AffirmativeBased with two voters,
RoleVoter and AuthenticatedVoter. A voter can vote to grant, deny, or abstain.
-
R oleVoter: This bases its vote on role. If the user has the required role by
the required resource, it votes ACCESS_GRANTED. But if the resource doesn't
have a specifi ed role, it votes ACCESS_ABSTAIN. If the resource has a role the
user doesn't have, then it votes ACCESS_DENIED.
-
AuthenticatedVoter: This votes on the strength of the user's authentication. A
user can be authenticated with:
-IS_AUTHENTICATED_FULLY
-IS_AUTHENTICATED_REMEMBERED
-IS_AUTHENTICATED_ANONYMOUSLY
-AuthenticatedVoter votes ACCESS_GRANTED if the authentication level is higher
than the level requested by the resource. The highest one is
IS_AUTHENTICATED_FULLY.
In the following XML, we see the declaration of the access decision manager:
<beans xmlns=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/security
http://www.springframework.org/schema/security/spring-security- 2.0.4.xsd
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
…
<bean id="accessDecisionManager" class="org.springframework.
security.vote.AffirmativeBased">
<property name="decisionVoters">
<list>
<bean class="org.springframework.security.vote.RoleVoter" />
<bean class="org.springframework.security.vote.AuthenticatedVoter" />
</list>
</property>
</bean>
</beans>
Once we have defi ned the AccessDecisionManager, we can use AOP to decide the
roles that are necessary to call the several beans' methods.
We can employ three strategies:
1. Securing methods with security interceptors.
2. Securing methods with pointcuts.
3. Securing methods with annotations.
Securing methods with security interceptors
With security interceptors we can defi ne the roles necessary to execute methods
on the bean.
Let's have the interface:
public interface FooService {
public Integer getBalance(Integer idAccount);
public void setBalanceAccount(Integer id,
Integer balance);
public boolean suspendAccount(Integer id);
}
FooService is implemented by FooServiceImpl, that is confi gured as follows :
<beans xmlns=http://www.springframework.org/schema/beans
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:security=http://www.springframework.org/schema/security
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security- 2.0.4.xsd">
…
<bean id="accessDecisionManager" class="org.springframework.
security.vote.AffirmativeBased">
<property name="decisionVoters">
<list>
<bean
class="org.springframework.security.vote.RoleVoter"/>
<bean
class="org.springframework.security.vote.AuthenticatedVoter"/>
</list>
</property>
</bean>
…
<bean class="org.springaop.chapter.five.security.FooServiceImpl">
<security:intercept-methods
access-decision-manager-ref="accessDecisionManager">
<security:protect method="org.springaop.chapter.five.
security.FooService.getBalance"access="ROLE_USER" />
<security:protect method="org.springaop.chapter.five.security.FooService.
setBalanceAccount" access="ROLE_ACCOUNTING,ROLE_ADMIN" />
<security:protect method="org.springaop.chapter.five.
security.FooService.suspendAccount" access="ROLE_ADMIN" />
</security:intercept-methods>
</bean>
…
</beans>
We have defi ned some roles (separated by a comma) that can execute those method
we want to be executed by a user that has a particular role. This choice
permits us to defi ne roles on methods directly on beans, but makes the confi
guration fi les too long.
Securing methods with pointcuts
With this strategy, it's possible to defi ne the roles required for the
different pointcuts with AspectJ syntax that we defi ne with the tag
global-method-security.
We use the same rules on the same methods of the interface FooService.
<global-method-security
access-decision-manager-ref="accessDecisionManager">
<protect-pointcut expression="execution(*
org.springaop.chapter.five.security. FooService.getBalance(..))"
access="ROLE_USER" />
<protect-pointcut expression="execution(*
org.springaop.chapter.five.security. FooService.set*(..))"
access="ROLE_ACCOUNTING,ROLE_ADMIN" />
<protect-pointcut expression="execution(*
org.springaop.chapter.five.security. FooService.suspendAccount(..))"
access="ROLE_ADMIN" />
</global-method-security>
When using pointcuts, we don't have to use interceptors if they can be in confl
ict with the execution of methods that we have defi ned in the confi guration.
This modality of confi guration is consistent with AspectJ syntax for the defi
nition of pointcuts, making the modality of confi guration of aspects
homogeneous.
Compared to interceptors, the confi guration is less prolix and dispersive as it
concentrates the methods that can be invoked with the different roles at one
point.
Securing methods with annotations
W e can use annotations to defi ne which roles can be executed by the methods of
our classes. We will use the same rules on the same methods of the interface
FooService.
package org.springaop.chapter.five.security;
import org.springframework.security.annotation.Secured;
public class FooServiceImplWithAnnotations implements FooService{
@Secured("ROLE_USER")
public Integer getBalance(Integer idAccount) {
Integer result =
0;
// do something
return result;
}
@Secured( { "ROLE_ACCOUNTING", "ROLE_ADMIN" })
public void setBalanceAccount(Integer id,
Integer balance) {
// do something
}
@Secured("ROLE_ADMIN")
public boolean suspendAccount(Integer id) {
boolean result = false;
// do something
return result;
}
}
W ith this strategy, we defi ne the roles within the class, needed for the
execution of methods. With this choice we don't have to confi gure any XML, but
we lose the possibility of seeing the roles for the methods present defi ned in
a single place.
Summary
In this chapter we've seen how to implement crosscutting functionalities, such
as concurrency control, the employment of a cache, and security management.
Without AOP those functionalities would be scattered across the application,
with the same code duplicated in different modules. With AOP we can have
cleaner code, much more concise and easier to maintain and debug. We've seen
how it is possible to implement these functionalities without having tangled or
scattered code, implementing functionalities with aspects and advices.
Also read
Explain the concepts and capabilities of Aspect-Oriented Programming, AOP.
What is Aspect in AOP?
AOP approach addresses Crosscutting concerns. Explain
The components of AOP are advices/interceptors, introductions, metadata, and
pointcuts. Explain them
AOP vs OOPs...........
What is the relation between Classes and Objects? Explain different properties
of Object Oriented Systems. What is difference between Association, Aggregation
and Inheritance relationships? Explain the features of an abstract class in
NET. Difference between abstract classes and interfaces Similarities and
difference between Class and structure in .NET Features of Static/Shared
classes. What is Operator Overloading in .NET?.............
What
is object oriented programming (OOP)?
The object oriented programming is commonly known as OOP. Most of the languages
are developed using OOP concept. Object-oriented programming (OOP) is a
programming concept that uses "objects" to develop a system.........
What
are the various elements of OOP?
Various elements of OOP are.........
Explain
an object, class and Method.
An object is an entity that keeps together state and behaviors.
For instance, a car encapsulates state such as red color, 900 cc etc and
behaviors as 'Start', 'Stop' etc., so does an object...............
|
