不管在是在service还是action加权限验证，实际是RBAC模块是可以分离的，我在去年的时候完成了这个模块，然后项目的时候只要把这个模块加进去就可以了。如果实际项目是可以通过url来控制权限的，那么就可以不用写一行代码。 在RBAC模块里完全可以做到很细的控制。
资源概念(可以是url，还有刚才看到有人说.do后面的参数那不到，参数当然可以拿的的,只不过url被切分成两部分而已，一部分就是参数.可以通过getQueryString得到)
资源就是想要的到的最终物质,我们可以给每一个资源定义一个权限，也可以给某一类资源定义一个权限,而web项目 url的tree特别容易用来管理资源。资源是一棵树,如果你有管理树根的权限那么就有了这颗树的所有权限。
权限概念
权限是对资源的一种保护访问.用户要访问A资源前提是用户必须有A资源的访问权限.
角色概念
实事上我们不会直接把权限赋予给用户，而是通过角色来赋予给用户,因为用户拥有某一种权限是因为用户扮演着某一种角色。
A是个经理,他管理着B公司,他拥有b,c,d的权限。实际是不是A有这个权限，而是因为Abo是经理。因为经理拥有b,c,d权限
所以很显然在权限划分上，我们会把权限赋予给某一个角色，而不是赋予给个人。这样带来的好处是
如果公司换了经理，那么只要再聘用一个人来做经理就可以了，而不会出现因为权限在个人手里导致权限被带走的情况
分组概念(分组也是一棵树，用户就是这里的叶子)
只有角色是不够的，B公司发现A有财务问题成立了一个财务调查小组,然后我们赋予了这个小组财务调查员的角色(注意是赋予小组这个角色).这样这个小组的所有人员
都有财务调查的资格。而不需要给小组的每个人都赋予这个角色(实际上已经拥有了)，分组概念也适合部门，因为任何一个部门在公司里或者社会上都在扮演着一个泛的角色。
用户
用户一定是属于某一个分组的,不存在不属于分组的用户.不过用户可以直接扮演(获得)角色，或者通过属于的分组来得到角色
最后一个概念
判断用户有没有访问资源的权限就看这个用户有没有访问这个资源的权限,也就是说分组，分部门,分角色最终是以权限来实现对资源的访问控制