在一般的Web项目中都多少需要点权限认证什么的，用Spring的福音，SpringFramework出了一个可以进行权限认证的小东西，原先是叫ACEGI，很初级的一个东西，使用起来很麻烦，就像当年的JDBC一样，现在Spring把它大大的包装了一下，叫Spring Security 2，表示一个新面孔的产品，使用起来大大的简化，功能也强大起来，就像现在遍地的ORM比如Hibernate之类的。

说起来，东西虽好，但是用起来还是要慎重，就像一把抢，不要乱用哦。
一般来说SS2用在系统登陆验证方面应当很不错，没什么大问题，支持的验证种类也很多，
想用的尽管用吧。
上面也说过，他的功能很强大，不止局限于登陆验证，还可以对系统所有URL级别的访问进行访问权限控制，以及业务中的方法级进行控制，但是，我们要看到，如果使用这些功能，必然导致性能的下降，很明显，你既然要求它干这些工作，那么，他就任劳任怨的对所有访问系统的URL和方法进行检查，虽然它不怕麻烦，但是，你却必须为此付出不菲的开销，如果验证的规则再稍微那么复杂一点，呵呵，对不起，花销更大。

并不仅仅是SS2有这个问题，所有的这种需求都会导致这种问题，所以，如果你要想用，就必须要慎重。

首先，尽量减少URL和方法验证的规则的简约化，让它在验证的时候，最好一矢中的，不要七拐八拐的才找到目标，要知道每拐一次费用就会增加一倍甚至更多。
其次，尽量减少要验证的URL和方法的数量，这个也很主要，但是有人要问了，明明都是需要验证的怎么减少？这个可以从两个方面来看，对于URL，可以把有相同权限的URL尽量的归并到一个大的组/目录中，对这个上级目录进行控制岂不是就减少了数量？对于方法，尽量对它的更上级进行控制，比如SSH项目中的Manager或者Service中的主方法，而不是DAO中的那些零散的方法。
再次，分散权限检查到其它部分，虽然SS2可以做所有的检查，但是也不是非要他做不可，比如一些业务权限划分明确的一些业务模块，可以把这些模块通过目录菜单等的方式或者权限标签的方式，控制他们的显示和不显示，从而降低无权限的角色对权限以外的资源的请求，从而降低底端的验证开销。还有就是不要把多个权限的操作放到一个页面中，尽量拆分开，一种权限一个页面，让菜单来控制它，也能降低开销。
最后，如果你的这个系统服务器很强大，访问量很低，比如一个用户量很少的OA什么的系统，根本不在乎什么性能上的这点开销，那你还等什么，统统给他加上，即显示出来你们的产品功能的强大，又满足了客户的变态要求，何乐而不为？