09权限控制

第九章 权限控制 本课教学内容 简介 权限控制 软件开发中，对用户权限进行控制，应用已经越来越广泛，在某些系统中，科学的权限控制方法，保证了资源访问的安全性，成为系统安全性的重要保障。因此，对于程序员来说，权限控制怎样开发，显得非常重要。 本章首先对权限控制进行了概述，阐述了权限控制的基本概念和基本思想；接下来阐述了常见的一些权限控制方法，如用户名/口令方法、智能卡认证方法、动态口令方法等等。并对这些方法的优缺点进行了阐述。 不过，站在编码的角度来讲，这些方法本身的实现并不重要，我们关心的是怎样在软件开发的过程中较好地控制权限，因此，后面的篇幅讲解了一些有代性的权限控制开发方法，如基于代理模式权限控制的方法、基于AOP的权限控制方法，等等。 本章还对一种较流行的统一权限控制方法：单点登录进行了讲解。 最后，本章讲解了权限控制系统的一些常见管理策略。 9.1 权限控制概述 9.1.1 权限控制分类 权限是一个广泛的概念，有面向资源管理人员的，有面向开发人员的。本章所叙述的权限，主要是指在对某个资源进行某种操作时，对操作者的身份要进行的限制。在一般的系统中，操作者的身份是以用户的形式进行表达的。因此，权限控制，是针对各种非法操作所提出的一种安全保护。 在软件开发的过程中，使不同的用户对资源具有不同的使用权限，是非常重要的一项功能，特别是在某些安全性要求比较高的软件中，为软件加入权限控制功能，可以说成为一个安全性能的重要保障。如数据库管理软件、资源管理软件中，这项功能更为重要。 在权限的概念中，一般说得比较多的有以下几个概念： 用户：对资源的操作者身份； 功能权限：用户能否执行某个功能。比如此用户是否能进行商品查询的功能。功能权限是一类比较基础的权限，赋予的值，不是Y(Yes)就是N(No)，又叫做Y/N权限； 数据权限：在用户具有了某一功能权限的基础上，规定用户可以访问的数据范围。比如，用户能够进行商品查询，也就是说有了查询商品的功能权限，但是他可能只能查询出某一种类型的商品，或者只能查询某一个时段的商品，这些都属于数据权限。 在一些软件中，对于权限控制，还引入了“角色”或者“用户组”等概念，归根结底，其目的是为了将以上三个概念进行更好、更方便的管理；从软件开发者的角度讲，需要通过编程来控制的，就是用户、功能权限、数据权限这三个概念。 9.1.2 用户认证方法 权限控制，首要的是对用户进行认证，即确定：什么样的用户是合法的。只有合法的用户才具有判断其权限的资格，才能被授予访问的权限。用户认证有很多方法，按照认证的形式分，主要有以下几种： 1：用户名/口令。 用户名/口令，是最简单，也是最常用的用户认证方法。大量的系统中都是采用这种方法。该有以下特点： 用户名可以由每个用户自己设定，也可由系统给出； 用户的口令(或者密码)由用户自己设定的，理论上只有用户自己才具有读取和修改权； 对于某一用户名，只要能够正确输入口令，计算机就认为持该用户名的操作者就是合法用户。 该方法最常用，但是也是一种单因素的认证，从安全性上讲，用户名/口令方式一种是不安全的身份认证方式。其不安全性主要体现在： 安全性依赖于口令，许多用户为了防止忘记口令，经常采用很简单的口令(如用自己的生日)或者将口令简单存放(如简单地保存在邮箱或者自己机器的硬盘上)，造成口令容易猜测和泄露； 口令是静态的数据，而大量的口令验证是远程的，在验证过程中要在计算机内存中和网络中传输，容易被攻击者通过各种手段(如木马程序或网络监听程序)截获。 口令保存在数据库中，可能被管理员得知；等等。 2：智能卡认证 智能卡是一种内置集成电路的芯片，由专门的厂商通过专门的设备生产，芯片中存有与用户身份相关的数据。智能卡有如下特点： 是不可复制的硬件，由合法用户随身携带； 如果用户想要进行认证，必须将智能卡插入专用的读卡器，读取其中的信息，再通过一定的手段，以验证用户的身份。 不过，和前面一种方法类似，由于存在于智能卡中的数据是静态的，在验证过程中也可能要在计算机内存中和网络中传输，攻击者也可以通过各种手段(如木马程序或网络监听程序)截获。因此还是存在一定的安全隐患。 3：动态口令技术 动态口令技术采用专门硬件，每次根据一定的密码算法生成不同的密码，显示出来告诉用户，每个密码只能使用一次。用户使用时，将显示的当前密码提交给服务器，当密码传输到服务器端，认证服务器采用相同的算法计算当前的有效密码，判断两个密码是否吻合，即可实现身份认证。由于每次使用的密码动态产生，用户每次使用的密码不相同，即使黑客通过一定手段截获了一次密码，也无法利用这个密码来仿冒合法用户的身份。 不过，如果客户端与服务器端的密码不能保持良好的同步，就可能发生合法用户无法登录的问题。因此，此方法对技术要求较高。 此外，还有基于USB Key的身份认证、生物特征认证技术等等。 对于每一种认证方法，我们没有办法去避免其劣势。当然，站在程序员的角度，我们主要关心的是权限控制怎样去通过编程来实现。 由于大量的应用软件都是基于“用户名/口令”的方法进行验证的，因此，本章后面的内容将基于这种验证方法进行讲解。 9.2 权限控制的开发 9.2.1 开发思想 软件中的权限控制如何开发，运用不同的编程方式，就有不同的实现策略。随着软件的结构越来越复杂，权限控制也要越来越精细。从编程结构上讲，如果要实现细致的权限操作，就必须在每一个方法中检查权限，最常见的结构为： public businessMethod() { //权限判断 //获得用户信息 if (用户拥有此方法的权限) { //该用户执行相关功能 } else { //抛出异常 }} 这种方法，实际上是一种在具体功能前加入权限操作检验的实现方式，能够将权限的粒度控制到具体的业务方法，比较有效，控制能力也比较强大。但是，该方法有很多缺点： 每个功能类都需要相应的权限检验代码； 项目中分布着大量的权限控制代码，程序功能和权限检验混淆在一起，存在紧密的耦合性，扩展修改难度大。 总的来说，从程序员的角度讲，除了安全性之外，权限控制系统的开发应该保证以下几点： 权限控制模块和业务逻辑模块分开，可以单独开发； 可以很方便地对权限控制模块进行修改，具有良好的可维护性；等等。 9.2.2 基于代理模式的权限控制开发 代理模式(Proxy Pattern)是一种常见的软件模式，它的经典定义(GoF给出的定义)是：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。其意义和日常生活中的“代理”类似。代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度。 虽然代理模式可能使得请求的处理速度会变慢，但是能够将代理模块的功能从整个系统中分离出来。 代理模式基本结构如下： 从这里可以看出，代理模式有如下特点： 代理类和工作类实现同样的接口； 客户端和代理类打交道； 代理类如果通过验证，则将请求发给工作类； 客户和代理类打交道，其感觉就好像在调用工作类一样，也就是说，代理类实际上对客户透明。 很明显，代理模式的以上特点，决定了权限控制可以借助代理模式来编写。代理模式怎样实现权限控制呢？很简单，将权限控制的代码写在代理类内就可以了。 举一个例子，某个论坛上有多个功能：如发帖子，发评论(简便起见，只列出这两个功能)，客户端要用这些功能，必须验证一定的权限。传统情况下，我们必须在各个方法中编写权限控制的代码，这样的话，权限控制代码和实际业务代码混合在一起，不好维护。此时我们就可以将权限验证的模块写成代理，代码如09_01.java。 权限控制模块完全独立出来了，并且和实际工作模块降低了耦合性。客户直接和代理类打交道，方法如下： public class P09_01 { public static void main(String[] args) { Forum forum = new ForumProxy(new ForumOpe()); //和调用代理类 forum.writeArticle(); } } 以上代码是伪代码，无法直接运行，但是，读者可以从中看出代理模式的应用，并能够预计其运行结果。 从以上的例子可以看出，在代理模式的实现过程中，将每个功能类实现一个相应的代理类，在代理类中进行权限检查，解耦了程序功能和权限检验。 提示 不过，如果系统足够复杂，可能带来的问题是代理类太多。 很明显，如果将每个用户的权限由Proxy实现转为容器的实现，可以大大简化应用程序的设计，关于这方面的内容，大家可以参考相应文档。 9.2.3 基于AOP的权限控制开发 面向方面编程(Aspect Oriented Programming,AOP)，是目前一种比较流行的技术。这种技术的思想是：通过预编译方式和运行期动态代理，给程序动态统一添加功能的一种技术，但是不需要不修改程序源代码。 AOP并不是OOP(面向对象编程)的替代品，是OOP的延续，也可以说是软件设计模式的延续。 AOP也能为权限控制的开发提供较好的解决，有兴趣的读者可以进行学习。我们将这一部分作为课外作业来进行。 9.3 单点登录 9.3.1 单点登录概述 单点登录（Single Sign-On，SSO）是权限控制开发中的一个创新。单点登录是一种身份认证管理方法。 单点登录在一些包含子系统的项目中具有广泛的应用。例如，在一个成为有机整体的部门中，网站的建设的过程，往往具有如下特点： 由于历史原因，一个网站中往往有多个应用子系统，如办公自动化系统、档案管理系统、财务管理系统等等，它们不是一次性开发完毕，而是在不同的时期开发完成； 各应用系统由于功能侧重、设计方法和开发技术有所不同，比如语言、服务器环境不同等，各自的用户保存在各自的库中，具有自己的独立的用户认证体系；用户在每个应用系统中都有独立的账号； 随着子系统的应用整合，网站的用户可能要使用多个子系统； 在这种情况下，就会造成一些问题： 由于用户在每个应用系统中有独立的账号，进入每一个应用系统前都需要以该应用系统的账号来登录，同一个用户在多个系统中要记多个用户名密码，登录麻烦； 应用系统不同，用户账号可能不同，用户必须同时牢记多套用户名称和用户密码； 一个用户离职或者改变，需要维护所有子系统中他的账号，如变更5个人员，一共6个应用系统，需要重复维护30个人员信息，维护起来不方便；等等。 所以，对于应用系统和用户数目较多的企业，我们需要建立一个统一的登录平台，使用SSO技术可以解决以上这些问题。在单点登录系统中，每个用户只需记录一个用户名密码，登录一个平台后即可实现各应用系统的透明跳转，实行统一的用户信息管理系统。 IBM对SSO有一个形象的解释“单点登录、全网漫游”。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的同一用户，只需要登录一次，再访问其他应用中的受保护资源时，不再需要重新登录验证。 9.3.2 单点登录中账号管理 单点登录的应用场合很多，不过，一般情况下，和C/S应用相比，单点登录在B/S模式下用得比较多。 实现单点登录的第一步，就是子系统中账号的统一管理。 单点登录的目的，是要让用户登录一次，能够访问各个子系统，那么用户登录用的账号和密码就只能有一个，但是在各个子系统中都有自己的账号密码，怎样实现统一呢？方法有以下几种： 1：各个子系统账号同步。 该方法中，对于同一个用户而言，每个子系统账号密码相同。比如用户A需要使用X系统与Y系统，就必须在X系统与Y系统中都创建用户名，并且用户名密码一致，这样，用户A可以用这个用户名，保证一个名字能够登录到两个系统。如图所示： 但是，这种方法的代价是X，Y任一系统中用户A的信息更改，必须同步至另一系统，否则会引起数据的不一致。该方法用户信息同步会增加系统的复杂性，增加管理的成本。一般不采用。 2：统一存储。 该方法中，各个子系统并不存储相应的用户名，所有用户的用户名存储一份，单独存放。如图所示： 该方法不会遇到同步问题，维护方便。但是不太现实，因为每个子系统可能本来就有自己的账号，除非将所有的账号密码进行一次大的清理，否则无法实现统一存储，但是这样带来的代价又比较大。 3：用户映射。 该方法中，保留原有系统中用户的账号，将其和新的账号进行一个映射。实际上操作的过程中，用户首先注册一个单点登录账号，然后针对每个应用系统映射一个该应用系统中原有的账号，并维护这些注册和绑定信息。 用户统一使用新的账号。用新账号登录子系统，在底层还是相当于用原有的账号进行登录。如图所示： 该方法既不破坏原有用户存储，也不存在同步的问题，是一种可行性比较高的方法。 9.3.3 单点登录实现 用户统一管理之后，接下来就是单点登录的实现了。一般情况下，SSO的实现机制不尽相同，大体分为session机制和Cookie机制两大类。 1：session机制。 session服务器端的一种对象，因此，session机制是一种服务器机制，当客户端访问服务器时，服务器为客户端创建一个惟一的 sessionID，来保证该次会话的过程中服务器端为该客户分配的是同一个session。session方法的过程如下： 客户端访问任意一个子系统，服务器端检查session； 如果session中显示“未登录”，则服务器将页面跳转到单点登录页面； 客户在单点登录页面中登录；成功后，服务器端将session置为“已登录”状态，并存储相应信息； 客户访问另一个子系统，服务器检查session，此时session内置为“已登录”状态；服务器从session内取出相应信息到数据库验证，如果成功，则视为登录成功，无需客户输入密码。 由于session的机制，用session方式实现SSO，不能在多个浏览器之间实现单点登录，但只要sessionID被共享，SSO就可以跨域。 一些商用服务器，如WebLogic，通过Session共享认证信息。 2：Cookie机制。 Cookie是服务器存储在客户端的一个文件，存储了的内容主要包括Cookie名、Cookie值、Cookie过期时间、Cookie所在的域等。商用软件中，WebSphere通过Cookie记录认证信息，目前大部分SSO产品采用的是Cookie机制，在Java系列中，目前能够找到的较好的开源单点登录产品CAS也是采用Cookie机制 提示： Central Authentication Service (CAS) 单点登录系统最早由耶鲁大学开发。CAS具有设计理念先进、体系结构合理、配置简单、客户端支持广泛、技术成熟等优点。读者可以在http://www.ja-sig.org/products/cas/去下载或参考相应文档。 Cookie机制的过程如下： 客户端访问任意一个子系统，服务器端读取Cookie； 如果Cookie中无法得到账号密码或者其他登录信息，则服务器将页面跳转到单点登录页面； 客户在单点登录页面中登录；成功后，服务器端将登录信息保存在客户端Cookie； 客户访问另一个子系统，服务器读取Cookie，此时服务器端可以得到相应的登录信息，取出，到数据库验证，如果成功，则视为登录成功，无需客户输入密码。 注意，由于Cookie的不安全性(如可能被禁用等)，这里Cookie可能要进行一定的加密。另外，Cookie中保存了关于域的一些信息，因此用Cookie方式可实现SSO，域名必须相同。 9.4 权限控制的管理 权限控制的管理，主要是指对用户以及其对资源的访问权限进行合理的配置，使其达到如下效果： 可以很方便地对某一用户的某种权限进行读取或修改； 也可以很方便地对一批类似的用户的某种权限进行读取或修改。 权限控制的管理，有以下几种模型： 1：矩阵模型。 这种模型出现于早期的应用之中，将用户和资源设计为矩阵，矩阵中可以为用户对某种资源的权限进行赋值。如下图所示： 这种方法中，授权关系明确，直截了当，存取都很容易。但是不太容易适应变化，也不方便对多个用户进行统一管理。 2：任务模型。 任务，是指业务中的一个逻辑操作，一个流程一般包含一到多个任务。该模型是一种动态的权限控制模型，用户在执行不同任务中被许可的权限可能不一样，可以应用于某些用户权限随着任务不同而不同的系统，使用范围较窄。但是适合于用户权限和环境紧密关联或者需要动态授权的应用系统， 3：角色模型。 该模型中，在系统中设计多种角色，将用户和资源连接起来。用户所对应的角色是否能够对某个资源访问，决定了用户对某个资源是否能够访问。可以对用户统一管理，适应变化。 但是，用户通过角色访问资源，但是对于某些具有单一类型权限的用户，不得不为其创建角色，角色弱化为用户，显得多此一举。 4：综合模型。 该模型综合了矩阵模型和角色模型的优点。首先，以角色为桥梁，将用户和资源连接起来，用户对某个资源是否能够访问，取决于该用户所对应的角色是否能够对某个资源访问。授权既对用户进行，也对角色进行。当然，角色和用户的权限进行重叠，需要有一定的规则进行规定。授权比较方便灵活，不过，计算复杂，运算效率低。 该方法得到了更加广泛的应用，如SQLServer等软件中基本上是基于这种思想进行管理；另外一些系统中提出了群组的概念，以群组为基础，将某一组织或者群体下的用户统一授权，用户对某个资源是否能够访问，取决于该用户所对应的群组是否能够对某个资源访问，实际上也是使用了这种模型。 小结 本章对权限控制进行了阐述。首先讲解了权限控制的概念，然后阐述了权限控制的一些方法，接下来站在软件开发者的角度，讲解了一些常见的权限控制开发方法，最后讲解了权限控制系统的管理。 练习 1：很多情况下，用户口令都是保存在数据库中。而数据库管理员具有较大的操作权限。如何保证数据库中的密码不被管理员窃取? 2：权限管理在数据库产品中表现得比较严密。 (1) Oracle中的权限管理是基于什么方式？ (2) MS SQLServer中的权限管理是基于什么方式？ 3：权限管理有哪些方法？各有什么优缺点？ 4：基于AOP的权限控制系统，目前受到了广泛的重视。查找相关资料，了解关于AOP实现权限控制的原理。 5：SSO是一种流行的统一用户管理方法。 (1) 如果子应用用不同的语言编写，如(一个是JSP，一个是ASP)，SSO还能进行单点登录的配置吗？ (2) 请任选一种服务器，完成一个SSO的配置。 6：有一个员工管理系统，要求： 管理员级别的用户可以删除系统中的其他用户和修改其密码； 普通用户能浏览自己的信息，也可以修改自己的信息； 经理级别的用户，除了具有普通用户的权限之外，还可以浏览该部门的用户； (1) 设计其用户管理模型。 (2) 以“浏览客户服务部门的用户”为例，怎样判断当前用户的操作权限？