Spring Security优劣之我见

Spring Security是不容易上手，但再找不到其他比它更好点的权限解决方案了。

看了daquan198163,downpour,guoxu1231关于角色控制的说明，SS也是支持RBAC的。
那在这样的项目里面：客户需要自己创建角色，而且角色将要赋予什么权限在系统上线的时候确定、而且需要修改的话。 建议采用  重新实现下FilterInvocationDefinitionSource这个类。

本文的用意是帮助开发者，尤其是初学者，对Spring Secuirty有个大致了解。这样再看其他帖子或者教程的时候，会轻松很多，加快入门速度。

同时，我也站在项目管理的角度，审查Spring Security是否合适在项目里面运用，付出的代价如何，得到多大回报。

演示例子：（构建项目，编写业务代码等）
http://www.metadmin.com/demo1/index.html
权限逻辑定制过程：（FLASH， 持续时间约8分钟，全屏观看效果更好一些）
http://www.metadmin.com/download/showEmployees.html

我的场景和LZ的差不多，但是我们一直没有找到解决权限的好办法。

对于数据权限，就是能看到什么看不到什么，这个通常是通过SQL的条件去搞定，但是最后就出现了SQL超长的问题，最后只好在存储过程中搞定了。特殊一点的就是，江苏的能看到南京的，南京的看不到扬州的。这种上下级关系的也要支持

对于操作权限，就是按钮需要不需要显示。这个一般是在按钮上加上权限码，然后检查该用户是否有该权限码。

不知道SS能否搞定这两种权限。

关于细粒度的控制数据权限，我有个想法：比如要求江苏的能看到南京的报表，南京的看不到扬州的报表
那么我可以定义一个资源叫“查看报表”viewReport.do，注册到资源表里，
但这个粒度太大，要么全能看，要么全不能看，
于是我给这个资源增加一个rule属性，里面用来保存权限规则，比如groovy脚本，
里面可以写任意复杂的规则，什么ip范围、时间段、行政级别…… 应该能做的灵活和通用了。


可以的，SS的标签库就是做这个的。
但我觉得它自带的标签库有问题:<security:authorize ifAllGranted="ROLE_admin">xx</security:authorize>
这样就把角色写死在页面里了，我觉得更好的做法是
<security:authorize ifAllGranted="/xx.do">xx</security:authorize>，即声明这个被保护的页面元素对应了哪个资源，至于这个资源需要哪个角色标签库程序是很容易获得的，进而计算是否有权查看。

通常的做法是这么个表。

文档  操作人 权限类型 权限
文档1 江苏      群    查看
文档1 南京      群    查看
文档1 扬州      群    查看，编辑
文档1 扬州某人  个人  查看，编辑，删除
文档2 江苏      群    查看
文档2 南京      群    查看
文档2 南京某人  个人  查看，编辑，删除

用数据库做权限存储的，只能通过SQL的条件或存储过程去搞定，因为还有个分页问题，不用数据库内置的能力想不出有什么办法。可能你需要一个缓存。

后一种权限SS没有现成的接口，SS有个问题就是你没有接口询问它你能不能做某个操作，也就是你去操作某个方法，等有没有异常抛出来，捕捉到异常你就没有按某个按钮的权限。这种事情只能按钮带有权限码了，最好这个东西让配置管理工具去做。显示页面的时候，就拿这个人的身份和按钮上的权限比较，得出是否显示。

按钮A 南京某人 个人 可见
按钮B 江苏     群   可见

[quote="daquan198163可以的，SS的标签库就是做这个的。
但我觉得它自带的标签库有问题:<security:authorize ifAllGranted="ROLE_admin">xx</security:authorize>
这样就把角色写死在页面里了，我觉得更好的做法是
<security:authorize ifAllGranted="/xx.do">xx</security:authorize>，即声明这个被保护的页面元素对应了哪个资源，至于这个资源需要哪个角色标签库程序是很容易获得的，进而计算是否有权查看。

问题是ROLE就很多了。有些ROLE不能预设，比如，突然来了个 “南京纪检组”，必须动态的加的。

所以我说应该改成<security:authorize ifAllGranted="/xx.do">xx</security:authorize>这样的方式啊，
资源是很少变的。

/xx.do需要定义xx.do 会很多这样的东西。有时候有些比较变态的要求，某份资料只能几个部门可见，其他平级部门不可见。所以，页面只能保留增加，删除，编辑，保存等基础按钮，而另外的操作需要放在页面流去做，满足某个权限才进入特定的页面流。这样，基础按钮就容易被管理工具管理起来了。

可能我说得不够清楚：
<security:authorize ifAllGranted="ROLE_GROUP_123,ROLE_PERSON_456">xx</security:authorize>

如果PERSON ID是456的人离职了，或者GROUP ID是123的部门撤并了。用到的地方都要改，改起来工作量很可观。

定义为xx.do，就要在某个需要管理这些类别的地方需要定义xx.do后面代表了什么，比如南京，南通，扬州等，yy.do表示江苏、浙江等。或者你可以加后缀.xx_city.do,yy_province.do，但如过要表示南京纪检组呢？xx.do会很长，这是用字符串表示的缺陷，既要管理键"xx.do"还要管理后面的值“某人，某部门”,放在关键字里面会满屏的，不借助工具是很难达到合理管理。这些要看公司的技术积累了。