Spring Security namespace provides an <ldap-server> element that configures the location of an external LDAP server against which authentication is to be performed. It can also be used to create an embedded Apache Directory Server instance. If the url attribute of the <ldap-server> element is specified, then it means that an external LDAP server is being used for authentication. And, if the url attribute is not specified, then an embedded instance of Apache Directory Server is created.

The applicationContext-security.xml file of the flightapp-web project configures embedded Apache Directory Server instances, as shown here:

<ldap-server ldif="classpath:application_users.ldif" 
      root="dc=sample,dc=com" />

The ldif attribute specifies the location of the LDIF (LDAP Data Interchange Format) file, which contains user information loaded by the embedded LDAP server. You'll find the application_users.ldif file in the WEB-INF/classes directory of the flightapp-web project. The root attribute specifies the root of the LDAP directory tree.

The following figure shows the LDAP directory tree defined by the application_users.ldif file:

The given figure shows that user groups administrator and appuser are defined under ou=groups, and application users admin and ashish are defined under ou=users. The DN (Distinguished Name) of user ashish is uid=ashish,ou=users,dc=sample,dc=com, and DN of user admin is uid=admin,ou=users,dc=sample,dc=com. DN of administrator group entry is cn=administrator,ou=groups,dc=sample,dc=com, and DN of appuser group entry is cn=appuser,ou=groups,dc=sample,dc=com.

The uniqueMember attribute(s) of an entry defined under ou=groups identifies the application user who belongs to that group. For instance, in the cn=administrator entry, the uniqueMember attribute value is uid=admin,ou=users,dc=sample,dc=com (DN of user admin), which means that the admin user belongs to administrator group. Similarly, ashish belongs to appuser group.

The businessCategory attribute of an entry under ou=groups identifies the role of the users belonging to that group. As the given figure shows, the role of user admin is admin_user and the role of user ashish is app_user.

As Flight Booking application makes use of the embedded Apache Directory Server, the following JAR dependencies have been added to the pom.xml file of the flightapp-web project:

As we are using Spring Security's LDAP support, spring-security-ldap JAR dependency is also added to the pom.xml file.

Let's now look at configuration, which instructs Spring Security to authenticate against the embedded LDAP server.

To authenticate against the embedded LDAP server, the following configuration has been added to the applicationContext-security.xml file:

<authentication-manager>
  <authentication-provider>
    <ldap-user-service group-search-filter="uniqueMember={0}"
       group-search-base="ou=groups" 
       user-search-base="ou=users" 
       user-search-filter="uid={0}" 
       group-role-attribute="businessCategory" />
  </authentication-provider>
</authentication-manager>

The <ldap-user-service> configures LdapUserDetailsService (an implementation of UserDetailsService that we discussed earlier), which loads user details containing username, password, and roles from the LDAP server. Authentication is performed by comparing the user entered password with the user details loaded by the LdapUserDetailsService instance.

The <ldap-user-service> element accepts the following attributes:

It is important to note at this point that Spring Security's LDAP authentication mechanism by default prepends ROLE_ to the name of the role returned after authentication. So, if the admin user authenticates with the Flight Booking application, then instead of admin_user role, it gets the role ROLE_ADMIN_USER. Similarly, user ashish gets the 'ROLE_APP_USER' role.

Let's now look at how web request security is configured for the Flight Booking application.

The following <http> element of security namespace shows how web request security is configured in the applicationContext-security.xml file of the flightapp-web project:

<http auto-config="true" use-expressions="true">
  <access-denied-handler error-page="/accessdenied" />
  <form-login .../>
  <logout logout-url="/resources/j_spring_security_logout" />

  <intercept-url pattern="/flights/**" 
    access="hasRole('ROLE_ADMIN_USER')" />

  <intercept-url pattern="/flightdescriptions/**" 
    access="hasRole('ROLE_ADMIN_USER')" />

  <intercept-url pattern="/bookings/**"
    access="hasAnyRole('ROLE_APP_USER','ROLE_ADMIN_USER')" />

  <intercept-url pattern="/accessdenied/**"
    access="hasAnyRole('ROLE_APP_USER', 'ROLE_ADMIN_USER')" />
 </http>

As in the previous recipe, we discussed the <http> element of the Roo-generated applicationContext-security.xml file; but here we'll only focus on configuration elements specifically added for meeting flightapp-web application's web security requirements. In the given code, the following are the elements that we added to configure web request security for the Flight Booking application:

Method-level security in the Flight Booking application is enabled by the <global-method-security> element in the applicationContext-security.xml file, as shown here:

<global-method-security mode="aspectj" 
   secured-annotations="enabled"/>

The mode attribute value specifies whether Spring AOP (which proxies the target object) or AspectJ (in which Spring's AspectJ security aspect is weaved into the class at load-time or compile-time) is used for securing methods. As Booking JPA entity is created outside the Spring container, to use Spring's @Secured annotation (discussed in the next section) to secure methods defined by Booking JPA entity, you need to use AspectJ. The value aspectj of the mode attribute instructs Spring to weave AnnotationSecurityAspect (available in the Spring Security's spring-security-aspects JAR file) into classes that make use of the @Secured annotation. The secured-annotations attribute specifies if the use of the @Secured annotations is enabled or disabled for the application context. The value enabled means that Spring Security will secure all methods that make use @Secured method-level annotation. Spring also supports using JSR-250 security annotations, security expressions (like hasRole, hasPermission, and so on), and the <protect-pointcut> sub-element of the <global-method-security> element to implement method-level security. You can use a combination of different approaches to implement method-level security in your application.

As we are using AspectJ mode for implementing method-level security in the Flight Booking application, dependency on spring-security-aspects JAR has been added to the pom.xml file, and the AspectJ compiler plugin configuration in the pom.xml file has been updated to include spring-security-aspects, as shown here:

   <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    ...
    <configuration>
     <outxml>true</outxml>
     <aspectLibraries>
      <aspectLibrary>
       <groupId>org.springframework</groupId>
       <artifactId>spring-aspects</artifactId>
      </aspectLibrary>
      <aspectLibrary>
       <groupId>org.springframework.security</groupId>
       <artifactId>spring-security-aspects</artifactId>
      </aspectLibrary>
     </aspectLibraries>
     ...
    </configuration>
   </plugin>

The <aspectLibrary> element specifies the JAR files that contain aspects. The spring-aspects JAR contains aspect for weaving @Transactional support and spring-security-aspects JAR contains aspect for weaving @Secured support in classes.

Now that we have seen how method-level security is configured for the Flight Booking application, we are ready to annotate Booking JPA entity methods with the @Secured annotation.

Spring Security's @Secured annotation can be used at method-level to secure methods from unauthorized access. @Secured annotation specifies the user roles that are authorized to invoke the method.

Adding Spring Security's @Secured annotation to JPA entity methods in Roo-generated applications is a bit of an involved process. Roo defines JPA entity methods in the *_Roo_Entity.aj AspectJ ITD file, which is not recommended to be modified by application developers. To add the @Secured annotation to a JPA entity method, perform push-in refactoring (refer to Chapter 7) to move the method to the entity's Java class or simply copy the methods from the AspectJ file to entity's Java class. For instance, in the case of the Booking JPA entity, the persist method is copied from the Booking_Roo_Entity.aj file to the Booking.java file, as shown here:

@RooEntity(identifierColumn = "BOOKING_ID")
public class Booking {
    @PersistenceContext
    transient EntityManager entityManager;
    ...
    @Transactional
    @Secured("ROLE_APP_USER")
    public void persist() {
        if (this.entityManager == null) 
           this.entityManager = entityManager();
        this.entityManager.persist(this);
    }
    
    public static final EntityManager entityManager() {
        EntityManager em = new Booking().entityManager;
        ...
        return em;
    }
}

The given code shows that the persist method is copied from Booking_Roo_Entity.aj to the Booking.java file. The @Secured annotation is added to the persist method to make it secure.

It is important to note that copying a method from AspectJ ITD to a Java file doesn't require moving dependent methods and attributes also. For instance, moving persist method from Booking_Roo_Entity.aj to Booking.java doesn't require moving entityManager attribute and entityManager() method, as shown in the code. It has been done to simplify understanding the code.