网络管理系统中的动态客户端授权

摘要

本申请提供了一种操作电信网络管理系统的方法。该管理系统包括授权服务，该授权服务定义管理系统的每一个用户被准许运行的客户端应用的授权。电信网络包括网络元件(网元)形式的受管理资源，这些受管理资源是授权客户端应用所涉及的、管理系统的目标。该方法包括：进行改变，该改变涉及对一个或更多个授权的改变；产生关于授权改变的非请求通知；以及实时地将非请求通知传播到授权客户端应用。

说明书

技术领域

本发明涉及网络管理系统，例如，用于电信网络的网络管理系统， 更具体地，涉及网络管理系统中对客户端授权改变的处理。

背景技术

大型分布式电信网络(例如，3G或4G网络等)可以包括几千、 甚至数以万计的网络元件(网元)(例如，服务器节点、基站等)。这 些网络元件由数量可能多达100至200个的不同客户端操作员操作， 每一个客户端操作员控制网络的一部分。采用管理系统来管理网络资 源。典型的网络管理系统的示例是爱立信OSS-RC。与很多其他管理系 统一样，爱立信OSS-RC采用了授权系统，下面将对其更多细节进行描 述。

下面描述在管理系统中使用的与本公开有关的一些一般架构概 念和定义。这些概念在多个管理系统中(例如，在OSS-RC中以及其他 (包括稍早前的)系统中)是已知的并被广泛使用。

组件

授权数据库包含针对管理系统和/或针对管理实体、参与者 (player)等的授权相关信息(见下文)。

授权服务提供针对授权数据库的接口，从而处理请求并且向管理 系统的各个组件发送消息。

服务器侧应用包含管理系统的应用的业务逻辑部分(例如，数据 收集和对收集到的数据的评估)。

客户端侧应用包括应用的“表示层”部分，该“表示层”部分例 如包括图形用户界面(GUI)。

应用包括客户端侧应用软件和服务器侧应用软件二者。

受管理实体是网络(例如，有线的、GSM、3G、LTE电信等)的由 管理系统管理的节点、实体或组件。

参与者

安全管理员(SM)管理授权数据库，因此负责管理系统的授权。

操作员是管理系统的用户，该用户可以担负在ISO电信管理网络 模型中定义的故障、配置、计费、性能、安全(FCAPS)职责中的任意 一个或更多个职责。操作员也被称作用户。

配置管理员(CM)是在该特定的情况下具有向/从管理系统安装 (添加或移除)节点的任务的用户。

定义的用户是被添加到管理系统中的那些用户。

活动用户是在管理系统中定义的活动地使用管理系统的资源(例 如，使用GUI)的那些用户。

网络拓扑

图1示出了管理系统的典型网络拓扑。如图所示，网络节点包括 管理服务器10、多个受管理实体16、以及多个客户端侧管理节点20 (在图1中仅示出了两个客户端侧管理节点，但是通常将存在更多个 客户端侧管理节点)。管理服务器10包括具有授权服务13的授权数 据库12以及服务器侧应用14。安全管理员26经由授权服务13与系 统进行交互。每一个管理客户端节点20均包括客户端侧应用22(例 如，一个或更多个GUI)。在每一个管理客户端节点20处，操作员24 与客户端侧应用22进行通信。操作员24包括配置管理员28，配置管 理员28是担负处理节点/网络元件的添加/移除的配置管理员职责(如 在FCAPS模型中定义的)的用户/操作员。服务器侧应用14与受管理 实体16进行通信，并且还与每一个管理客户端节点20上的客户端侧 应用22进行通信。如图所示，授权数据库12和服务器侧应用14通常 驻留在一个管理服务器节点10上(但这不是必需的)，而客户端侧应 用22驻留在不同的管理客户端节点20上。

授权数据库12包含每一个用户能够看见或者对其有一定影响或 控制的网络实体的细节、以及用户可以对这些实体执行的任务或功能 的细节。可以围绕涉及以下数据库元素的授权数据库的抽象映射来描 述这一点。

用户是管理系统的参与者——参见上面的定义的用户。

职责是用户的特定行为的定义。

活动是受管理实体的配置属性，其中，授权数据库拥有针对该配 置属性的条目。

目标是授权的对象，通常但不限于一个或更多个受管理实体。

职责-目标关系是目标或目标集合与职责之间的绑定关系，其中， 职责的功能(活动)的对象是目标。

用户-职责关系是职责或职责集合与用户之间的绑定关系，其中， 用户的工作指派(assignment)是该绑定的职责集合。

职责-活动关系是活动或活动集合与职责之间的绑定关系，其中， 职责的功能是通过这种关系来定义的。

安全管理员(SM)和配置管理员(CM)对授权数据库进行管理。 SM有权管理用户和职责，并且可以通过对职责-活动关系、职责-目标 关系和用户-职责关系进行改变来定义职责和用户。CM仅有权直接或 间接地管理目标数据库，例如通过安装(添加或移除)受管理实体。

其他术语

可见性集合是被授权以在表示层向用户呈现的目标(通常是受管 理实体)的集合。例如，这意味着在GUI中只允许显示授权的目标(受 管理实体)。

客户端的授权信息涵盖对客户端有影响的所有授权设置(活动)。

在包含授权系统的爱立信的OSS-RC管理系统中，授权系统的一 个示例被称作TSS(电信安全服务)。TSS包括包含与OSS-RC及其受 管理实体有关的所有授权信息的数据库。OSS-RC的组件向TSS发送授 权请求。典型的授权请求包含希望执行活动的用户的ID、活动的名称 和活动的对象。为了实现有保证的授权(强授权)，应用的服务器侧 (业务逻辑)实施授权检查。然而，诸如GUI等的客户端侧应用也可 以执行一些授权功能。

与一些已知的授权系统有关的一个问题是直到客户端下一次执 行启动时或者直到定期的配置更新请求时才在客户端处更新任何授权 改变。这意味着在做出改变的时间与请求配置更新的时间之间可能存 在客户端应用基于过期授权运行的时间间隔。客户端操作员还可能被 上面的行为误导，并做出错误的决策。另一个问题是，对于管理系统 而言，仅在负责已经改变的特定网络资源(或元件)的客户端处操作 的应用中更新任何授权改变才是恰当的。然而，广播授权更新的任何 系统将向包括不需要接收该信息的客户端的更多客户端提供该信息， 从而导致大量不必要的网络业务、不必要的服务器处理消耗，并且具 有可能不利的安全影响。

本发明是在考虑到上述问题的情况下做出的。

发明内容

根据第一方案，提供了一种操作电信网络管理系统的方法。所述 管理系统包括授权服务，所述授权服务定义所述管理系统的每一个用 户被准许运行的客户端应用的授权。所述电信网络包括网络元件形式 的受管理资源，所述受管理资源是授权客户端应用所涉及的、所述管 理系统的目标。所述方法包括：进行改变，所述改变涉及对一个或更 多个授权的改变；产生关于所述授权改变的非请求通知；以及实时地 将所述非请求通知传播到所述授权客户端应用。

优点在于，所述系统通过发送非请求通知来向应用通知授权改 变，这意味着，它不等待接收针对更新的授权信息的请求，而是直接 产生通知，并实时地(即，无延迟地)传播通知。

根据第二方案，提供了一种电信网络管理系统中的授权服务器。 所述授权服务器被配置为访问授权数据库中的数据，所述授权数据库 定义所述管理系统的每一个用户被准许运行的客户端应用的授权。所 述电信网络包括网络元件形式的受管理资源，所述受管理资源是授权 客户端应用所涉及的、所述管理系统的目标。所述授权服务器被进一 步配置为检测改变，所述改变涉及对一个或更多个授权的改变，产生 关于所述授权改变的非请求通知，以及将所述非请求通知传播到所述 授权客户端应用。

根据第三方案，提供了一种电信网络管理系统中的客户端侧服务 器。所述服务器包括一个或更多个客户端应用，每一个应用被授权与 网络元件形式的受管理资源相关联地运行，所述受管理资源是依照所 述管理系统中定义的一个或更多个授权的、所述管理系统的目标。所 述客户端侧服务器被配置为接收指示与在所述服务器中运行的客户端 侧应用相关联的授权的改变的非请求授权更新通知，并且在所述应用 正在运行的同时在所述客户端侧应用中执行所述授权改变。

根据第四方案，提供了一种电信网络管理系统。所述系统包括： 至少一个客户端侧服务器，包括能够由所述管理系统的用户运行的一 个或更多个客户端应用。授权服务定义所述管理系统的每一个用户被 准许运行的客户端应用的授权。所述电信网络包括网络元件形式的受 管理资源，所述受管理资源是所述授权客户端应用所涉及的、所述管 理系统的目标。所述授权服务器被进一步配置为：检测改变，所述改 变涉及对一个或更多个授权的改变，产生关于所述授权改变的非请求 通知，以及向所述授权客户端应用发送所述非请求通知。

附图说明

图1是网络管理系统的拓扑的示意图。

图2A和图2B是示出了可能导致授权改变的两种使用情况的流程 图。

图3是示出了管理系统处理授权改变的更新的过程的流程图。

图4至图10是可能导致授权改变的其他使用情况的流程图。

图11是示出了用于在运行的应用中更新授权改变的过程的流程 图。

图12是示出了当用户启动应用时的过程的流程图。

具体实施方式

下面描述的实施例涉及操作包括授权服务的电信网络管理系统 的方法以及用于执行该方法的系统/网络服务器实体。围绕多个功能考 虑这些实施例，这些功能可以被分类到不同的场景中，在这些场景中， 参与者执行特定任务。在下面的讨论中，这些场景已经被分组为描述 典型的用户相关配置步骤的多个使用情况。此外，给出了根据本发明 的实施例的管理应用的一般化行为。关于图2至图12的流程图示出并 描述了这些行为。

注意，可以在网络的不同节点中执行流程图的元素(即，每一个 框中指示的步骤)。流程图仅考虑功能而未考虑与网络拓扑的关系或者 网络拓扑的映射。因此，所描述的过程不限于在网络的任何特定的部 分或节点上执行。

图2A示出了配置管理员(CM)想要向系统安装新的受管理实体 (目标)的情况。在步骤201，CM向系统添加新的目标。通常，CM将 使用用于该受管理实体的安装向导。因此，在步骤202，将通过将新 的受管理实体作为目标进行插入来更新已经安装的受管理实体的数据 库。在该情况下，节点仅被添加到数据库中，但是还没有任何人被授 权或者有权访问它(这将仅在已经执行另一个活动以后才发生，如下 所述并且如图2B中所示)。因此，过程在步骤203处结束。

图2B示出了安全管理员(SM)想要配置特定职责的授权设置的 情况。职责是用户行为的定义，因此束缚于特定用户，因而用户的授 权设置也将改变。改变是向职责-目标关系添加目标或者从职责-目标 关系中移除目标。在步骤204，SM改变职责-目标关系。通常，SM将 使用配置向导来改变职责-目标关系。在步骤205，在授权数据库中更 新改变(更新职责-目标关系)。然后，该过程继续到步骤“1”206和 图3的过程。

图3示出了系统如何处理授权改变的更新。作为已经由SM或CM 发起的改变(例如，上文参照图2B所描述的职责-目标关系的改变) 的结果，过程在步骤“1”303处开始。在步骤304，授权服务识别职 责-目标关系是否对管理系统中定义的任何用户的授权设置有任何影 响。如果没有用户受到改变的影响，则过程在步骤305处结束。否则， 该过程继续到步骤306，步骤306是系统相关检查点。授权服务确定 在管理系统中是否存在具有与活动用户有关的信息的组件。如果管理 系统不具有与活动用户有关的信息，则在步骤307，系统向所有应用 通知授权改变。这涉及系统向所有运行的应用通知针对所有用户的所 有授权改变。然后，该过程在步骤308处结束。

如果管理系统拥有与活动用户有关的最新信息，则在步骤309， 系统计算并检查识别的授权改变中的任意一个是否是涉及活动用户的 活动应用的改变。如果不是，则过程在步骤310处结束。如果存在受 改变影响的活动应用，则在步骤311，授权服务向活动用户的每一个 活动应用通知特定用户的授权改变。然后，过程在步骤312处结束。

注意，当系统向应用通知授权改变(步骤307和311)时，它是 通过发送非请求通知来完成这一点的。也即是说，它不等待接收针对 更新的授权信息的请求，而是直接产生通知，并实时地(即，无延迟 地)传播通知。因此，如本文所使用的，表达“非请求通知”用于与 对请求或询问的响应区分开，术语“传播”用于指示无延迟地发送或 推送出通知。

图4示出了当配置管理员(CM)从系统中移除受管理实体时的过 程。在步骤401，CM通常使用移除向导来移除目标受管理实体。因此， 在步骤402，通过将选择的受管理实体作为目标进行移除来更新已经 安装的受管理实体的数据库。这种受管理实体的移除要求还移除授权 数据库中绑定于移除的目标的所有职责-目标关系，如步骤403所示。 在步骤404，该过程然后继续到步骤“1”(图3)。

图5示出了安全管理员(SM)向系统添加新职责的过程。在步骤 501，SM通常使用用于新的职责的添加向导来添加该新职责。因此， 在步骤502，使用新的职责来扩展授权数据库。此外，该活动仅涉及 在数据库中定义职责，而不涉及任何授权，授权将通过如图2B所示的 更新职责-目标关系来处理，因此过程在步骤503处结束。

图6示出了当安全管理员(SM)移除现有职责时的过程。在步骤 601，SM通常使用移除向导从系统中移除职责。因此，在步骤602，从 授权数据库中移除职责。这种职责的移除要求如步骤603处所示地还 移除授权数据库中绑定于移除的职责的所有用户-职责关系。这种职责 的移除还要求如步骤604所示地还移除授权数据库中绑定于移除的职 责的所有职责-目标关系。然后，该过程继续到步骤“1”(图3)。

图7示出了安全管理员(SM)(例如，通过改变职责-活动关系) 改变职责的功能的过程。在步骤701，SM在职责的功能改变时通常使 用职责改变向导来重新定义职责。因此，如步骤702所示，在授权数 据库中更新职责。然后，该过程继续到步骤“1”(图3)。

图8示出了安全管理员(SM)向管理系统定义新的用户的过程。 在步骤801，SM通常使用添加用户向导来添加新的用户。因此，如步 骤802所示，将用户添加到授权数据库。因为SM仅定义用户而不向他 /她指派任何授权，因此过程在步骤803处结束。稍后，将参照图10 来描述授权指派。

图9示出了安全管理员(SM)从管理系统中移除定义的用户的过 程。在步骤901，SM通常使用移除用户向导来移除现有用户。因此， 如步骤902所示，从授权数据库中移除用户。这种用户的移除要求如 步骤903所示地还移除授权数据库中绑定于移除的用户的所有用户- 职责关系。在步骤904，过程然后继续到步骤“1”(图3)。

图10示出了安全管理员(SM)使用新的用户-职责关系来扩展授 权数据库的过程。在步骤1001，SM通常使用用户-职责创建向导来添 加新的用户-职责关系。因此，如步骤1002所示，将用户-职责关系添 加到授权数据库。在步骤1003，过程然后继续到步骤“1”(图3)。

图11示出了运行的客户端应用如何处理来自授权服务的、与授 权改变有关的输入信息。该流程图针对系统向应用通知授权改变的那 些情形、从图3的流程图(图3的步骤307和311)继续。该过程在 步骤1101处开始，然后，在步骤1102，应用从授权服务接收与授权 设置的改变有关的信息。在步骤1103，应用确定是否存在影响应用的 用户/操作员的可见性集合的任何授权改变。如果不存在此类改变，则 过程在步骤1106继续。如果存在任何此类改变，则在步骤1104，针 对这些用户，记录改变。在步骤1105，根据授权改变来更新用户的可 见性集合，使得在应用的表示层中反映改变。例如，这意味着已经添 加的目标(受管理实体)在用户的GUI中变得可见或者已经移除的目 标(受授权实体)变得不再可见。该过程然后在步骤1106继续。

在步骤1106，进一步确定从授权服务接收的授权改变是否对用户 的客户端授权信息有任何影响。如果答案为否，则过程在步骤1109 处结束。如果答案为是，则在步骤1107，针对这些用户，记录改变。 此外，在步骤1108，在应用的表示层中反映客户端处的授权改变。然 后，该过程在步骤1109处结束。注意，在步骤1103和1106处进行确 定以及执行后续任务(步骤1104/5和1107/8)的顺序是无关紧要的 ——即，可以交换顺序。此外，在一些实施例中，只能作出这些确定 中的一个确定并且只能执行后续任务中的一个后续任务。

图12示出了当用户/操作员启动应用时的过程。因为授权改变可 能已经在应用不是活动的时发生，因此当下一次启动应用时，将需要 更新该应用。该过程在步骤1201处开始。在步骤1202，由用户/操作 员开始执行应用。在步骤1203，应用然后询问启动应用的用户的当前 授权集合。然后，在步骤1204，应用等待授权服务通过发送授权应答 进行响应。授权应答包含针对特定用户的客户端的更新的授权信息和 可见性集合。在步骤1205至1207，在接收到可见性集合和授权信息 以后，应用记录并设置可见性集合和授权信息(如图11中的步骤1104、 1105、1107和1108所示)。

图12的框1210示出了授权服务处的询问过程。在步骤1212，授 权服务接收在步骤1203由最近启动的应用发送的请求。授权服务建立 针对特定用户的客户端的可见性集合和授权信息，并且在步骤1213， 通过向客户端应用发送回授权应答来进行响应。

从授权服务向客户端应用——GUI(或者整个表示层)——发送 的授权改变信息可以使用通知逻辑，例如3PPNotification中的通知 逻辑，如“Notification Service Specification，Version1.1An  Available Specification of the Object Management Group，Inc.” (参见http：//www.omg.org/spec/NOT/1.1/PDF)中所描述的。这可 以用于非请求通知和如参照图12所描述的响应于GUI(或者表示层) 在启动时向授权服务进行询问而发送的通知。此外，GUI(或者表示层 的其他子组件)可以持续地/定期地询问授权服务，然后，如果已经存 在授权改变，则授权服务进行响应，该响应触发如图11中所示的过程。 另一个选择是基于用户交互(或者其他异步触发)——例如，如果用 户点击鼠标的右键来产生客户端应用询问。

对于非请求通知，使用实时通知机制，该实时通知机制无延迟地 传播授权信息，并且比通过人机互动触发的询问或轮询机制更有效。 在一种情形中，实时通知机制无延迟地并且在对客户端处的表示层中 的活动用户没有任何初步了解的情况下传播授权信息。在该选择中， 授权信息被发送到所有运行的应用，如图3中的步骤307所示。否则， 实时通知机制无延迟地但是在对客户端应用的活动用户有初步了解的 情况下传播授权信息，如图3中的步骤311所示。

上面描述的过程和功能向用户/操作员提供了大量有利的特征。 例如，可以迅速地(无延迟地)向客户端侧应用发送SM(通过授权数 据库)对客户端侧应用的授权设置进行的改变。目标的授权改变可以 传播到表示层以动态地更新其授权。

另一个有利的特征是，当CM将受管理实体安装到网络中时，除 非操作员被授权查看受管理实体，否则受管理实体将不会向操作员显 现(例如，节点在GUI中将不可见)。此外，如果操作员被授权查看受 管理实体，则受管理实体将迅速地显现。

另一个有利的特征是，SM可以(通过改变职责-目标关系、通过 重新定义职责、通过移除职责、通过移除使用、通过移除用户-职责关 系、或者通过添加用户-职责关系)为不同的操作员设置授权设置，并 且设置将被迅速地传播。因此，SM可以定制哪一个操作员能够看见特 定的受管理实体、以及操作员能够对受管理实体执行哪些功能。

另一个有利特征是，当且仅当CM定义受管理实体并且SM向操作 员授权受管理实体时，受管理实体才向操作员显现(例如，将在GUI 中可见)。当满足这两个条件时，受管理实体迅速地、无延迟地向操作 员显现。

另一个有利特征是，如果CM未定义受管理实体或者SM撤销操作 员的访问授权，则受管理实体从操作员的应用中消失(例如，受管理 实体将在GUI中不可见)。受管理实体再次迅速地、无延迟地从操作员 的应用中消失。

另一个优点是，可以在客户端侧或者在客户端侧应用的表示层中 记录任何授权改变事件。

另一个有利特征是，可以对大型网络进行分割，使得可以将其模 拟为针对不同操作员或操作员组的几个较小的虚拟管理系统。通过这 种方式，还可以基于物理或拓扑或技术区域来创建客户端分离的域。