AOP design solutions

          

Security with AOP

 

Spring 2.5 Aspect Oriented Programming, AOP

Chapter 5
Design with AOP

This chapter excerpt from Spring 2.5 Aspect Oriented Programming by Massimiliano Dessì, is printed with permission from Packt Publishing, Copyright 2007.

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

Aspect-Oriented Programming

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...........

OOPS in .NET

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...............



Write your comment - Share Knowledge and Experience


 

 
Latest placement tests
Latest links
 
Latest MCQs
» General awareness - Banking » ASP.NET » PL/SQL » Mechanical Engineering
» IAS Prelims GS » Java » Programming Language » Electrical Engineering
» English » C++ » Software Engineering » Electronic Engineering
» Quantitative Aptitude » Oracle » English » Finance
Home | About us | Sitemap | Contact us | We are hiring