CN102130894A - 鉴权和认证方法及系统 - Google Patents

Abstract

本发明公开了鉴权和认证方法及系统，包括：预先配置权限模型和配置文件，其中，权限模型用于定义权限数据存储；以及当客户端调用服务器端的业务方法时，服务器根据权限模型和配置文件进行认证和鉴权处理。通过本发明的技术方案，能够支持细粒度的权限控制，同时能够在服务器端以AOP的方式实现可插拔的权限控制。

Description

鉴权和认证方法及系统

技术领域

本发明涉及通信领域，尤其涉及鉴权和认证方法及系统。

背景技术

操作维护中心(operation maintenance center，简称为OMC)由于采用客户端和服务端架构而导致OMC系统可能受到以下的安全威胁：伪装，一个实体伪装成一个OMC的客户端来进行操作请求；偷听，安全数据被窃听；未授权访问，服务器的资源被客户端未授权的任意访问；丢失或损坏，传递的大批量数据丢失或是损坏；否认，用户否认其进行过某项操作；以及伪造和拒绝服务。此外，攻击可能来自网络内部如不满的职员，也可能来自网络外部如黑客。

在目前的OMC系统中，对于伪装，未授权访问还是不能非常好地进行控制，主要原因是：在OMC中，用户在登录时通过服务器认证得到用户的权限，然后缓存在客户端，如果用户的权限发生了改变，则进行广播通知更新客户端相应的权限。此后，用户鉴权就是在客户端来完成的。此时，如果有人开发出自己的一个客户端，绕过客户端的鉴权，直接发起本来没有权限发起的操作，是完全是可以做到的。

目前OMC的权限模型主要结构是用户组(UserGroup)与分别网元(Domain)(网元可以是无线网络控制器(RNC)、NODEB节点等)用户(User)相关联，然后操作(Operation)与用户组(UserGroup)相关联。

虽然这种模型结构处理起来比较方便，但在有些情景下处理得并不是很好，例如：用户组G管理的Domain中包含RNC1和RNC2，同时针对RNC的操作有OP1和OP2，用户组G中有用户U1和U2，如果用户U1对RNC1的可发起的操作有OP 1和OP2，U2对RNC2的操作只能是OP1。

目前在OMC V3中，权限的基本实现方式是先确定用户组管理的网元，然后确定用户组针对RNC的操作，最后将用户分配到用户组。

在确认一个用户的权限时，先查到用户组，然后确定用户可以发起的操作以及管理的网元类型。这个过程主要在用户登录的时候完成，之后将该用户的信息缓存在客户端，大部分的操作以后仅仅在客户端鉴权。

从上可以看出，现有技术存在以下缺点：细粒度的权限处理的不充分；服务器端没有做相应的安全校验，安全性不够，用户可以不通过运营商提供的客户端而和运营商提供的服务端进行通信，这样就绕过了客户端的安全检验。

因此，需要能够完支持细粒度的权限控制并能够完成服务器端的认证和鉴权的方法和系统。

发明内容

考虑到上述问题而做出本发明。

根据本发明的一个方面，提供了一种鉴权和认证方法，包括：预先配置权限模型和配置文件，其中，权限模型用于定义权限数据存储；以及当客户端调用服务器端的业务方法时，服务器根据权限模型和配置文件进行认证和鉴权处理。

此外，所述认证和鉴权处理包括：客户端发起对服务器端的业务方法的调用请求；服务器端的面向方面的编程切面拦截调用请求；面向方面的编程切面调用认证管理器，以确定是否能够通过认证；在通过认证的情况下，面向方面的编程切面调用授权管理器，以确定是否能够通过授权；以及在通过授权的情况下，服务器允许客户端对业务方法进行调用。

另外，认证管理器中的处理包括：接收认证请求；调用根据配置文件决定的认证管理器的认证方法以及统计认证管理器列表中的每个认证器的返回值来确定是否通过认证。

另外，授权管理器中的处理包括：接收授权请求；调用根据配置文件决定的访问决策管理器的决策方法；以及统计访问决策管理器的列表中的每个访问决策投票器的返回值来确定是否通过授权。

优选地，在一个业务方法可能被多个操作调用的情况下，利用授权管理器中设置的访问决策调用回叫接口来决定用户是否有权调用该业务方法。

优选地，将权限模型配置为：用户与用户组关联，用户组与权限关联，权限与网元和操作关联。

优选地，将权限模型配置为：用户与用户组关联，用户组与权限关联，权限与网元组和操作组关联，网元与网元组关联，以及操作与操作组关联。

优选地，配置文件配置一个安全服务器对象，在安全服务器对象上设置认证方式、授权方式，同时设置各种统计策略、缓存策略、加密策略等。

优选地，配置文件提供了操作和业务方法的映射关系。

根据本发明的另一方面，提供了一种鉴权和认证系统，包括：权限模型配置装置，用于预先配置权限模型，权限模型用于定义权限数据存储；配置文件配置装置，用于预先配置配置文件；客户端，用于调用服务器端的业务方法；以及服务器，用于当客户端调用业务方法时，根据权限模型和配置文件进行认证和鉴权处理。

此外，服务器还包括：调用请求接收装置，用于接收由客户端发起的对服务器端的业务方法的调用请求；服务器端的面向方面的编程切面，拦截调用请求；认证管理器，面向方面的编程切面调用认证管理器，以确定是否能够通过认证；授权管理器，用于在通过认证的情况下，面向方面的编程切面调用授权管理器，以确定是否能够通过授权；以及业务方法返回装置，用于在通过授权的情况下，客户端调用所要求的业务方法。

另外，认证管理器中还包括：认证请求接收装置，用于接收认证请求；调用装置，调用根据配置文件决定的认证管理器的认证方法；以及统计装置，统计认证管理器列表中的每个认证器的返回值来确定是否通过认证。

另外，授权管理器还包括：授权请求接收装置，接收授权请求；调用装置，调用根据配置文件决定的访问决策管理器的决策方法；以及统计装置，统计访问决策管理器的列表中的每个访问决策投票器的返回值来确定是否通过授权。

优选地，在一个业务方法可能被多个操作调用的情况下，利用授权管理器中设置的访问决策调用回叫接口来决定用户是否有权调用该业务方法。

优选地，将权限模型配置为：用户与用户组关联，用户组与权限关联，权限与网元和操作关联。

优选地，将权限模型配置为：用户与用户组关联，用户组与权限关联，权限与网元组和操作组关联，网元与网元组关联，以及操作与操作组关联。

优选地，配置文件配置一个安全服务器对象，在安全服务器对象上设置认证方式、授权方式，同时设置各种统计策略、缓存策略、加密策略等。

优选地，配置文件提供了操作和业务方法的映射关系。

通过本发明的技术方案，能够支持细粒度的权限控制，同时能够在服务器端以AOP的方式实现可插拔的权限控制。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是示出现有技术中的OMC的权限模型的结构的示图；

图2是示出根据本发明的鉴权和认证方法的流程图；

图3是示出根据本发明的鉴权和认证系统的结构框图；

图4是示出根据本发明实施例的OMC的权限模型的结构的示图；

图5是示出根据本发明另一实施例的OMC的权限模型的结构的示图；

图6是示出根据本发明实施例的鉴权和认证方法的具体流程图；

图7是示出根据本发明实施例的认证管理器中的调用过程的示图；以及

图8是示出根据本发明实施例的授权管理器中的调用过程的示图。

具体实施方式

下面将结合附图来详细说明本发明的实施例。

图2是示出根据本发明的鉴权和认证方法的流程图。

参照图2，根据本发明的鉴权和认证方法包括：步骤S202，预先配置权限模型和配置文件，其中，权限模型用于定义权限数据存储；步骤S204，当客户端调用服务器端的业务方法时，服务器根据权限模型和配置文件进行认证和鉴权处理。

图3是示出根据本发明的鉴权和认证系统的结构框图。

参照图3，根据本发明的鉴权和认证系统30包括：权限模型配置装置302，用于预先配置权限模型，权限模型用于定义权限数据存储；配置文件配置装置304，用于预先配置配置文件；客户端306，用于调用服务器端的业务方法；以及服务器308，用于当客户端306调用业务方法时，根据权限模型和配置文件进行认证和鉴权处理。

下面参照图4至图8对本发明的实施例进行具体描述。

本发明主要是以OMC安全为基础的，中心思想就是能够根据建立的安全模型完成较细粒度的安全控制，同时根据建立的安全框架能够完成服务器端的认证和鉴权。

因此，首先需要考虑如何建立细粒度控制的安全模型。

图4是示出根据本发明实施例的OMC的权限模型的结构的示图。

参照图4，将模型配置为：权限分别与用户组、网元和操作相关联，用户与用户组相关联，以及网元与表示用户是否能操作网元的条件相关联。

具体地，图中各类的含义如下：User指的是系统中的用户；UserGroup是指用户组，权限是分配在用户组上的，用户组中的用户拥有该用户组上分配的权限，一个用户组可以包含多个用户，一个用户也可以属于多个用户组；Domain指的是OMC中的网元，如RNC，NODEB等；Operation：代表一个操作；Perminssion：代表一个权限，表示在Domain上的一个Operation形成一个Perminssion；Properties是设置在Domain上的条件，可用于在进行业务操作时进行更细粒度的判断用户是否能操作Domain。

将该模型与现有模型相比，该模型中Domain并没有分配在用户组上，而是和Perminssion关联，Perminssion再和UserGroup关联，同时Perminssion还和Operation关联，这样就能解决上面例举的问题，即，用户组G管理的Domain中包含RNC1和RNC2，同时针对RNC的操作有OP 1和OP2，用户组G中有用户U1和U2，如果用户U1对RNC1的可发起的操作有OP1和OP2，U2对RNC2发起的操作只能是OP 1。

例如，对于这种问题，可以将对RNC 1和RNC2的操作OP1和OP2，组装成4个permission，即：RNC 1和OP 1设为P1，RNC 1和OP2设为P2，RNC2和OP1设为P3，RNC2和OP2设为P4。同时，可以建立用户组G1，将P1和P2权限分配给G1，且G1中包含用户U1，这样U1就具有对RNC1发起的操作OP1和OP2；同理，可以建立用户组G2，将P3设置到用户组G2中，G2中包含用户U2，这样U2对RNC2发起的操作就是OP 1。

图5是示出根据本发明另一实施例的OMC的权限模型的结构的示图。

参照图5，将权限模型配置为：权限分别与用户组、网元组和操作组相关联，用户与用户组相关联，操作与操作组相关联，网元与网元组相关联，以及网元与表示用户是否能操作网元的条件相关联。

具体地，如果考虑界面用户人员使用方便可以在该模型上扩展，设置Role(包含一组操作)和DomainSet(包含一组网元)，在Permission中设置操作组和网元组的关系。该结构实质上只是在图4的基础上将Operation和Domain分组，方便用户在界面上的权限分配，能和图4一样达到细粒度的权限控制的目的。

图6是示出根据本发明实施例的鉴权和认证方法的具体流程图。

在配置完权限模型之后，客户端在调用服务器端的业务方法的时候，安全AOP切面可以使用该权限模型向服务器端要求进行鉴权认证。

服务器的权限控制是以IOC(依赖注入，目的就是解耦对象之间的依赖)和AOP的思想为基础的。光有细粒度的权限处理还是不够的，如上所述，尤其是在C/S(客户端/服务器)系统中，如果仅在客户端做权限校验是存在弊端的。

因此，服务器端的权限方案，应该能够达到以下两个要求：

1)不能为了实现服务器的权限，改变服务器的业务接口，也就是不能将安全需要用到的信息在接口传递。因为如果这样做的话，会使安全和业务混在一起，从而不方便以后的维护，并且其安全没有统一地被管理。因此，为了实现该目的，可以使用AOP的实现，安全本质上就是系统中可以抽出来进行公共处理的一个方面，这刚好符合AOP的使用场景；

2)应该可插拔，也就是说能够方便更换用户的认证方式、更换用户的授权方式、更换用户的加密算法、缓存方式等，因此用IOC的思想来实现最合适不过了。

具体地，参照图6，根据事先配置的配置文件(稍后进行详细描述)确定是否向服务器调用业务方法，调用过程如下：首先，客户端发起请求；接下来，AOP切面拦截该请求；此后，AOP切面在服务器端调用认证管理器组件，如果不能通过就会提示用户认证失败；如果通过认证，则AOP切面就会在服务器端调用授权管理器组件，如果不能通过就会提示用户授权失败；如果通过授权，则调用业务方法得到返回值。

以下参照图7和图8分别描述认证管理器和授权管理器中的调用过程的示图。

参照图7，认证管理器中的调用过程如下：

首先，接收认证请求；

然后，调用AuthenticationManager实现类的认证方法，提供默认实现类ProviderManager；

其中，在ProviderManager  中包含一个集合List<AuthenticationProvider>，在AuthenticationProvider中也包含一个认证authenticate方法，因此，在调用ProviderManager的认证authenti cate时，会委托到该类中的集合List<AuthenticationProvider>的每个AuthenticationProvider的实现类中的方法authenticate，然后统计(可根据需要设置统计策略)该List中的每个AuthenticationProvider的返回值来确定ProviderManager的认证authenticate是否通过。

注意，具体是哪个实现类需要根据配置文件来决定，下文将对配置文件进行详细描述。

参照图8，授权管理器中的调用过程如下：

首先，接收授权请求；

然后，调用AccessDecisionManager实现类的决策decide方法，提供默认实现类BasedDecisionManager；

其中，在BasedDecisionManager中提供了一个实现AccessDecisionVoter的集合，并且AccessDecisionVoter接口定义了decide方法，与上述认证过程类似，AccessDecisionManager的授权也是委托给其包含的List<AccessDecisionVoter>来完成，然后根据List<AccessDecisionVoter>中的每个AccessDecisionVoter返回值，来统计(可根据需要设置统计策略)授权是否通过。

类似地，具体是哪个实现类也需要根据配置文件来决定。

下面详细描述上文提到的配置文件。

一种配置文件就是将以上所有处理组合一起协调工作的方法，其可以配置一个安全服务器对象，在该对象上配置好认证方式、授权方式，同时设置好各种统计策略、缓存策略、加密策略等。

该安全服务器对象最后被提供给安全AOP切面使用，安全AOP切面也配置在配置文件中，该切面描述(支持通配符，正则表达式的描述)了在调用那些业务方法时需要进入到AOP切面中进行安全的处理，然后就会进入图6的流程，这样使得所有的安全控制都集中到AOP切面中，而不用在每个业务方法中调用安全的API。

另外一种配置文件为表明界面操作对应的后台业务方法是哪一个的配置文件，因为用户分配权限时分配的是操作而不是业务方法，所以需要提供一个操作和业务方法映射的配置文件。当用户调用某业务方法时，根据配置文件找到该业务方法对应的操作，然后再根据图1、图4或图5设计的结构，判断用户是否有权执行该操作，从而在安全AOP切面中，判断用户是否有权执行该业务方法。其中，用户的信息在用户登录系统时，已经保存在服务器端。注意，一个业务方法可能被多个操作调用，如果仅仅使用以上方案还有不足，所以在图8的授权管理器中还提供了一个AccessDecisionCallback接口，由用户实现该接口，从而在该特殊情况下来决定用户是否有权调用某业务方法。

如上所述，在本发明的技术方案中，通过建立新的权限模型，使得权限分配更加细粒度，此外还为OMC提供了更加强健的安全性。因此，本发明能够支持细粒度的权限控制，同时能够在服务器端以AOP的方式实现可插拔的权限控制。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种鉴权和认证方法，其特征在于，所述方法包括：

预先配置权限模型和配置文件，其中，所述权限模型用于定义权限数据存储；以及

当客户端调用服务器端的业务方法时，服务器根据所述权限模型和所述配置文件进行认证和鉴权处理。

2.根据权利要求1所述的方法，其特征在于，所述认证和鉴权处理包括：

所述客户端发起对服务器端的所述业务方法的调用请求；

服务器端的面向方面的编程切面拦截所述调用请求；

所述面向方面的编程切面调用认证管理器，以确定是否能够通过认证；

在通过认证的情况下，所述面向方面的编程切面调用授权管理器，以确定是否能够通过授权；以及

在通过授权的情况下，所述服务器允许所述客户端对所述业务方法进行调用。

3.根据权利要求2所述的方法，其特征在于，所述认证管理器中的处理包括：

接收认证请求；

调用根据所述配置文件决定的认证管理器的认证方法，以及

统计所述认证管理器列表中的每个认证器的返回值来确定是否通过认证。

4.根据权利要求2所述的方法，其特征在于，所述授权管理器中的处理包括：

接收授权请求；

调用根据所述配置文件决定的访问决策管理器的决策方法；以及

统计所述访问决策管理器的列表中的每个访问决策投票器的返回值来确定是否通过授权。

5.根据权利要求4所述的方法，其特征在于，在一个业务方法可能被多个操作调用的情况下，利用所述授权管理器中设置的访问决策投票器回叫接口来决定用户是否有权调用该业务方法。

6.根据权利要求1至5中任一项所述的方法，其特征在于，将所述权限模型配置为：用户与用户组关联，所述用户组与权限关联，所述权限与网元和操作关联。

7.根据权利要求1至5中任一项所述的方法，其特征在于，将所述权限模型配置为：用户与用户组关联，所述用户组与权限关联，所述权限与网元组和操作组关联，网元与所述网元组关联，以及操作与所述操作组关联。

8.根据权利要求1至5中任一项所述的方法，其特征在于，所述配置文件配置一个安全服务器对象，在所述安全服务器对象上设置认证方式、授权方式，同时设置各种统计策略、缓存策略、加密策略等。

9.根据权利要求1至5中任一项所述的方法，其特征在于，所述配置文件提供了操作和业务方法的映射关系。

10.一种鉴权和认证系统，其特征在于，所述系统包括：

权限模型配置装置，用于预先配置权限模型，所述权限模型用于定义权限数据存储；

配置文件配置装置，用于预先配置配置文件；

客户端，用于调用服务器端的业务方法；以及

服务器，用于当所述客户端调用所述业务方法时，根据所述权限模型和所述配置文件进行认证和鉴权处理。

11.根据权利要求10所述的系统，其特征在于，所述服务器还包括：

调用请求接收装置，用于接收由所述客户端发起的对服务器端的业务方法的调用请求；

服务器端的面向方面的编程切面，拦截所述调用请求；

认证管理器，所述面向方面的编程切面调用所述认证管理器，以确定是否能够通过认证；

授权管理器，用于在通过认证的情况下，所述面向方面的编程切面调用授权管理器，以确定是否能够通过授权；以及

业务方法返回装置，用于在通过授权的情况下，所述客户端调用所要求的业务方法。

12.根据权利要求11所述的系统，其特征在于，所述认证管理器中还包括：

认证请求接收装置，用于接收认证请求；

调用装置，调用根据所述配置文件决定的认证管理器的认证方法；以及

统计装置，统计所述认证管理器列表中的每个认证器的返回值来确定是否通过认证。

13.根据权利要求11所述的系统，其特征在于，所述授权管理器还包括：

授权请求接收装置，接收授权请求；

调用装置，调用根据所述配置文件决定的访问决策管理器的决策方法；以及

统计装置，统计所述访问决策管理器的列表中的每个访问决策投票器的返回值来确定是否通过授权。

14.根据权利要求13所述的系统，其特征在于，在一个业务方法可能被多个操作调用的情况下，利用所述授权管理器中设置的访问决策投票器回叫接口来决定用户是否有权调用该业务方法。

15.根据权利要求10至14中任一项所述的系统，其特征在于，将所述权限模型配置为：用户与用户组关联，所述用户组与权限关联，所述权限与网元和操作关联。

16.根据权利要求10至14中任一项所述的系统，其特征在于，将所述权限模型配置为：用户与用户组关联，所述用户组与权限关联，所述权限与网元组和操作组关联，网元与所述网元组关联，以及操作与所述操作组关联。

17.根据权利要求10至14中任一项所述的系统，其特征在于，所述配置文件配置一个安全服务器对象，在所述安全服务器对象上设置认证方式、授权方式，同时设置各种统计策略、缓存策略、加密策略等。

18.根据权利要求10至14中任一项所述的系统，其特征在于，所述配置文件提供了操作和业务方法的映射关系。

Images