我认为，本身你所提出的思路就存在概念上的不合理。
我们所说的登陆啊之类之类，归结为一个安全概念，那就是访问控制。
访问控制需要有两个必备：1、系统必须明确知道用户是谁。2、系统必须明确知道，访问这个资源的用户是否有权利。
第一个，大家很容易理解，我们经常使用“用户名”+“密码”的方式来让系统获知用户是谁。因为密码是隐私数据，我们仅认为合法用户才持有。因此，当一个用户提供了用户名和正确的密码，系统就可以认为是用系统的用户是谁。这个过程叫验证用户。
第二个，系统知道用户是谁，还必须知道用户是否有访问某个资源的权利。这个过程叫授权。一个验证、一个授权，前者是证明用户是谁，后者是决定一个资源是否允许被用户访问。
角色、组等概念并非访问控制所必须的。因为你可以在一个资源上添加“访问控制列表”，在该表中明确指定每一个用户是否有权访问它的记录，当一个用户要访问时，通过查表以决定是否允许。但这样会造成“访问控制列表”过于庞大，当用户成千上万时，它的伸缩性、性能非常低下。并且，为每个资源维护用户的访问表，其维护量基本上等于用户数和资源数的乘积，相当庞大。
于是，思考是否引入一个中间环节，将用户和资源对应关系进行缓冲。这就是角色、或者组。随你怎么说，只要在一个项目中，这些概念的含义相同就行。我们对资源的授权并不针对用户，而是针对角色或者组。
我认为，用角色的概念更贴近现实生活。首先、一个人有可能担当多种角色：例如，一个老师，对于学生，他是老师的角色，对于学校，他是工作者的角色，对于家庭，他是父亲/母亲的角色，对于银行，他是业务办理者的角色。其次，一个角色可能有很多人在扮演，全世界不止一个教师，银行也不乏仅他一个业务办理者。
因此角色和用户是N对N的关系。
当然，用“组”这个概念同样可以，随你怎么说，这取决于你的设计。
所以，对于你的设计而言，违背了最初设计原则。如楼主所说偷工减料吧，这样付出的代价就是违背设计原则，导致信息不全。在我的基于角色的安全访问中，任何元素都是必须的，没有冗余。
高阶技巧：
美国国家标准协会倡导了RBAC（基于角色的访问控制Role-based Access Control）。他还指定了RBAC的三种标准，分别是RBAC0、RBAC1、RBAC2。其中RBAC0是最基本的角色访问控制标准。如同我所有帖子一样，他们都是RBAC0的，用户和角色这两个元素都是没有层次结构的（属于平面数据）。更复杂RBAC系统，用户和角色的组织形式是树状结构的，并且，对于访问控制元来说，还可区分“允许”“拒绝”“未指定”，对控制策略来说，可以分为“拒绝优先法”等等，对于用户和角色呈现的树状结构，还存在追溯权限和继承关系，权限怎么追溯、怎么继承、怎么叠加等，都是设计访问控制需要考虑的问题，还有就是这些追溯、继承算法是否满足性能要求。
2008-11-25 19:25
