5 min read

(For more resources on Spring, see here.)

During the course of this article we will:

  • Review important enhancements in Spring Security 3
  • Understand configuration changes required in your existing Spring Security 2 applications when moving them to Spring Security 3
  • Illustrate the overall movement of important classes and packages in Spring Security 3

Once you have completed the review of this article, you will be in a good position to migrate an existing application from Spring Security 2 to Spring Security 3.

Migrating from Spring Security 2

You may be planning to migrate an existing application to Spring Security 3, or trying to add functionality to a Spring Security 2 application and looking for guidance. We’ll try to address both of your concerns in this article.

First, we’ll run through the important differences between Spring Security 2 and 3—both in terms of features and configuration. Second, we’ll provide some guidance in mapping configuration or class name changes. These will better enable you to translate the examples from Spring Security 3 back to Spring Security 2 (where applicable).

A very important migration note is that Spring Security 3 mandates a migration to Spring Framework 3 and Java 5 (1.5) or greater. Be aware that in many cases, migrating these other components may have a greater impact on your application than the upgrade of Spring Security!

Enhancements in Spring Security 3

Significant enhancements in Spring Security 3 over Spring Security 2 include the following:

  • The addition of Spring Expression Language (SpEL) support for access declarations, both in URL patterns and method access specifications.
  • Additional fine-grained configuration around authentication and accessing successes and failures.
  • Enhanced capabilities of method access declaration, including annotationbased pre-and post-invocation access checks and filtering, as well as highly configurable security namespace XML declarations for custom backing bean behavior.
  • Fine-grained management of session access and concurrency control using the security namespace.
  • Noteworthy revisions to the ACL module, with the removal of the legacy ACL code in o.s.s.acl and some important issues with the ACL framework are addressed.
  • Support for OpenID Attribute Exchange, and other general improvements to the robustness of OpenID.
  • New Kerberos and SAML single sign-on support through the Spring Security Extensions project.

Other more innocuous changes encompassed a general restructuring and cleaning up of the codebase and the configuration of the framework, such that the overall structure and usage makes much more sense. The authors of Spring Security have made efforts to add extensibility where none previously existed, especially in the areas of login and URL redirection.

If you are already working in a Spring Security 2 environment, you may not find compelling reasons to upgrade if you aren’t pushing the boundaries of the framework. However, if you have found limitations in the available extension points, code structure, or configurability of Spring Security 2, you’ll welcome many of the minor changes that we discuss in detail in the remainder of this article.

Changes to configuration in Spring Security 3

Many of the changes in Spring Security 3 will be visible in the security namespace style of configuration. Although this article cannot cover all of the minor changes in detail, we’ll try to cover those changes that will be most likely to affect you as you move to Spring Security 3.

Rearranged AuthenticationManager configuration

The most obvious changes in Spring Security 3 deal with the configuration of the AuthenticationManager and any related AuthenticationProvider elements. In Spring Security 2, the AuthenticationManager and AuthenticationProvider configuration elements were completely disconnected—declaring an AuthenticationProvider didn’t require any notion of an AuthenticationManager at all.

<authentication-provider>
  <jdbc-user-service data-source-ref="dataSource"
  />
</authentication-provider>

In Spring Security 2 to declare the <authentication-manager> element as a sibling of any AuthenticationProvider.

<authentication-manager alias="authManager"/>
<authentication-provider>
  <jdbc-user-service data-source-ref="dataSource"/>
</authentication-provider>
<ldap-authentication-provider server-ref="ldap://localhost:10389/"/>

In Spring Security 3, all AuthenticationProvider elements must be the children of <authentication-manager> element, so this would be rewritten as follows:

<authentication-manager alias="authManager">
  <authentication-provider>
    <jdbc-user-service data-source-ref="dataSource"
    />
  </authentication-provider>
  <ldap-authentication-provider server-ref=
    "ldap://localhost:10389/"/>
</authentication-manager>

Of course, this means that the <authentication-manager> element is now required in any security namespace configurations.

If you had defined a custom AuthenticationProvider in Spring Security 2, you would have decorated it with the <custom-authentication-provider> element as part of its bean definition.

<bean id="signedRequestAuthenticationProvider"
  class="com.packtpub.springsecurity.security
  .SignedUsernamePasswordAuthenticationProvider">
  <security:custom-authentication-provider/>
  <property name="userDetailsService" ref="userDetailsService"/>
<!-- ... -->
</bean>

While moving this custom AuthenticationProvider to Spring Security 3, we would remove the decorator element and instead configure the AuthenticationProvider using the ref attribute of the <authentication-provider> element as follows:

<authentication-manager alias="authenticationManager">
  <authentication-provider ref=
  "signedRequestAuthenticationProvider"/>
</authentication-manager>

Of course, the source code of our custom provider would change due to class relocations and renaming in Spring Security 3—look later in the article for basic guidelines, and in the code download for this article to see a detailed mapping.

New configuration syntax for session management options

In addition to continuing support for the session fixation and concurrency control features from prior versions of the framework, Spring Security 3 adds new configuration capabilities for customizing URLs and classes involved in session and concurrency control management. If your older application was configuring session fixation protection or concurrent session control, the configuration settings have a new home in the <session-management> directive of the <http> element.

In Spring Security 2, these options would be configured as follows:

<http ... session-fixation-protection="none">
<!-- ... -->
  <concurrent-session-control exception-if-maximum-exceeded
    ="true" max-sessions="1"/>
</http>

The analogous configuration in Spring Security 3 removes the session-fixation-protection attribute from the <http> element, and consolidates as follows:

<http ...>
  <session-management session-fixation-protection="none">
    <concurrency-control error-if-maximum-exceeded
      ="true" max-sessions="1"/>
  </session-management>
</http>

You can see that the new logical organization of these options is much more sensible and leaves room for future expansion.

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here