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