RBAC，thinkphp的rbac容易理解么

本文目录一览

1，thinkphp的rbac容易理解么
2，角色访问控制具有什么便于大规模实现等优点
3，请问下有谁熟悉ThinkPHP中的RBAC 感谢
4，制定什么策略的目的之一是保护
5，简述什么是基于角色的访问控制rbac
6，rbac是什么意思
7，什么是rbac
8，网站搭建后台用户角色权限管理系统的模板一
9，谁能通俗的教我一下RBAC

1，thinkphp的rbac容易理解么

让我来告诉你答案!容易理解与RBAC访问控制相关的概念有：1.用户（User）：一个具有唯一标识符的用户，与权限相分离，只能通过所属的Role去关联权限，一个用户可以拥有多项角色；2.角色（Role）:一定数量的权限的集合，角色可以继承，一个角色对应多项权限；3.权限（Resource）：也可以看作是资源，它对应了应用系统中的一个功能；

thinkphp的rbac容易理解么

2，角色访问控制具有什么便于大规模实现等优点

角色访问控制具有“什么”便于大规模实现等优点：角色访问控制具有“便于授权管理、便于赋予最小特权、便于根据工作需要分级”便于大规模实现等优点，不具有便于分担任务的特点。基于角色的访问控制RBAC（Role-Based Access Control）：系统元素可分为：权限角色用户需满足：权限与角色多对多关联，可对角色赋予和回收权限，权限也分配给多个角色；角色和用户多对多，用户可分属不同角色，角色也可以分配给多人。

角色访问控制具有什么便于大规模实现等优点

3，请问下有谁熟悉ThinkPHP中的RBAC 感谢

你对MVC或者说thinkphp体味吗？rbac你可以看看视频教程《LAMP兄弟连李文凯讲ThinkPHP》在我的理解中rbac是一种基于节点-脚色-用户的模子你可以在rbac中添加你的项目的名称模块的名称操作的名称使RBAC可以按照数据库内容来限制用户的访谒。查看原帖>>

rbac 供给的只是一种把权限分组的打点体例，只要你把你的模子思虑的正确，很少有不能应用的，至少我没有见过，rbac至于你说的阿谁应该是thinkphp自带的使用rbac写的一个例子。这个应该是个参考。点击禁用后，在用户里，应该没有法子选择这个脚色了。

请问下有谁熟悉ThinkPHP中的RBAC 感谢

4，制定什么策略的目的之一是保护

制定安全策略的目的之一是保护重要资源，保证机构或企业的安全运行，减少不必要的风险和损失，满足系统特定的安全需求。制定安全战略的基本依据包括:综合考虑企业及其组织的安全需求、安全环境分析、安全管理体系、安全加固技术、法律法规及相关标准、风险评估与分析等。计算机安全是系统的安全，它具有整体性，因为计算机系统是由许多不同的组件组成的，这些组件相互影响，每个组件的安全对整个系统的安全有重要影响。因此，只有将所有组件结合起来，才能有效保证系统的安全性。RBAC的基本原则是最小特权原则，即用户只能拥有最小的特权来完成所需的任务。基于角色的访问控制(RBAC)是一种使用用户角色的访问授权模型，在这种模型中，用户必须拥有特定的角色才能访问特定的资源。RBAC管理一组允许用户访问的角色和资源，而不是授予用户直接访问权限。

5，简述什么是基于角色的访问控制rbac

访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制(通常是通过物理上和基于系统的控制)。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备中实现。　　就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色(比如医生、护士、出纳、经理)。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。　　访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等;而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。　　控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。

在分布式系统中，不同的计算机系统之间经常要进行资源的互相访问，由此带来的安全性问题与通常环境下的安全问题有比较大的不同，比如通常访问控制一般有一个中央主机控制系统的安全策略和进行用户认证、访问控制等相关安全性检验工作，但是在分布式异构系统中往往并不存在这样的一个统一的安全控制中心，那么当一个系统中的用户或计算机要访问另一个系统的资源时，如何进行相关的安全控制保护呢？在论文中，首先分析了用传统访问控制方法来实现分布式资源互访的缺点，然后讨论了如何利用基于角色的访问控制（rbac）来实现分布式系统中的资源共享。-

6，rbac是什么意思

rbac的意思是基于角色的权限访问控制。基于角色的权限访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。银行应用中，把借款、存款操作权限指派给出纳角色，把批准贷款操作权限指派给经理角色。而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。模型特点：符合各类组织机构的安全管理需求。RBAC模型支持最小特权原则、责任分离原则，这些原则是任何组织的管理工作都需要的。这就使得RBAC模型有广泛的应用前景。RBAC模型支持数据抽象原则和继承概念。由于目前主流程序设计语言都支持面向对象技术，RBAC的这一特性便于在实际系统中应用实现。模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型。RBAC模型仍素具访问控制类模型，本质是对访问矩阵模型的扩充，能够很好的解决系统中主体对客体的访问控制访问权力的分配与控制问题，但模型没有提供信息流控制机制，还不能完全满足信息系统的全部安全需求。

7，什么是rbac

以角色为基础的访问控制（Role-based Access Control, RBAC）

基于权限的访问控制（Role Based Access Control），由于需要把权限抽象出来，做成taglib，所以最近看了一点理论，主要有：http://csrc.nist.gov/rbac/http://www.oone.com.cn/article/security.htmhttp://www.jdon.com/jive/article.jsp?forum=46&thread=10122http://www.jdon.com/jive/article.jsp?forum=46&thread=7309及其他jdon里的一些文章。具体实现的时候，大家作的都不太一样，而且对这个理论的认同度好像也有差异。我现在疑惑的是：1 现在有没有一套经过实践证明好用的基于java语言的RBAC实现，可以直接使用的。2 sun的jaas是不是基于RBAC思想设计的，具体实现时，它对这样的授权（比如谁能添加，谁能修改什么栏目的什么记录，）支不支持，如果支持，sun的jaas在这方面有没有参考实现，忘了在什么地方看的，说chinaxp论坛用的是jaas来实现权限管理，不知是不是这样。3 jive3的权限管理是不是基于RBAC的，因为我在看帮助时，看到了“role-based administration"，而且在管理jive的过程中，我感觉确实和自己了解的RBAC理论停相符的，当然，我对RBAC的理解可能有偏差。jive3的权限管理能在多大程度上抽象出

用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。

8，网站搭建后台用户角色权限管理系统的模板一

网站建设是指使用标识语言(markuplanguage)，通过一系列设计、建模、和执行的过程将电子格式的信息通过互联网传输，最终以图形用户界面(GUI)的形式被用户所浏览。那么网站搭建后台用户角色权限管理系统的模板有哪些?一.用户角色权限系统说明1.RBAC权限设计模型(1)RBAC(Role-BasedAccessControl，基于角色的访问控制)，就是用户通过角色与权限进行关联，从而获得某些功能的使用权限。权限被赋予给角色，而不是用户，但是一个用户可以拥有若干个角色，当一个角色被赋予给某一个用户时，此用户就拥有了该角色所包含的功能权限。简单地说，一个用户拥有若干角色，每一个角色拥有若干功能权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。2.三大模块搭建后台用户角色权限系统如上所述，一个后台的用户角色权限系统总是可以大概划分为三个打的模块的：用户管理、角色管理、权限管理。用户管理往往随着行政部门划分或者随着业务线部门划分，对应部门或者小组内的用户有着基本相似的功能需求和权限等级;角色管理相对来讲更加固定，它往往是基于业务管理需求而预先在系统中设定好的角色标签，一般不会随意更改，更像是一个用户分组标签;权限管理内容相对更加庞杂和丰富，主要包含了目标、操作和许可权三个部分，当某一功能权限授权给用户时，也就相当于为该用户开通了可以操作某个目标功能的许可权。3.权限管理(1)权限管理权限管理更多是从功能菜单、功能操作、数据参数三个不同颗粒度等级来考量的。具体颗粒度的大小视公司结构和团队规模而定，如果不是业务属性一定要求将权限控制到非常精细的级别，其实就没有必要将权限的颗粒度拆分到具体某一项操作或者某一个按钮，毕竟后台产品的核心是业务管理平台，主要目标是辅助业务的管理和推进。(2)功能菜单权限对于后台产品来讲，针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式，这种模式下用户一旦获得授权即可使用该菜单栏下的全部数据查看权限和功能操作权限;(3)功能操作权限功能操作层级的权限相对于功能菜单会更为深入，这种情况下，不同角色的用户可以进入同一菜单页后台查看相同的数据字段信息，但是他们可执行的功能操作不同;(4)数据字段权限数据字段层面是较细颗粒度的拆分，他会实现不同角色用户在进入同一菜单页后台时，可见的数据字段都有差异。比如销售人员进入某销售业绩管理后台时，可以看到自己的业绩提升数据，但是财务人员看到的是业务工单的费用字段，这些字段共存在一个菜单页中，只是受限于不同的角色权限而已。以上就是网站搭建后台用户角色权限管理系统的模板。网站网站搭建

9，谁能通俗的教我一下RBAC

哎呀，，难以通俗啊，，这种东西，，，只能是下面这些，，自己还得勤奋点，，RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。　　RBAC有许多部件，这使得RBAC的管理多面化。尤其是，我们要分割这些问题来讨论：用户与角色的指派；角色与权限的指派；为定义角色的继承进行的角色与角色的指派。这些活动都要求把用户和权限联系起来。然而在很多情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责。银行应用中，把借款、存款操作权限指派给出纳角色，把批准贷款操作权限指派给经理角色。而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。更一般来说，角色与角色的关系体现了更广泛的策略。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。　　Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）　　What：权限针对的对象或资源（Resource、Class）。　　How：具体的权限（Privilege,正向授权与负向授权）。　　Operator：操作。表明对What的How操作。也就是Privilege+Resource 　　Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系. 　　Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。　　RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。　　凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。　　Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session. 　　在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。　　这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。　　Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。　　Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。　　引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。