企业应用的权限系统设计

  各种企业应用开发系统大到企业ERP,小到一张报表,通常都会涉及到权限的问题。
一般理解的系统权限大致包括,登录权限,然后是菜单的权限,功能的权限,数据的权限。
登录权限,判断用户是否有权力登录系统的过程通常称之为认证。菜单、功能、数据等权限都是对某种资源的访问控制,这部分我们通常称之为授权。
这样的话,其实权限系统包含了两大部份:
1、认证;
2、授权;

下面我们再针对这两类详细讨论一下。


一、首先是认证:


  一般系统的认证都是提供一个页面,输入用户名及密码,然后传递到后台,再通过程序以用户名为条件获取到数据库(或某种可持久数据的介质,如:文本文件,内存等)的密码,再比较一下用户输入的密码和从后台获取的密码是否相同,以此依据来判断此用户是不是一个合法用户。


  此种认证的方式通常称之为表单认证,由自己写代码来实现认证过程。另外还有一些其它常见的认证方式,如:


  LDAP认证,有些企业拥有自己的LDAP系统来管理企业的用户及组织,例如AD活动目录。这种场景,和表单认证类似,不同的是传递到后台的用户名及密码后,程序会将其传入LDAP服务器,由其进行认证,并将真假的结果返回回来,系统由此结果再判断用户的合法性。


  单点认证,如:常见的开源SSO项目CAS,此种场景大体思路是这样,之前的登录页面通常是由单点系统提供,单点系统负责认证,认证通过后跳转到业务系统中,并会将用户名返回,业务系统再根据用户名进行相应的授权。在没有认证的情况下,如果访问业务系统,会跳转到单点的登录页面,认没认证过通常是通过存在COOKIES中的票据信息决定。这样如果是多个业务系统,只要没有认证通过都会跳到单点系统认证,只要通过了随便访问哪个业务系统都可以,达到了多系统统一登录认证的目的。但授权必须由每个业务系统自己管理,所以单点只是让用户省心了,不用访问每个系统时都输入一次用户名密码,对于程序来说也没省多少事,每次认证通过后还是要走繁琐的授权过程。这部分顺便讲了讲单点的基本知识。


 当然还有其它一些认证方式,如:

HTTP BASIC authentication headers (一个基于IEFT RFC 的标准)
HTTP Digest authentication headers (一个基于IEFT RFC 的标准)
HTTP X.509 client certificate exchange (一个基于IEFT RFC 的标准)
OpenID authentication
Computer Associates Siteminder
等等

二、授权

扫描二维码关注公众号,回复: 5936606 查看本文章

  上面说过,授权部份包括了一些,菜单权限,功能权限,数据权限等,我们先看看每一个的特点。


  首先是菜单权限,通常的权限系统会对系统菜单进行管理和控制,比如,针对不同的用户配置一些菜单范围,这样,用户在进入系统后,只显示了他所配置的菜单。对于要求不高的权限体系,用菜单控制就够了。


  功能权限,一般就是系统中的一些操作动作,比如,一些增删改查的按钮,或者一些后台的方法,安全目录等等。通常的设计,也是针对用户配置这些按钮,这样在前台页面中就会根据配置显示或隐藏这些按钮。


  数据权限,这部份通常比较复杂一点,基本的要求就是,对于不同用户,一些数据要根据预定的规则显示,不能看到全部的范围,比如,自己只能看到自己编制的单据,某个人只能看到其组织机构的数据,等等。这样就要根据需求做不同的设计,基本有两种思路,一种就是定制一个,比如上面的例子,就是根据组织机构控制数据,只要用户和组织机构做一个配置就可以了。第二种就做一个通用的,比如还是上面的例子,一开始需求是只能看见本组织的数据,但随着系统深化应用,需求变化为,某用户只能看本组织机构,和其下的所有,并且区域是北京的数据,或者再复杂点,销售数据大于一万的,客户为张三、李四的。需求如果一直这样变化,如果是定制的话那开发程序员基本要疯了,一直得改永远没有尽头。通用的设计就这样产生了,大体思路就是做一个可以配置的规则,条件可以自己定义,组织机构,区域,销售量,客户这些都是一些条件属性,再定义一些量值,这样不同的用户就有了相应的规则,查找数据时根据这些规则去过滤,就达到了目的。这部份以后再深入讨论一下,实际的情况还有比这个复杂的,比如,加入许可操作的控制,需求为本组织及以下,区域北京,销售额大于一万,客户为张三、李四,这些数据只能看,不能修改或删除。再来一个,某用户只能查看本组织及以下,区域北京,销售额大于一万,客户为张三、李四的订单数据,但不能看订单的某个字段。我的个神啊。

  以上三种权限就是一般开发中经常会遇到的,这里再说一个问题,就是权限控制的切面,象菜单权限,上面说的是一个通常的做法,没有权限菜单就不显示,可以是全部显示,但进入后会有权限判断,没权限会提示权限不足。其实如果前一种方式,也可以将菜单权限放在数据权限中配置处理,把菜单也当做是一种需控制的数据。功能权限同理,但事后处理通常被认为不友好,用户会提出,没有权限的为什么要让我看见,而且页面显示也不简洁,所以这种就暂不讨论了。


三、安全

  权限系统的一些基本功能上面提了关键的两个功能,认证和授权,从安全角度来讲,这都是可以归类到安全范畴,一些权限系统都定位是安全系统或安全框架,也会加入褚多安全相关的功能,比如,对密码是进行加密、强度限制等,访问session的安全管理功能,等等功能。


  关于权限的一些产品或框架还是不多的,主要原因是权限系统有时会严重依赖业务系统,做到通用性,独立性难度还是比较大的,目前开源里有两个比较有名的安全框架,spring security,apache shiro。但想让其完全满足我们的业务需求必须做适当的修改。

  好,下次我们再聊一下权限具体设计。

猜你喜欢

转载自blog.csdn.net/onemy/article/details/19923969