先由一个Administrators组 （Group）拥有一个根权限“/kasai/”，享有根权限。在权限的分配上，Group、Role以及User都拥有一个自身的根节点：“ /kasai/group/”、“/kasai/role/”和“/kasai/user/”，新加的group、role或者user都将在此节点之下 进行扩充。由于用户的权限是在“/kasai/user/”节点之下进行扩充，因此也就注定了通常情况下创建的用户是无法获得对用户的操作权限（如：新建 用户）的。为了解决这个问题，Kasai的开发团队在开发Kasai系统时，引入了一个Super User的概念，对kasai_users表进行扩充，增加了一个标识字段用来表示一个超级用户，对于超级用户，系统不再进行繁琐的权限判断，直接允许进 行所有全部操作。
Kasai对用户密码使用一套开源加密算法————Jasypt加密算法，这个Java类包为开发人员提供一种简单的方式来为项目增加加密功能， 包括：密码Digest认证，文本和对象加密，集成hibernate，Spring Security(Acegi)来增强密码管理。Jasypt遵循RSA标准提供单向和双向的加密技术 ，对用户的密码更安全的保护，二进制加密支持，Jasypt可以根据需要加密对象或文件 、数字加密支持，除了text和binaries，Jasypt也可以分类和数字值的加密（BigInteger，BigDecimal或其他类型） ，支持Hibernate持久化加密 ，安全的线程 ，提供非配置的加密工具和灵活的配置 ，在Hibernate映射文件中定义域的加密 ，无缝的与Spring应用程序集成，Spring安全（Acegi Security）选项集成适合执行密码加密和匹配任务，通过使用安全的密码加密机制和提供更高程度的配置和控制，从而提高了用户密码的安全性，比较有意 思的是对于相同的“明文”，在通过Jasypt加密后的“密文”值却是不同的，因此怀疑“密钥”应该就在密文本身，而且此所用的加密算法应该是“可逆加密 算法”。
其实，角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。
Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给 User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。 例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。
对Kasai来说，这个many-to-many的关系是由3张表（kasai_users, kasai_roles, kasai_objects）来完成的。为了构建many-to-many的关系，Kasai增加了一张关系表 kasai_objects_users_roles。同时，所有的资源都是由role来管理，这样，用户、角色和资源之间就构成了一种权限关系。
基于角色的访问控制方法（RBAC）的显著的两大特征是：
1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。
2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
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都是基于关系模型。
事实上Kasai的开发团队在开发过程中开发了多种认证机制（基于AS/400 server的认证、基于关系数据库的认证、基于Unix的认证方式以及基于Win32的认证方式），但是从发布产品的情况来看，除了对基于关系数据库的 认证方式实现的比较彻底，其他几种方式却依然是犹抱琵琶半遮面。不过没关系，对于普通的应用，提供关系数据库认证方式的支持就已经足够了。
在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。
Role 作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或 Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于 新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。
因此，从这个角度来看，对于Kasai系统的使用，首先需要理清现有系统中对于部门、角色、用户之间的权限关系，同时分清当前应用系统中的角色用 户的概念与RBAC概念中对于角色、权限、用户概念的异同。对于现有系统来说，如果需要使用RBAC系统，我们可以暂时先抛开对这些概念性的纠缠。对于 WEB应用来说，首先是对应用系统中将要使用的“权限管理粒度”做深入的分析。其次，在“权限粒度”的把握下，对系统资源（如：链接、按钮、图片。。。等 等）进行整理，根据整理出的资源进行归类，对于系统共有的资源，如果系统暂时无法保证将来是否会依然是共有资源的，可以将其归属于某一个特定的角色，而对 于大多数公有资源，可以不用考虑进行权限限制。最后，根据现有应用系统中各个角色和用户的日常权限对资源进行归类，并将相应的资源纳入相应角色之中。
参考资料：
http://sourceforge.net/projects/soap-rbac
http://sourceforge.net/projects/rolemanager
http://tech.ddvip.com/2008-01/120138480041599.html
http://www.phpchina.com/html/73/5173_itemid_10049.html
http://java.ccidnet.com/art/3539/20080123/1350845_1.html
http://java.e800.com.cn/articles/2007/413/1176400843016628730_1.html
先由一个Administrators组 （Group）拥有一个根权限“/kasai/”，享有根权限。在权限的分配上，Group、Role以及User都拥有一个自身的根节点：“ /kasai/group/”、“/kasai/role/”和“/kasai/user/”，新加的group、role或者user都将在此节点之下 进行扩充。由于用户的权限是在“/kasai/user/”节点之下进行扩充，因此也就注定了通常情况下创建的用户是无法获得对用户的操作权限（如：新建 用户）的。为了解决这个问题，Kasai的开发团队在开发Kasai系统时，引入了一个Super User的概念，对kasai_users表进行扩充，增加了一个标识字段用来表示一个超级用户，对于超级用户，系统不再进行繁琐的权限判断，直接允许进 行所有全部操作。Kasai对用户密码使用一套开源加密算法————Jasypt加密算法，这个Java类包为开发人员提供一种简单的方式来为项目增加加密功能， 包括：密码Digest认证，文本和对象加密，集成hibernate，Spring Security(Acegi)来增强密码管理。Jasypt遵循RSA标准提供单向和双向的加密技术 ，对用户的密码更安全的保护，二进制加密支持，Jasypt可以根据需要加密对象或文件 、数字加密支持，除了text和binaries，Jasypt也可以分类和数字值的加密（BigInteger，BigDecimal或其他类型） ，支持Hibernate持久化加密 ，安全的线程 ，提供非配置的加密工具和灵活的配置 ，在Hibernate映射文件中定义域的加密 ，无缝的与Spring应用程序集成，Spring安全（Acegi Security）选项集成适合执行密码加密和匹配任务，通过使用安全的密码加密机制和提供更高程度的配置和控制，从而提高了用户密码的安全性，比较有意 思的是对于相同的“明文”，在通过Jasypt加密后的“密文”值却是不同的，因此怀疑“密钥”应该就在密文本身，而且此所用的加密算法应该是“可逆加密 算法”。
其实，角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。
Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给 User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。 例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。
对Kasai来说，这个many-to-many的关系是由3张表（kasai_users, kasai_roles, kasai_objects）来完成的。为了构建many-to-many的关系，Kasai增加了一张关系表 kasai_objects_users_roles。同时，所有的资源都是由role来管理，这样，用户、角色和资源之间就构成了一种权限关系。
基于角色的访问控制方法（RBAC）的显著的两大特征是：
1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。
2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
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都是基于关系模型。
事实上Kasai的开发团队在开发过程中开发了多种认证机制（基于AS/400 server的认证、基于关系数据库的认证、基于Unix的认证方式以及基于Win32的认证方式），但是从发布产品的情况来看，除了对基于关系数据库的 认证方式实现的比较彻底，其他几种方式却依然是犹抱琵琶半遮面。不过没关系，对于普通的应用，提供关系数据库认证方式的支持就已经足够了。
在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。
Role 作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或 Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于 新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。
因此，从这个角度来看，对于Kasai系统的使用，首先需要理清现有系统中对于部门、角色、用户之间的权限关系，同时分清当前应用系统中的角色用 户的概念与RBAC概念中对于角色、权限、用户概念的异同。对于现有系统来说，如果需要使用RBAC系统，我们可以暂时先抛开对这些概念性的纠缠。对于 WEB应用来说，首先是对应用系统中将要使用的“权限管理粒度”做深入的分析。其次，在“权限粒度”的把握下，对系统资源（如：链接、按钮、图片。。。等 等）进行整理，根据整理出的资源进行归类，对于系统共有的资源，如果系统暂时无法保证将来是否会依然是共有资源的，可以将其归属于某一个特定的角色，而对 于大多数公有资源，可以不用考虑进行权限限制。最后，根据现有应用系统中各个角色和用户的日常权限对资源进行归类，并将相应的资源纳入相应角色之中。
参考资料：
http://sourceforge.net/projects/soap-rbac
http://sourceforge.net/projects/rolemanager
http://tech.ddvip.com/2008-01/120138480041599.html
http://www.phpchina.com/html/73/5173_itemid_10049.html
http://java.ccidnet.com/art/3539/20080123/1350845_1.html
http://java.e800.com.cn/articles/2007/413/1176400843016628730_1.html
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。