1 数据级的权限管理和功能级的权限管理
引自:
http://www.iteye.com/problems/97374
功能级权限
，有大有小。大的可以直接包括一个业务模块，小的可以是一个按钮。一般的功能级权限一般包括：菜单、url、按钮 。
数据级权限
主要是针对访问数据的可见范围。一般包括以下几类：当前操作人可见、部门可见、部门及子部门可见……等。数据级权限目前常用的做法就是在业务模块的表中增加操作人字段（如：creator），然后通过aop或者是在基类的查询、查看、更新、删除中，把creator字段值与可见范围进行特殊处理。
2 不使用框架(shiro,springsecurity)做权限设计的思考(我的理解是拼sql)
以下三篇连接转载自：oschina博主”
悠悠然然
”
https://my.oschina.net/tinyframework/blog/630801
https://my.oschina.net/tinyframework/blog/653256
https://my.oschina.net/tinyframework/blog/675439
所谓操作权限
就是有或者没有做某种操作的权限，具体表现形式就是你看不到某个菜单或按钮，当然也有的是把菜单或按钮灰掉的形式。实际上它的实现机制比表面上看到的要复杂得多，比如：我们从浏览器访问过一个地址之后，实际上这个URL就会在历史中存在，这时就会存在一种可能，有的人虽然没有权限，但是他知道怎么访问的URL，如果他再有一定的技术基础，那么通过猜测，有时候就可以得到真正的操作的URL，这个时候如果操作权限限制做得不到位，那么他就可能做他非授权的事项，所以操作权限一般都在显示界面做一次控制，过滤没有权限的操作菜单或按钮，另外在真正执行操作时，还要进行一次权限检查，确保控制非授权访问。
所谓数据权限
就是有或者没有对某些数据的访问权限，具体表现形式就是当某用户有操作权限的时候，但不代表其对所有的数据都有查看或者管理权限。数据权限有两种表现形式：一种是行权限、另外一种是列权限。所谓行权限，就是限制用户对某些行的访问权限，比如：只能对本人、本部门、本组织的数据进行访问；也可以是根据数据的范围进行限制，比如：合同额大小来限制用户对数据的访问。所谓列权限，就是限制用户对某些列的访问权限，比如：某些内容的摘要可以被查阅，但是详细内容就只有VIP用户才能查看。通过数据权限，可以从物理层级限制用户对数据的行或列进行获取，这种方式比把所有数据拿到之后再根据用户权限来限制某些行或列有诸多好处：
性能提升：获取的数据量较少，节省了网络流量和数据库IO，一定程度上可以提升性能
翻页处理更为准确：如果通过后续逻辑去掉某些行，就会导致一页显示的记录条数不足，或者采用这条记录只显示部分内容，但是操作权限方面做限制的方式，这个时候就产生一个悖论，你不想让我操作，为什么让我看到？你让我看到为什么不让我操作？
安全风险提升：理论上让攻击者看到的信息越多，被攻击的风险也越大。通过后续业务逻辑限制的方式通过攻击控制层或展现层的代码，理论上就可以获取到所有的数据。
代码编写工作量增加：由于数据是正常全部返回的，只是通过后期的逻辑进行了控制，这个时候就需要开发人员增加相关的代码来进行判断和控制，这个时候会把高层级的限制逻辑暴露给底层业务开发人员，并由他们来编写代码进行限制。
代码重构工作量增加：当权限限制逻辑或范围有变化的时候，程序员们就需要对这部分逻辑进行重构，稍不注意就会出现数据安全问题。
操作权限相对来说比较简单，目前也有比较好的解决方案，因此今天的不讨论操作权限，今天重点来讨论数据权限的实现方案。
需求整理
一个好的数据权限方案要考虑哪些问题呢？我觉得要考虑以下方面：
对程序员透明：整个方案对于程序员们来说，不论是前台还是后台的程序员们来说，越透明越好，他们最好不知道有这么回事情
与不同的用户权限能较好集成：作为一个数据权限系统来说，肯定要和用户、角色、组织机构什么的数据打交道。如果这个方案只能和某一种用户权限系统集成，那么它充其量只能算是一个可用的解决方案，但是注定算不是上好的解决方案。
性能损失最少：我们说，要增加新的功能或限制的过程中，肯定会对性能方面有一定影响的，怎么样能把性能损失降低，甚至能提升一定的性能是设计师们永恒的主题。
对于分页能良好支持：上面有说到当采用了行权限时，有些行是不能显示给用户的，这个时候不能对分页有影响，比如本来是一页是10条的，现在忽然变成8条，甚至在极端情况下变成0条，这样的用户体验就非常差了。
一次设定到处生效,哪怕是不同的ORMapping方案也都起作用：我们知道，现在采用唯一的一种ORMapping解决方案的场景已经越来越少了，不同的方案都有自己的优缺点，它可能只适应某种前置条件下的应用场景，实际应用的情况下根据场景不同使用不同的解决方案也是非常普遍的，这就要求解决方案有一定的普适定。
跨数据库：一个项目，它的运行环境基本上是确定的。但是对于一个产品来说，根据用户的实际场景不同，可能对于数据库也有不同的要求，这个时候就需要对不同的数据库有支持，不能对于A数据库是支持的，对于B数据库的场景下，就出异常或者结果不正确了。
需求分析
由于要对程序员透明，因此解决方案不应该在DAO层实现。
由于要和不同的用户权限系统进行集成，因此确定了不能在DAO层实现。
对于分页有良好的支持，决定了不能在DAO层和显示层实现。
一次设计到处生效，对多种ORMapping方案生效，决定了不能在ORMapping层实现。
要求能跨数据库，进一步提升了方案的通用性和普适性，也提升了实现的难度。
数据行权限不是所有的过滤条件都是和用户、角色、岗位字段有关的，不是所有的表中，都有用户、角色、岗位字段，这个时候也要能良好支持。比如：人员信息表中：不同的级别的HR，可以看到不同级别的人员信息。总之过滤条件可能是数据表中的任意字段。
数据列权限是控制列的可见性的，也就是说，同样对这行数据有权限，但是可能对其中的几列没有权限，则这几列不可见。
比如表table1 有（a,b,c,d,e,f）字段，列权限控制可能控制c,d不可见。但是程序员写代码的时候可能写的是select * from table1，这种情况下也不能返回c,d字段。
3
http://bbs.csdn.net/topics/390643734
RBAC就是个基础模型，它是基础的但不是万能的。这就好比冯诺依曼的计算机模型，是非常基础的，只要是学计算机的都必然要先学习这套模型；但现在的计算机没有哪个是仅仅依据冯诺依曼的模型来设计的，都在各个方面做出了长足的扩展与优化，比如CPU和内存之间的多级缓存，比如IO通道上的独立计算芯片（相当于一个简易CPU了）。
所以无论是什么系统，多半都会在RBAC上进行扩展甚至裁剪。
以上说的比较空些，下面说点我自己的理解。
权限总体而言可以分为两类：功能权限 和 数据权限。功能权限泛指对某个功能（页面、按钮、命令）的使用权；数据权限则泛指所能操纵的范围；比如你有删除邮件的功能（功能权限），但只能删除自己的邮件（数据权限）。
当功能权限数量过于庞大，导致管理复杂度太高时，自然就会考虑对其进行分类，于是诞生了一个新的概念：“角色”，也即一组权限的集合，我也见过某些系统称之为“权限模板”。
随后又会面临另一个问题，就是功能权限与数据权限的匹配问题，比如你作为版主，你可以删除你板块下的任何帖子，但修改却只能针对自己的帖子，这就是不同功能权限匹配了不同的数据权限。
为此某些系统会为此诞生一个新的概念：“岗位”，有些也会称之为“业务组”之类的很多名字；简化的处理方式也有直接将数据权限跟组织机构直接对应起来从而忽略数据权限的管理。
再写下去似乎不好结束了啊。。。看来只好草草收场了。总的来说：尽可能理解各种设计的优异之处和局限性，然后根据业务需求来设计符合系统要求的权限模型，然后不要忘了：简洁就是美。