企业应用的权限系统设计

　　各种企业应用开发系统大到企业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
等等

 

二、授权

 

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

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

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

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

 

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

三、安全

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

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

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