bob沙巴体育:融云 企业通讯录的设计与实现

来源:bob沙巴体育登录 作者:bob沙巴体育首页

发布时间:2022-09-04 15:51:24

  企业通讯录作为企业统一通信中其它业务功能的触发点,需要灵活、完备的功能和好用、便捷的人机界面,以便用户顺利完成业务协作,真正为企业运转提速,实现降本增效。

  之前,我们已分享过【在“企业通讯录”的盲区,融云的边界与分寸】和【云办公时代,企业通讯录的技术选型】。本文将阐述企业级通讯录的设计与实现。

  2. 支持视图显示。支持管理员在管理后台对部门、员工信息以及组织架构进行查看和更改。

  4. 支持细粒度访问权限控制。对不同员工设置不同的访问权限,企业管理人员拥有所有操作权限。

  5. 支持通讯录信息实时同步。员工或部门信息甚至企业架构发生变化时,需要及时通知受影响的客户端进行通讯录信息的同步。

  6. 支持点击好友触发语音会议、即时消息、视频会议、企业直播等通讯业务。

  7. 提供统一认证服务。用户只需登录一次,在一段时间内可以使用企业提供的其它服务。

  其中,通讯录信息实时同步、细粒度访问权限控制以及统一认证服务是核心功能。

  通讯录信息实时同步保证了用户本地通讯录与服务端通讯录的一致性;细粒度访问权限控制保证了用户能够获得正确的通讯录信息;统一认证服务保证了企业合法用户无需重复认证即可使用系统授权服务。

  基于企业通讯录功能需求,通讯录服务器架构设计如图 1,将通讯录架构层分为应用层、接口接入层、统一认证层、服务层和数据库接入层,各模块之间的通信采用消息总线的方式,即模块之间不会直接发送消息而是将消息发送到消息队列中,采用这种通信方式可以降低模块之间的耦合度,便于系统模块的扩展和维护。

  如图 2 企业通讯录服务功能模块结构图所示,客户端通过 HTTP 协议调用服务端提供的 Webservice 接口服务。

  Web 端服务主要是管理类的,包含角色管理、权限管理、通讯录管理、日志管理、企业管理以及系统管理等。

  移动终端的首次登录需要获取自己对应角色的通讯录,如果服务端通讯录信息发生变化,本地终端的通讯录需要同步更新,由通讯录同步模块实现。

  基础服务包括统一认证和安全模块,统一认证包括身份认证、单点登录;安全模块确保通讯录服务的数据传输安全可靠。

  单点登录是指当用户请求通讯录服务时,服务端需要对请求用户的合法性进行验证,合法用户系统会提供通讯录服务,否则返回无权访问提示。用户在服务请求中会涉及到如图 3 所示认证过程。

  ② 通讯录服务收到请求消息,会调用验证模块验证用户的合法性,即判断用户是否己登录,已登录执行步骤 ⑤,未登录执行步骤 ③

  为增加企业通讯录信息传输的安全性,客户端与服务端之间的数据传输本文采用SSL/TLS加密,对存储在数据库中的数据进行加密存储,以防泄露。

  通讯录服务需要对企业通信业务提供相对应的接口支持,还要辅助其它业务获得通信的相关信息。如图 4 所示,企业通讯录服务提供了广泛的接口支持企业通信业务和其它业务。

  位于服务端和 IM 或语音视频之类的通讯业务之间,使通讯业务能够从通讯录服务中查找到企业或个人的相关信息以便进行通信。

  位于通讯录服务和权限验证模块之间,客户端或者其他实体业务对通讯录服务的消息请求需要得到验证,合法用户才能使用通讯录业务,该接口用于提供身份验证服务。

  通讯录服务和用户状态呈现之间的接口,通讯录可以通过此接口获得用户的状态信息。

  通讯录信息存放在 LDAP 数据库中,通讯录的各数据元描述具体见表 1。

  上表所示的属性是系统默认的属性,管理员在进行员工信息操作时可根据需求进行属性的添加或删除。

  本文中的企业通讯录的数据是采用 LDAP 协议描述的,它将数据库中的数据抽象为树形结构,用户只需对这棵树的节点进行操作即可,降低了数据 操作的复杂性,真实的数据被存放到了一个关系型数据库中,本文采用的是 MySQL。

  除此之外,LDAP 提供了丰富的语言接口,有利于不同终端对LDAP 的操作。Schema (模式)是 LDAP 的 一 项重要内容,它定义了数据的存储格式。

  比如定义一个节点有哪些属性。本文采用的 openLDAP 中包含一些标准的 Schema, 在 openLDAP 的 Schema 文件夹下,用户也可以根据自己的需要来进行扩展,只需要在 Schema 文件夹下新建一个 Schema 文件来进行定义即可。

  企业通讯录是由企业所有员工组成的联系人列表,并且与企业设置的组织架构相对应,实行层级管理。根据企业通讯录功能的需要,部门和员工以及它们的信息形成了如图 5 所示的树状结构。

  上文给出的是本文中扩展定义的 Schema 文件,从上文看出 Schema 是由属性、 对象类、几配法则和语法四个重要元素组成。

  首先给出了部门节点的属性,由部门通信地址、部门名称、部门编码以及部门员工数量组成。然后给出了员工节点的属性,有员工编号、员工姓名、性别、年龄、通信地址、手机号、SIP 号以及所属部门组成,最后给出了部门节点和员工节点的对象类型,并将属性添加到对象类型中。

  细粒度是相对粗粒度而言的,细粒度权限访问控制在 RBAC(Role-Based Access Contro)模型中可理解为控制对最小权限单位客体的访问,最小权限单位客体也就是不可再分割的客体,在企业通讯录中最小权限单位是员工的个人信息如电话号码。

  企业通讯录进行细粒度权限访问控制,优化了系统性能,减少系统代码量和降低系统复杂度。

  在使用粗粒度的权限管理系统中,为了授权对最小权限单位的访问,不得不编写大量逻辑代码进行控制,增加了工程难度,不方便授权管理。

  当然,在实际的工程中很难达到最小化分解,只能尽可能进行细粒度分解(R5)。本文通过在原有的“角色-部门-员工”权限管理模型基础上增加了“员工-信息”管理粒度使得权限得以细化,实现了最小权限访问粒度的控制。

  基于角色的访问控制 RBAC 模型中包含了一些基本概念,包括用户、角色、权限、主客体、用户-角色分配(URA)、角色-权限分配(PRA)以及会话。为了介绍 RBAC 模型,这里先介绍一下这些基本概念。

  被访问的对象,是一个被动实体,表现为操作系统中的文件或目录,或者数据库的表、行、字段等,也可以是一些外设图投影仪、打印机等。

  访问系统数据或资源的主体,通常表现为人、系统进程或者代理等,大部分情况下指人

  通常指一个单位中的工作岗位,这个工作岗位具有特定权利与职责,拥有这个角色的人就具有了这种权利与职责。

  指被赋予了访问模式的实体,访问模式也可以说是访问权利,即有权访问哪些实体,权利包括读、写以及执行,被访问的实体与具体的应用场景有关,可以是数据库、通讯录、以及外设等。

  将角色分配给用户,一个用户可以拥有多种角色,分配过后用户拥有角色相应的职责和权利。

  将权限分配给角色,一个角色可以被分配多种权限,分配过后角色拥有访问系统资源的能力。

  指用户激活角色的过程,参与者有一个用户以及一组激活的角色。建立新会话可以激活新的角色。

  在用户与权限之间引入角色中介,将用户与权限的直接关联关系弱化为间接关联关系,如图 7 所示;以角色为中间者,首先创建不同的系统资源访问权限,然后创建不同的角色,根据角色职责的不同将对应权限分配给它们,建立角色-权限的关系后,不同的角色就会有不同的访问权限。根据用户担任的岗位,将对应的角色分配给它们,建立用户-角色的关系,这就是 RBAC (基于角色的访问控制)的主要思想。

  RBAC 模型解耦了用户与权限之间的直接联系,通过角色与权限关联以及用户与角色关联这两部分,实现了通过角色给用户分配权限;一个用户可以有多种角色,一个角色可以有多种权限。RBAC 的这种设计,极大地方便了授权的管理。

  PA(PxR)为角色分配权限:UA(UxR)为用户分配角色;RH(RxR)为角色层次。系统管理员可根据实际系统的需求创建角色,给角色分配权限并给不同用户分配相应的角色。角色和权限之间,以及用户和角色之间都是多对多的关系,其模型图 7 所示。

  RBAC 最大的特点是用户通过角色来获得访问权限,这样做增加了权限管理的灵活性,可以减少管理上的错误。

  当用户在公司的职位发生变化时,只需要移去员工原来的角色并重新分配新职位对应的角色即可,避免因人员职位调动导致的重新授权。当公司的组织架构发生变化时,角色也可以根据公司新的组织架构重新设置。

  除此之外,角色也可以像部门的层级关系那样具有继承关系,高级角色可以继承低级角色的访问权限。这些都是 RBAC 授权灵活性的表现,当然也降低了企业进行授权管理的成本。

  由于企业部门和员工数量很多,管理员在创建权限时不可能去设置一种角色对每一个部门以及每一个员工的访问权限,为了方便权限设置,本文将功能和职责相似的部门以及员工看作是同一类型,在创建部门和员工时系统会为它们分配固有 type 属性,具有相同的 type 类型可看成是同一群组,管理员在设置可见性时不需要去设置对每一个部门或员工的可见性,只需要设置对部门群组和员工群组的可见性即可,示例如图 8 所示。

  基于“角色-部门-员工-信息”细粒度访问控制概念,本文所提“角色-部门-员工-信息”的权限分级模型,由三级权限组成。企业通讯录由多个部门组成,每个部门下又包含多个员工,每个员工都有各种个人信息,这些具体的个人信息可认为是不可分解最小单位。

  在我们的“角色-部门-员工-信息”模型中,员工的这些个人信息属于最小级别权限——三级权限,包含这些信息的个人是它们的父级权限——二级权限,包含员工的部门拥有最大权限级别——一级权限。

  基于“角色-部门-员工-信息”细粒度访问控制概念原理,由于不同角色的用户对系统的访问权限不同。因此,用户在进入系统后,系统根据用户的 ID 查询到用户的权限集合,根据一级权限给客户端返回可见部门,根据二级权限返回可见员工,客户端收到返回信息后可生成本地通讯录的部门菜单以及各部门下所包含的员工,然后根据三级权限系统给客户端返回相应的个人信息。最后客户端将接收到的消息进行解析即可获得本地通讯录。

  根据以上分析,管理员在进行访问权限管理时,首先需要设置各级权限,其次,将权限分配给角色,最后将角色分配给员工,即可完成员工对通讯录访问权限的控制。

  通过以上分析,基于“角色-部门-员工-信息”的权限分级模型实现了权限的 细粒度访问控制,把对权限的控制最小化到了员工的具体个人信息;并根据 RBAC 的访问控制模型,得出了基手“角色-部门-员工-信息”的权限管理模型图如图 9 所示。

  实体关系模型基于“角色-部门-员工-信息”的分级细粒度权限控制模型,有效的实现了用户的访问权限控制,其实体关系图如图 10 所示。

  系统的部门信息、用户信息以及它们之间的从属关系,会采用 LDAP 数据库表示,在此给出的部门、员工表设计仅仅是为了阐明涉及到的实体之间的逻辑关系。

  根据 RBAC 思想,用户、角色、权限相互独立,分别通过用户角色表和角色权限表进行关联,用户角色表中通过引用用户表中的主键用户 ID 作为外键和用户表关联,通过引用角色表中的主键角色 ID 作为外键和角色表关联;角色权限表中通过引用角色表中的主键角色 ID 作为外键和角色关联,通过引用各级权限表中的主键权限 ID 作为外键和各级权限表关联;部门和用户表中各有一个类型字段,该字段用于部门和员工的群组化管理,方便管理员的权限控制。返回搜狐,查看更多

上一篇:最热的天 · 最燃的会 · 焉知智车年会魅力四射!精彩纷呈! 下一篇:山东宏创铝业控股股份有限公司 关于深圳证券交易所关注函回复的公告
最新案例 bob沙巴体育

版权所有:bob沙巴体育登录-bob沙巴体育首页 Copyright @ 2016 All rights reserved.

客服热线:400-8570288