• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛

• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

<p>
Date:
<input name="mydatefield.day" size="3" type="text"> /
<input name="mydatefield.month" size="3" type="text"> /
<input name="mydatefield.year" size="6" type="text"> (dd/mm/yyyy)
</p>

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

Source URL: http://java.dzone.com/tips/pathway-acegi-spring-security-


Published on Javalobby (http://java.dzone.com)

Pathway from ACEGI to Spring Security 2.0

By Chris.Baker

Created 2008/04/22 - 9:44am

Formerly called ACEGI Security for Spring, the re-branded Spring Security 2.0 has delivered on its promises of making it simpler to use and improving developer productivity. Already considered as the Java platform's most widely used enterprise security framework [1] with over 250,000 downloads from SourceForge, Spring Security 2.0 provides a host of new features.This article outlines how to convert your existing ACEGI based Spring application to use Spring Security 2.0.

What is Spring Security 2.0

Spring Security 2.0 [2] has recently been released as a replacement to ACEGI and it provides a host of new security features:

Substantially simplified configuration.

OpenID integration, single sign on standard.

Windows NTLM support, single sign on against Windows corporate networks.

Support for JSR 250 ("EJB 3") security annotations.

AspectJ pointcut expression language support.

Comprehensive support for RESTful web request authorization.

Long-requested support for groups, hierarchical roles and a user management API.

An improved, database-backed "remember me" implementation.

New support for web state and flow transition authorization through the Spring Web Flow 2.0 release.

Enhanced WSS (formerly WS-Security) support through the Spring Web Services 1.5 release.

A whole lot more...

Goal

Currently I work on a Spring web application that uses ACEGI to control access to the secure resources. Users are stored in a database and as such we have configured ACEGI to use a JDBC based UserDetails Service. Likewise, all of our web resources are stored in the database and ACEGI is configure to use a custom AbstractFilterInvocationDefinitionSource to check authorization details for each request.
With the release of Spring Security 2.0 I would like to see if I can replace ACEGI and keep the current ability to use the database as our source of authentication and authorization instead of the XML configuration files (as most examples demonstrate).

Here are the steps that I took...

Steps

The first (and trickiest) step was to download [3] the new Spring Security 2.0 Framework and make sure that the jar files are deployed to the correct location. (/WEB-INF/lib/)
There are 22 jar files that come with the Spring Security 2.0 download. I did not need to use all of them (especially not the *sources packages). For this exercise I only had to include:
spring-security-acl-2.0.0.jar

spring-security-core-2.0.0.jar

spring-security-core-tiger-2.0.0.jar

spring-security-taglibs-2.0.0.jar

Configure a DelegatingFilterProxy in the web.xml file.

 springSecurityFilterChain
 org.springframework.web.filter.DelegatingFilterProxy

 springSecurityFilterChain
 /*

Configuration of Spring Security 2.0 is far more concise than ACEGI, so instead of changing my current ACEGI based configuration file, I found it easier to start from a empty file. If you do want to change your existing configuration file, I am sure that you will be deleting more lines than adding.

The first part of the configuration is to specifiy the details for the secure resource filter, this is to allow secure resources to be read from the database and not from the actual configuration file. This is an example of what you will see in most of the examples:

Replace this with:

The main part of this piece of configuration is the secureResourceFilter, this is a class that implements FilterInvocationDefinitionSource and is called when Spring Security needs to check the Authorities for a requested page.
Here is the code for MySecureResourceFilter:
package org.security.SecureFilter;

import java.util.Collection;
import java.util.List;

import org.springframework.security.ConfigAttributeDefinition;
import org.springframework.security.ConfigAttributeEditor;
import org.springframework.security.intercept.web.FilterInvocation;
import org.springframework.security.intercept.web.FilterInvocationDefinitionSource;

public class MySecureResourceFilter implements FilterInvocationDefinitionSource {

 public ConfigAttributeDefinition getAttributes(Object filter) throws IllegalArgumentException {
 
 FilterInvocation filterInvocation = (FilterInvocation) filter;
 
 String url = filterInvocation.getRequestUrl();
 
 // create a resource object that represents this Url object
 Resource resource = new Resource(url);
 
 if (resource == null) return null;
 else{
 ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor();
 // get the Roles that can access this Url
 List roles = resource.getRoles();
 StringBuffer rolesList = new StringBuffer();
 for (Role role : roles){
 rolesList.append(role.getName());
 rolesList.append(",");
 }
 // don't want to end with a "," so remove the last ","
 if (rolesList.length() > 0)
 rolesList.replace(rolesList.length()-1, rolesList.length()+1, "");
 configAttrEditor.setAsText(rolesList.toString());
 return (ConfigAttributeDefinition) configAttrEditor.getValue();
 }
 }

 public Collection getConfigAttributeDefinitions() {
 return null;
 }

 public boolean supports(Class arg0) {
 return true;
 }

}

This getAttributes() method above essentially returns the name of Authorities (which I call Roles) that are allowed access to the current Url.

OK, so now we have setup the database based resources and now the next step is to get Spring Security to read the user details from the database. The examples that come with Spring Security 2.0 shows you how to keep a list of users and authorities in the configuration file like this:

You could replace these examples with this configuration so that you can read the user details straight from the database like this:

While this is a very fast and easy way to configure database based security it does mean that you have to conform to a default databases schema. By default, the requires the following tables: user, authorities, groups, group_members and group_authorities.
In my case this was not going to work as my security schema it not the same as what the requires, so I was forced to change the :

 
 users-by-username-query="SELECT U.username, U.password, U.accountEnabled AS 'enabled' FROM User U where U.username=?"
 authorities-by-username-query="SELECT U.username, R.name as 'authority' FROM User U JOIN Authority A ON u.id = A.userId JOIN Role R ON R.id = A.roleId WHERE U.username=?"/>

By adding the users-by-username-query and authorities-by-username-query properties you are able to override the default SQL statements with your own. As in ACEGI security you must make sure that the columns that your SQL statement returns is the same as what Spring Security expects. There is a another property group-authorities-by-username-query which I am not using and have therefore left it out of this example, but it works in exactly the same manner as the other two SQL statements.

This feature of the has only been included in the past month or so and was not available in the pre-release versions of Spring Security. Luckily it has been added as it does make life a lot easier. You can read about this here [4] and here [5].

The dataSource bean instructs which database to connect to, it is not included in my configuration file as it's not specific to security. Here is an example of a dataSource bean for those who are not sure:
 
 
 
 
 
 

And that is all for the configuration of Spring Security. My last task was to change my current logon screen. In ACEGI you could create your own logon by making sure that you POSTED the correctly named HTML input elements to the correct URL. While you can still do this in Spring Security 2.0, some of the names have changed.
You can still call your username field j_username and