原文链接:http://sarin.iteye.com/blog/832963
Security对数据库验证用户有两种方式,上文提到的是它默认支持的数据库表结构,但基本上用于实际是不现实的,因为我们的数据库都有自己的业务逻辑,所以现在来看看怎么在我们自己的数据库上进行Security框架的用户验证整合,这里给出一个比较通用的数据库权限设计结构:
假设我们的数据表名称为b_user和b_userrole,它们的结构如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
CREATE
TABLE
`b_user` (
`ID`
int
(11)
NOT
NULL
AUTO_INCREMENT,
`USERNAME`
varchar
(20)
NOT
NULL
,
`
PASSWORD
`
varchar
(32)
NOT
NULL
,
PRIMARY
KEY
(`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=4
DEFAULT
CHARSET=utf8
CREATE
TABLE
`b_userrole` (
`ID`
int
(11)
NOT
NULL
,
`USERID`
int
(11)
NOT
NULL
,
`ROLE`
varchar
(15)
NOT
NULL
,
PRIMARY
KEY
(`ID`),
KEY
`FK_USERID_USERROLE` (`USERID`),
CONSTRAINT
`FK_USERID_USERROLE`
FOREIGN
KEY
(`USERID`)
REFERENCES
`b_user` (`ID`)
ON
DELETE
NO
ACTION
ON
UPDATE
NO
ACTION
) ENGINE=InnoDB
DEFAULT
CHARSET=utf8
|
那么表名,字段名和结构都和Security框架默认的不匹配,只好通过SQL语句来让Security框架识别了,在配置文件的数据库验证部分,我们可以这么来写:
1
2
3
4
5
6
7
8
9
|
<
security:authentication-manager
>
<
security:authentication-provider
>
<
security:password-encoder
ref
=
"md5Encoder"
/>
<
security:jdbc-user-service
data-source-ref
=
"dataSource"
users-by-username-query
=
"select USERNAME,PASSWORD,'true' as ENABLED from b_user where USERNAME=?"
authorities-by-username-query
=
"select u.USERNAME,ur.ROLE as AUTHORITIES from b_user u,b_userrole ur where u.USERNAME=? and u.ID=ur.USERID"
/>
</
security:authentication-provider
>
</
security:authentication-manager
>
|
在jdbc-user-service中,我们启用了两个属性,其中放置的是SQL语句,就是我们自定义的用户验证方式,将我们的数据库设计和Security框架相匹配,这里的角色一定是在拦截url标签中配置过的,否则Security框架不能识别用户身份。
启动应用程序,发现这和原来的验证效果是一样的,这就是自定义的数据库验证方式了。也非常简单,就是用SQL语句查询结果匹配Security框架,不过这可能要和自己应用的数据库设计做出调整,尽量做到最小调整。
这里补充一点用户验证方式的配置,我们已经使用了在配置文件里配置用户和数据库验证,一种是支持为数不多的用户,一种是支持数据库大量查询的。对于前者,将配置信息写在XML文件中,和Security框架的配置信息粘在一起,不利于维护。其实Security框架也支持属性文件的配置,我们可以这么来写:
1
2
3
4
5
|
<
security:authentication-manager
>
<
security:authentication-provider
>
<
security:user-service
properties
=
"/WEB-INF/users.properties"
/>
</
security:authentication-provider
>
</
security:authentication-manager
>
|
这里把用户信息都写在了users.properties里,我们来看这个属性配置文件:
1
2
3
|
admin=123,ROLE_ADMIN,ROLE_USER
user1=123,ROLE_USER
user2=123,enabled,ROLE_USER
|
这里面名/值对的形式排列的,值的字段比较多,我们来逐个解释。admin/user1是用户名,不用多说,等号后面第一位是密码,这里没有加密。第二位是状态,这是可选的,默认是enabled,第三位以后就是用户所拥有的角色了,这么使用和前面的效果也是相同的。
用户验证部分基本就这么多内容,这里没有涉及到LDAP相关部分。下面是访问控制的说明,访问控制是Security框架的另一大特性,可以对其进行自定义的扩展,设计符合我们业务逻辑的控制。这比URL拦截又深入了一步,可以过滤的东西又多了。
设计到访问控制,要引入一个概念,谁来决定能否访问,从而进行控制。Security框架中的访问控制管理有三种方案:至少有一个同意访问,全部同意访问,全部弃权或都同意访问(也就是没有拒绝的)。如何同意?投票产生!Security框架一个可配置的元素就出来了,那就是投票器了。和现实的投票一样,分同意,反对和弃权三类。
下面我们应用第一类访问控制管理:至少有一个投票器同意访问,在配置文件中这么来设置:
1
2
3
4
5
6
7
8
9
|
<
bean
id
=
"accessDecisionManager"
class
=
"org.springframework.security.access.vote.AffirmativeBased"
>
<
property
name
=
"decisionVoters"
>
<
list
>
<
bean
class
=
"org.springframework.security.access.vote.RoleVoter"
/>
<
bean
class
=
"org.springframework.security.access.vote.AuthenticatedVoter"
/>
</
list
>
</
property
>
</
bean
>
|
上面是默认需要的认证投票,下面就是我们定制的内容了,用来满足特定需要。在消息发布应用中,有这样一个需求,在服务器上登录的用户,给可以删除消息的权限,也就是说不用管理员账户登录,也能删除。那么我们就需要对访问进行控制。在服务器本身登录的用户的IP应该是本地地址127.0.0.1,那么只要IP是它的允许删除,我们来自定义一个投票器来进行投票:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
package
org.ourpioneer.board.security;
import
java.util.Collection;
import
org.springframework.security.access.AccessDecisionVoter;
import
org.springframework.security.access.ConfigAttribute;
import
org.springframework.security.core.Authentication;
import
org.springframework.security.web.authentication.WebAuthenticationDetails;
public
class
IPAddressVoter
implements
AccessDecisionVoter {
public
static
final
String IP_PREFIX =
"IP_"
;
public
static
final
String IP_LOCAL_HOST =
"IP_LOCAL_HOST"
;
public
boolean
supports(ConfigAttribute attribute) {
return
attribute.getAttribute() !=
null
&& attribute.getAttribute().startsWith(IP_PREFIX);
}
public
boolean
supports(Class<?> clazz) {
return
true
;
}
public
int
vote(Authentication authentication, Object object,
Collection<ConfigAttribute> attributes) {
if
(!(authentication.getDetails()
instanceof
WebAuthenticationDetails)) {
return
ACCESS_DENIED;
}
WebAuthenticationDetails details = (WebAuthenticationDetails) authentication
.getDetails();
String address = details.getRemoteAddress();
int
result = ACCESS_ABSTAIN;
for
(ConfigAttribute config : attributes) {
result = ACCESS_DENIED;
if
(IP_LOCAL_HOST.equals(config.getAttribute())) {
if
(address.equals(
"127.0.0.1"
)
|| address.equals(
"0:0:0:0:0:0:0:1"
)) {
return
ACCESS_GRANTED;
}
}
}
return
result;
}
}
|
IP地址投票器仅处理属性开头是IP的访问,而支持访问的只能是IP_LOCAL_HOST访问属性。如果访问者的IP是127.0.0.1或者0:0:0:0:0:0:0:1的可以访问,其余的拒绝访问。在配置文件的投票器list中再加入这个类:
1
|
<
bean
class
=
"org.ourpioneer.board.security.IPAddressVoter"
/>
|
之后还要在URL拦截属性中修改配置IP_LOCAL_HOST属性的访问权限:
1
|
<
security:intercept-url
pattern
=
"/messageDelete.htm"
access
=
"ROLE_ADMIN,IP_LOCAL_HOST"
/>
|
而且在http中还要配置访问决定管理器,否则是不能识别到IP_LOCAL_HOST的:
1
|
<
security:http
access-decision-manager-ref
=
"accessDecisionManager"
>
|
此时,在本地用user1用户登录,也具有了删除权限,可以删除文章了。这就是投票器的简单应用了。下面是方法调用安全,这是非常细粒度的安全控制,可以作用于类的方法,那么也就是说,对一块业务逻辑有权限的用户组,可能允许你能添加而不能删除,他能修改而不能添加和删除,这都是可以实现的,因为这已经细化到了方法之上了,一个类的某一个方法给你授权访问,其余方法就访问不到,细化到一个功能点上的访问,安全性有很大的提升。先看看对控制器方法的安全访问,这个配置相对简单,在配置文件中,把安全配置文件和controller的声明放在一起:
1
2
3
|
<
context:component-scan
base-package
=
"org.ourpioneer.board.web"
/>
<
security:global-method-security
jsr250-annotations
=
"enabled"
secured-annotations
=
"enabled"
/>
|
这样才能对controller的方法进行控制。不过对方法实行安全控制之后,就没有必要对URL进行拦截了,http配置中的url拦截就都可以去掉了,仅留下登录和退出的就可以了:
1
2
3
4
5
6
|
<
security:http
access-decision-manager-ref
=
"accessDecisionManager"
>
<
security:form-login
login-page
=
"/login.jsp"
login-processing-url
=
"/login"
default-target-url
=
"/messageList.htm"
authentication-failure-url
=
"/login.jsp?error=true"
/>
<
security:logout
logout-success-url
=
"/login.jsp"
/>
</
security:http
>
|
虽然这里加入了access-decision-manager-ref="accessDecisionManager",但是对方法的安全不是这里做的,所以这样的话使用user1登录就没有对消息的删除权限了,那么怎么能恢复呢?很简单,在global-method-security中加入它就可以了。这就完成了对控制器方法的配置,那么因为前面都是注解实现的,所以在方法上配置注解就行了,前面代码很全,这里给出一个示例:
1
2
3
4
5
6
7
8
9
10
|
@RequestMapping
(method = RequestMethod.GET)
@Secured
( {
"ROLE_ADMIN"
,
"IP_LOCAL_HOST"
})
public
String messageDelete(
@RequestParam
(required =
true
, value =
"messageId"
) Long messageId,
Model model) {
Message message = messageBoardService.findMessageById(messageId);
messageBoardService.deleteMeesage(message);
model.addAttribute(
"messages"
, messageBoardService.listMessages());
return
"redirect:messageList.htm"
;
}
|
只要在注解方法上表明可访问的权限就能实现拦截了。当然在Service上实现拦截同理可得,只是需要注意一下注解声明的所在配置文件,否则可能无效,这确实有点不爽。方法拦截除了注解,还有嵌入配置方式和切点配置方式,这两种都是常规做法,参考官方文档就可以了。
最后一点是V层的拦截,这在前面已经提到了,使用的是Security框架的标签库实现的。可用的标签和属性,直接参考官方文档即可,使用也很方便,这里就不过多说明了。
Spring 3的MVC和Security框架的简单整合就介绍完了,没有过深内容,都是基础应用,如果想深入了解,官方文档是最佳的学习资料。