• 爱情文章
  • 亲情文章
  • 友情文章
  • 生活随笔
  • 校园文章
  • 经典文章
  • 人生哲理
  • 励志文章
  • 搞笑文章
  • 心情日记
  • 公文文档
  • 英语文章
  • 当前位置: 星星阅读网 > 经典文章 > 正文

    协同商务的前沿问题_浅析网络协同商务系统的访问控制问题

    时间:2019-01-30 06:48:33 来源:星星阅读网 本文已影响 星星阅读网手机站

      【摘 要】:文章对一个特定的汽车行业协同商务系统进行分析,意在讨论当前流行的协同商务系统的访问权限问题。在类似的电子商务应用中,访问控制及其它安全问题的开发都是以该系统作为基础的,所以,对此而开发的系统在各种平台下是通用的。
      【关键词】:网络;协同商务系统;访问权限;控制
      中图分类号:TP3 文献标识码:B 文章编号:1997-0668(2008)0210084-04
      
      1.什么是协同商务系统
      
      在全球经济日趋一体化的国际大背景下,我国的中小企业面临着国际、国内企业竞争的双重压力,巨大的机遇和挑战,迫使企业依靠信息技术来提高自身的竞争力。为了能够更紧密的与上游的资源提供者和下游的销售者建立更密切的联系,为了更好的把握住瞬息万变的市场。随着现代网络的发展,协同商务系统应需诞生了。通过协同商务系统,上下游企业之间,企业内部之间的交流变得更为顺畅,能够更好的把握企业的运行情况,产品的销售情况等等,为企业的更进一步提高竞争力奠定了基础。
      
      图1-1 协同商务平台的体系结构示意
      
      协同电子商务平台的主要模块如图1-1所示。协同商务平台对外提供两种类型的接口,一种是由用户使用浏览器访问的接口,另一种是发布出来的Web服务接口(基于HTTP协议),供客户端进程使用。协同商务平台主要包括访问控制模块、经销商管理模块、服务商管理模块、产品信息发布模块、订单管理模块、远程数据交换模块等几个模块,其中访问控制模块是贯穿整个系统的一根红线。不管是使用传统Web界面的用户,还是使用Web服务的进程用户,都需要首先将登陆信息提供给访问控制模块,然后由访问控制模块根据系统权限的配置信息和用户所拥有的权限信息来决定是否允许该用户的访问,在用户浏览过程中需要确保用户的访问合法。
      以汽车行业为例,经销商管理模块的主要功能是管理汽车制造企业的下游经销商,包括查阅经销商的资料、审批经销商的资格等。在汽车售出以后,如果汽车出现故障,可以在厂家特约的维修点维修,服务商管理模块主要实现厂家和这些维修点之间的业务往来。产品信息发布模块由企业编辑发布本企业的产品信息。订单管理模块为购买汽车的注册用户(主要是签过合同的经销商)提供了网上下订单的功能,为汽车制造厂商提供了查看、审批订单的功能,也可以通过数据交换模块将订单下载到本地处理。由于各个汽车厂家的订单格式可能不同,因此此模块还应当给汽车厂家提供一个制定订单模板的功能,这样一来,购车者选购不同厂家的汽车时系统就有能力提供相应的订单格式。
      
      2.访问控制系统的分析
      
      与传统的单击系统不同,协同商务系统不是一个人在一个固定地方使用的系统。他是一个面对大量不同用户从不同地点进行访问的系统。在这么多不同的的访问用户中,他们具有不同的岗位,有着不同的工作职责,有着不同的职务级别,在如此复杂的条件下,为了保证系统内的信息不被无意或者恶意的操作,各种机密信息能够有效的保密,每个用户所能操作、查看的内容是需要进行控制的,为了对这种权限进行控制,访问控制系统成为了一个良好的协网络同商务平台所必须的功能。
      因为文章中讨论的访问控制系统是为协同商务平台而设计的,所以必须对协同商务平台对于访问控制的需求进行分析,这样才能做到有的放矢。
      2.1用户群分析
      协同商务平台是为多个企业的协作而开发的。首先对这个平台的用户群体进行一些分析。当前平台主要应用在汽车行业,平台的用户以汽车制造厂商为核心用户,在这些汽车制造厂商的上游供应链上,有一些零配件的供货商。这些上游供货商分布在全国各地,他们是潜在的用户,因此设计时应当对他们加以考虑,使平台具有良好的可扩充性。每个汽车制造厂商都有一个经销商群,这是他们进行汽车销售的重要渠道,汽车制造厂商与经销商的主要业务关系有销售合同的管理,经销商资质的管理,订单的管理等方面。车售出以后,可能会出现故障,因此每个汽车制造厂商还有一个服务商群,这些服务商通常是一些维修站,与汽车制造厂商之间有维修单据等数据往来,他们使用平台后可以将这些数据录入到平台,汽车制造厂商可以在平台上查阅或者用数据交换组件将数据导入到其本地系统中。与此前的手工处理相比大大缩短了这些数据传递时所花费的时间。
      经过以上的简要分析,我们可以大致勾勒出平台的用户群体,如图2-1所示。图中的每个椭圆代表一类用户,事实上,每一类用户都包含较多的企业,例如:一家汽车制造厂的经销商可能会多达数百家。
      
      2.2角色设置策略
      有了上一节对平台用户群的分析,我们这节要考虑的问题是采用什么样的角色策略以及设置哪些角色。粗略地看,汽车制造商、汽车销售商、汽车服务商和潜在的零配件供应商之间的分别非常明显。他们登陆平台后,能完成的功能也各不相同。在一个用户登陆平台以后,系统需要知道这个用户所属企业的类型,以决定呈现给用户的内容。很显然,一个用户如果属于企业A,那么决不可能同时又属于企业B。举例来说,一个汽车销售商不需要像汽车制造商那样提供订单模板,汽车制造商也不会像汽车服务商那样填写维修单据。因此每一类应该各设一个基础角色,这些角色之间是应当是互斥的。同时还需要考虑到将来有其它类型的企业使用平台时,角色体系应当能够进行相应的扩充。图2-2描述了平台中的企业类型角色,这些角色派生自"平台用户"根角色,它们中的每一个都拥有一个独立的角色族,这些角色族之间是互斥的,这些角色不可同时授予用户。在有新类型的厂商加入平台时,我们可以很方便地对角色体系进行扩充。
      
      这只是一个粗略的划分,还需要更具体一些,明确到具体使用平台的人员。以汽车制造厂商为例,其内部又可分为销售部、服务部、采购部等几个大的部门。销售部门包括销售部门经理,片区经理,业务主任,业务员等几类角色;服务部门也包括部门经理,业务主任,业务员等角色。而经销商企业也可能拥有多个部门,每个部门又可拥有若干角色类型,比如负责制订采购订单的业务经理等角色。服务商需要有进行维修单据录入的角色,管理零配件消耗情况的角色等等。还有一种特殊的用户,一些企业已经拥有自己的内部信息管理系统,这些内部系统可以与平台进行数据交换,出于安全性考虑,平台的WEB服务接口要求请求者提供自己的身份凭证,因此这也是一种用户类型。
      在每个公司内部,员工各有不同的职责,当他们使用平台时,有权看到的内容和允许进行的操作是不同的,系统应该提供比较合适的权限粒度,满足实际的需求。比如一张订单的确认要经过业务员的核对和业务主任的审批后,才能生效,那么业务员与业务主任的工作就必须设定为由不同的角色来完成,不能只设定一个订单管理员了事。图2-3给出了派生自图2-2中"汽车制造厂用户"角色的部分角色体系。对于经销商用户和服务商用户来说,其内部角色的情况与之类似,由于角色种类繁多,我们需要为管理员提供一个易于使用的角色设置工具来简化管理员的工作。
      
      关于访问控制系统的管理也是一个必须要考虑的问题。因为各个用户都分属于各个企业,如果所有的用户都统一由一个平台管理员来管理的话,那么工作量就非常大,企业也缺乏必要的灵活性。试想以下,如果企业中的每一次人员的流动或者岗位的调动,都要通知平台管理员才能完成用户的注销、角色的调整,这样做不仅低效,也不合理。根据Ravi S.Sandhu所提出的ARBAC理论模型,可以将用户-角色关系的管理权分散到各个企业中去。但是具体的角色设置、权限设置、角色间的静态约束和角色-权限关系仍由平台管理员统一管理,这是因为这些内容事实上属于应用程序配置的一部分。
      管理角色的类型可以分为平台管理员角色和企业管理员角色,这两种角色没有继承关系,实质上两者是互斥的。管理员角色与普通用户角色分属于不同的角色体系,在数据库系统中分别存放在不同的表中。平台管理员角色的成员要负责所有的系统配置操作,包括设置角色(包括普通角色和管理角色),制订角色约束规则,设置系统中的权限,还要指定角色和权限间的映射关系。企业管理员角色的成员负责管理各自企业内部的UR关系管理,但不负责PR关系的管理,后者由平台管理员的成员负责,这样在管理上就将管理的任务明确分开了,减轻了平台管理员的负担,也给了企业自己调整用户的自主权。
      经过以上的分析,因为实际的用户有很好的层次性,所以很自然的就会想到用角色继承来设计角色层次;而且对用户-角色之间的关系以及角色-权限之间的关系都有约束。这样来说我们需要有RBAC1中的角色继承概念和RBAC2中的约束概念,对于我们的系统来说,没有必要引入DSD和多继承使系统复杂化,仅保留静态约束和单继承,得到一个复杂性可控的系统设计。出于角色数据的完整性于一致性考虑,与角色相关的静态约束集应该有以下这些:
      每个角色的最大授权用户数目(Cardinality)。
      例如:可以规定每个企业的管理员角色只能有一个用户。
      两个角色的静态互斥约束。
      例如:可以规定订单业务员角色和业务主任角色静态互斥。用户就不可同时拥有这两个角色。
      每个角色不能与自己静态互斥。
      这是显然的,如果角色与自身互斥,那么任何用户都无法拥有这个角色。
      禁止多继承。
      我们的用户类型中,不需要使用多继承即可满足需求,允许多继承会造成不必要的麻烦。
      任何具有静态互斥关系的角色不能存在(直接或间接的)继承关系。
      如果任何两个具有(直接的,或间接的)继承关系的角色被授予同一个用户,则仅保留最高级的角色。
      作为访问控制系统的设计者,必须给平台管理员提供合适的管理接口,便于进行角色、权限、角色间的静态约束和角色-权限关系等方面的调整、管理。考虑到平台日后很可能会增加权限和角色种类,系统应当有良好的可扩充性。
      2.3定义权限
      NIST的RBAC模型对权限的定义是:在一个或者多个客体(object)上执行某一特定操作(operation)的权力。图2-4中形象的表示了这个定义。
      
      协同商务平台的客体实质是各种类别的数据,但这些数据并不允许用户直接读取、更改,而是通过Web页面和Web服务的方式为最终用户提供访问接口,每一项任务都是通过页面与用户的交互完成的。因此,我们可以将页面作为系统中的客体。
      对于B/S结构的应用程序来说,使用URL在系统中标识客体是一种简便易行的方法,可以使用形如:http://www.省略/ec/order.aspx的字符串来标识一个客体,默认的权限就是允许用户访问该页面。另外在系统中可能需要设计一套操作类型,在将某一客体指派给角色时,如果具体应用需要(比如不同角色的用户访问同一URL时需要返回不同的界面),允许同时指定在该客体上可以进行的操作集。这些操作类型可以在开发系统时就预先定义妥当,但更具灵活性的做法是提供一个管理操作类型的工具,允许管理员根据具体需要灵活配置。
      权限信息和角色-权限的映射关系信息可以存储在数据库中,也可以存储在XML格式的配置文件内。有些角色数目不大的应用将配置存储在XML文件,这可以得到一个好处,就是系统可以检测到配置文件的改动,及时重新装载配置信息。但是考虑到在我们的应用里,角色的数目可能会比较大,权限-角色之间的映射关系对应也比较多,使用XML文件速度会比较慢一些,因此将这些信息保存在数据库中。
      系统中如果存在较多的页面,则使用手工录入的方式定义权限是不可行的,这样不仅非常繁琐,而且易于出错。考虑到Web内容的存放比较有规律,一般都是存放在相应的虚拟目录下,可以提供一个资源收集的工具,将系统中所有的页面资源列出,管理员仅需根据需要选取相应的资源设置为权限即可。这就大大减轻了录入数据的负担,而且增加了可靠性。
      2.4标识用户
      我们接下来需要考虑的是如何将一个用户在计算机系统中标识出来,目前来说,用户登陆系统的凭证有用户名/口令、USB-key、生物特征等方式。其中,最廉价、最便捷也是使用最广泛的方式,就是用户名/口令方式。当然有一些更为稳妥的方案,比如使用USB-key,但是这些方案需要较多的费用投入,进一步给平台的实施带来障碍。基于这些考虑,我们选用的解决方案仍然采用用户名/口令方式。因为用户口令等需要通过公共网络传输,为了保证口令及用户订单等敏感数据的安全性,采用SSL来建立客户端和服务器端的安全信道,避免敏感数据在不安全信道上传输引发的安全问题。
      如果以后改用其它的登陆凭证,只需要修改系统的登陆部分即可,系统的其它部分仍然是适用的。
      
      3. 总结
      
      文章首先对协同商务系统进行了阐述,介绍了网络协同商务系统访问控制的重要性。然后分析了用户的种类,接下来详细分析了角色设置的策略,其中包括普通角色的设置策略和管理角色的设置策略,在文章的讨论中,对访问控制权力的管理思想是将管理工作分散给各个企业内部的管理员即权力下放的原则。最后讨论了权限的表示方法以及采取何种方式在系统中将用户标识出来。
      
      参考文献
      [1] 邓集波,洪帆. 基于任务的访问控制模型. 软件学报,2003,1:76-81.
      [2] 訾小超, 茅兵, 谢立. 面向对象访问控制模型的研究与实现. 计算机应用与软件,2004,1:4-6.
      [3] 许峰,赖海光,黄皓,谢立. 面向服务的角色访问控制技术研究. 计算机学报. 2005,4:686-693.
      [4] 刘克龙,卿斯汉,冯登国. 一种基于BLP模型的安全Web服务器系统. 计算机学报. 2003,10:1280-1287.
      [5] 唐慧佳,孙林夫,诸昌钤. 电子商务技术在区域制造业中的应用研究. 中国制造业信息化. 2004,5:73-75.
      [6] 徐震,李斓,冯登国. 基于角色的受限委托模型. 软件学报. 2005,5:970-978.
      [7] 梁洪亮,孙玉芳,赵庆松,张相锋,孙波. 一个安全标记公共框架的设计与实现. 软件学报,2003,3:547-552.

    • 爱情文章
    • 亲情文章
    • 友情文章
    • 随笔
    • 校园
    • 哲理
    • 励志文章