企业统一身份认证.docx
- 文档编号:11258379
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:21
- 大小:74.09KB
企业统一身份认证.docx
《企业统一身份认证.docx》由会员分享,可在线阅读,更多相关《企业统一身份认证.docx(21页珍藏版)》请在冰豆网上搜索。
企业统一身份认证
WebServiceCaseStudy:
统一身份认证服务
柴晓路(***********************)CIO,DealEasy
柴晓路:
上海得易电子商务技术有限公司(DealEasy)CIO、XMLWebSevices技术顾问,WS-IWorkingGroup成员、UDDI-China.org创始人,UDDIAdvisoryGroup成员,IBMdeveloperWorks专栏作家,CSDN名家专栏专栏作家。
2000年获复旦大学计算机科学硕士学位,曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XMLAsia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。
专长于WebServices技术架构、基于XML的系统集成和数据交换应用及方法,同时对数据库、面向对象技术及CSCW等技术比较擅长。
简介:
本文是WebServiceCaseStudy系列文章的第四篇。
在这篇文章中,我将围绕一个多应用环境下统一认证服务组件的架构展开讨论,探讨如何利用Web服务所带来的好处,实现跨平台跨应用的统一身份识别和权限认证。
同时将其拓展到多种应用模式中去,包括Internet公用服务、行业电子商务环境统一认证以及企业内部应用集成等。
标记本文!
发布日期:
2002年8月01日
级别:
初级
访问情况 135次浏览
建议:
0 (添加评论)
平均分(共1个评分)
应用背景
以下描述中使用的地名、机构名和系统名称纯属虚构,但是是从具体应用中抽象出来的。
GeneralBusiness是一家生产和销售多种家用电器的跨国企业。
GeneralBusiness一直注重利用新兴的计算机技术来改善和加强公司的自动化管理。
多年来,尾随各种技术的发展,GeneralBusiness应业务的需要,实施和部署了企业资源规划(ERP)、客户关系管理(CRM)、供应链管理(SCM)以及企业门户(EnterprisePortal)等多种商业应用,这些商业应用分别解决了企业在不同方面的需求,起到了相当的商业成效。
然而,随着业务和技术的发展,以自包含的"�\盒"系统各自存在、各自为政的自治系统的状况无法再维持下去了,商业管理需要整合各个系统的信息,实现跨越所有系统的整合管理,同时将企业内的管理信息流与企业外的管理信息流相结合以实现高反应效率的企业间的电子商务。
这一需求就需要由EAI和B2Bi的技术来实施并满足。
GeneralBusiness的IT部门已经决定使用WebServices技术架构作为其整个企业集团内部进行EAI和B2Bi的基础框架技术。
然而,在设计实施的时候,他们发现,尽管WebServices技术在实现不同系统不同平台之间的对接方面能够大大简化代码,但是,每个应用系统都有其自身的用户系统和认证方式,程序员在为某个应用系统编写接入其它应用系统的程序代码的时候,常常为了用户认证大伤脑筋:
1)让最终用户频繁登录?
似乎是一个让用户很难接受的解决方案。
2)在代码中内置用户名和密码?
代码需要随用户和密码的变化经常维护,同时在很多场合下,用户名和密码对于程序员来说可能是不可见的。
如何解决这一问题呢?
经过讨论,GeneralBusiness决定开发一个统一身份认证服务,以解决这一应用集成中碰到的用户认证的问题。
这个服务需要达到以下功能和目标:
1.支持WebServices技术框架,使得在对各个应用系统实施基于WebServices的应用集成(EAI/B2Bi)的时候能够使用这个统一身份认证服务进行身份认证。
2.方便使用,能够尽可能地利用现有系统的身份认证模块以及现有的用户设置和权限设置,尽量保护现有的投资,减少重新的用户设置和权限设置的费用,同时避免对现有系统进行大规模的修改。
3.具有良好的扩展性和可集成性,不仅能支持现有的应用系统及其现有的用户系统,当有新的企业应用被部署或开发的时候,这个统一身份认证服务可以作为它的身份认证模块的形式工作,也就是说,新的企业应用可以不自带用户系统,可以通过集成该服务的形式来实现等价的功能。
4.应当具备灵活和方便的使用模式,使用者可以通过多种方式自由地使用该统一身份认证服务。
回页首
解决方案
根据这个统一身份认证服务的目标和初步的功能定义,我们将这个服务设计如下:
Figure1.统一身份认证服务
该服务主要需要具备三项功能:
1.用户注册:
用户在统一身份认证服务中注册帐号,以后这个帐号可以在所有使用统一身份认证服务的应用系统中使用。
2.帐号关联:
如果用户之前已经在相关的应用系统中拥有帐号,同时也已经设置了相应的权限,那么用户能够将这些应用系统的帐号与统一身份认证服务的帐号进行关联,使得用户登录统一身份认证服务之后,就能够自动使用相关的应用系统用户来访问应用系统。
3.用户认证:
为应用系统提供用户身份认证,兼顾两个应用方式:
4.
o应用系统使用统一身份认证服务作为它的用户系统,用户与应用系统进行交互,进行登录操作,应用系统将用户提供的用户名/密码等转发给统一身份认证服务以检验其是否通过授权。
o用户首先登录统一身份认证服务,并获取权限令牌,以后可以使用这个权限令牌访问其他的应用系统,应用系统接收该权限令牌时应当与统一身份认证服务进行交互,以检验访问的合法性。
按照以上的功能描述,我们可以认为统一身份认证服务中需要考虑的实体可以使用下图来表示:
Figure2.统一身份认证服务的数据实体
1.用户(User):
即统一身份认证服务的用户;
2.帐号(Account):
应用系统的帐号,与统一身份认证服务的用户相关联,一个用户可以关联多个帐号;
3.应用系统(Application):
使用统一身份认证服务的应用系统;
4.会话(Session):
当用户登录统一身份认证服务后,即创建了一个活跃的会话,并获得会话的认证令牌,在这个会话中,用户可以使用会话的认证令牌访问各种应用系统。
用户注册
用户注册(包括用户更新注册信息)的流程可以使用下图来表示。
其中主要包含了两个流程:
新用户注册和用户更新注册信息。
Figure3.用户注册流程
新用户注册:
1.用户向统一身份认证服务发出新用户注册请求
2.服务查询用户注册库,如果该用户可以注册(没有同名ID等违背约束条件的情况发生),那么将该用户的信息保存到用户注册库中。
3.当保存完毕后,统一身份认证服务响应用户,注册完成。
用户更新注册信息:
1.用户向统一身份认证服务发出用户注册信息更新请求。
2.服务查询用户注册库,如果该用户信息可以更新(有该ID存在,同时提供的密码也是正确的等等),那么将该用户的信息将在用户注册库中更新。
3.当保存完毕后,统一身份认证服务响应用户,更新完成。
帐号关联
帐号关联操作可以使用下图来表示。
图中仅包含一个登记新的帐号关联的操作,相关的修改、删除操作被省略了,有兴趣的读者可以自行给出。
Figure4.用户关联流程
登记新的帐号关联:
1.用户向统一身份认证服务发出帐号关联注册请求,用户提供了应用系统的标识A,同时提供了可以在该应用系统中使用的用户信息(可能包含用户名和密码等)。
2.服务首先向该应用系统A征询,用户信息是否合法。
如果合法则响应服务。
3.如果收到合法响应,那么服务就将这个帐号关联注册信息保存到用户注册库中,以后该用户登录统一身份认证服务之后,就能够使用相应的应用系统A。
4.当注册库完成保存操作后,统一身份认证服务响应用户,注册完成。
身份认证组件模式
统一身份认证服务的一个基本应用模式是以应用系统的身份认证组件的形式工作,在这个应用模式下,主导地位的是应用系统。
在这种情况下,应用系统自身没有用户系统,因此本模式下涉及的帐号一定是统一身份认证服务的用户帐号。
Figure5.身份认证组件模式流程
流程描述如下:
(仅描述正常流程)
1.用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息,比如数字签名等)登陆应用系统A
2.应用系统A,将用户名和密码连同自己的标识(应用系统A的标识)一起转发给统一认证服务,要求统一认证服务完成登录操作。
3.统一认证服务核查自己的应用系统注册库(使用UDDIRegistry,我将在后面解释为什么使用UDDIRegistry)看看应用系统A是否已经是统一认证服务的用户系统。
同时在用户注册库中核查由应用系统A转发过来的用户名和密码。
4.待核查完毕后,统一认证服务响应应用系统A,登录完成。
5.应用系统A创建一个系统会话(Session,系统A自己的机制),并将应用系统A自己的权限令牌返回给用户,以后用户端可以通过这个权限令牌持续访问应用系统A,直至登出系统或是会话超时。
统一认证模式
统一认证模式是以统一身份认证服务为核心的服务使用模式。
用户登录统一身份认证服务后,即可使用所有支持统一身份认证服务的应用系统。
Figure6.统一认证模式流程
流程描述如下:
(仅描述正常流程)
1.用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息,比如数字签名等)登陆统一认证服务;
2.统一认证服务创建了一个会话,同时将与该会话关联的访问认证令牌返回给用户;
3.用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统;
4.该应用系统将访问认证令牌传入统一身份认证服务,认证访问认证令牌的有效性;
5.统一身份认证服务确认认证令牌的有效性;
6.应用系统接收访问,并返回访问结果,如果需要提高访问效率的话,应用系统可选择返回其自身的认证令牌已使得用户之后可以使用这个私有令牌持续访问。
此外,关于访问认证令牌的失效,有两个策略,一个是由用户主动发起声明,声明其拥有的访问认证令牌不再有效,这类似注销的操作,另一个是用户一段时间内没有使用这个认证令牌,认证令牌自动失效,这类似超时的处理。
信任代理模式
在Internet应用环境下,安全性和信任的重要性是显而易见的,对于商用系统而言,避免非法访问和入侵是他所需要考虑的几个重要问题之一,没有比商用数据丢失或是商用系统被违规使用更糟糕的了。
在信任代理模式下,一个组织可以为他所有需要提供安全信任保障的应用系统设置一个统一身份认证服务,对这些应用系统的访问全部由统一身份认证服务代理。
Figure7.信任代理模式流程
流程描述如下:
(仅描述正常流程)
1.用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息,比如数字签名等)登陆统一认证服务;
2.统一认证服务创建了一个会话,同时将与该会话关联的访问认证令牌返回给用户;
3.用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统,不过用户并不将请求消息直接交给应用系统,而是传给统一身份认证服务,在消息中标识了最终的应用系统的ID。
4.统一认证服务访问应用系统注册库(UDDIRegistry),获取了应用系统的访问入口(统一认证服务可以将这个访问入口缓存在本地,以减少以后与应用系统注册库的交互次数)。
并确认这个应用系统的确是支持统一身份认证服务的;
5.统一认证服务将请求消息转发给指定的应用系统,如果该应用系统使用自己的用户系统的话,那么该消息应当包含了预先定义好的相关联的用户名和密码等。
6.应用系统将请求结果返回给统一认证服务,最后统一认证服务将响应消息返回给用户,完成调用。
在该模式下,所有应用系统仅接收来自统一认证服务的访问请求,这样,解决方案提供商可以将主要的安全方面的投入部署在统一认证服务那端。
回页首
使用Web服务架构
由于统一身份认证服务可能被应用的领域包括:
∙企业内部的各种应用
∙跨国企业的各个部门或地区分公司的各种应用
∙行业内各个企业的不同应用
∙Internet上丰富的应用环境
无论是何种应用环境,都将面对不同的平台、不同的系统和不同的编程环境,要能最大可能地支持所有的平台、系统和编程环境,同时又要确保服务的实现代价保持相对固定,那么目前看来,选择基于规范的WebServices解决方案将是一个不错的选择。
UDDI的角色
在我们这个基于统一身份识别服务的应用环境中,所有支持统一身份识别服务的应用系统都需要被注册在UDDI注册中心中。
如果是企业内部的应用环境、跨国企业的应用环境或是行业内多个企业组成的联合行业应用环境,那么应当使用PrivateUDDIRegistry(私有UDDI注册中心),如果是Internet应用环境的话,则可以考虑使用PublicUDDIRegistry(公共UDDI注册中心)。
所有支持统一身份识别服务的应用系统以UDDI数据实体businessService的形式注册在UDDI注册中心中,他们都被分配了一个UUID(唯一标识符),这个UUID可以在用户定义关联帐号或是使用统一身份认证服务进行应用系统访问的时候,用于标识相应的应用系统。
businessService是UDDI中的一个关键的数据结构,businessService将一系列有关商业流程或分类目录的WebService的描述组合到一起。
businessService和下面要提到的bindingTemplate一起构成了技术信息。
其中,一个可能的商业流程的例子是一组相关的Web服务信息,包括采购服务、运输服务和其它的高层商业流程。
这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。
这些businessService的信息集合可以再次加以分类,使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。
分类的方法的机制与businessEntity是类似的。
对于每一个businessService,存在一个或多个Web服务的技术描述bindingTemplate。
这些技术描述包括应用程序连接远程Web服务并与之通讯所必须的信息。
这些信息包括Web应用服务的入口地址、应用服务宿主和调用服务前必须调用的附加应用服务等。
另外,通过附加的特性还可以实现一些复杂的路由选择,诸如负载平衡等。
当统一身份认证服务得到用户提交的应用系统的UUID之后,它应当使用这个UUID查询UDDI注册中心,以获得这个应用系统的完整服务描述(businessService结构),随后统一身份认证服务就可以得到这个应用系统的访问入口,并实施访问。
当应用系统修改了访问入口或是某些关键的技术信息之后,它可以在UDDI注册中心中更新自己的信息,这样,当统一身份认证服务下一次实施关联的查询时,就可以获取新的应用系统的访问信息,这样一种方式可以无需修改代码实现动态绑定。
为了提高服务的响应效率,减少与UDDI注册中心的交互次数,统一身份认证服务也可以选择将应用系统的UDDI描述缓存在本地,当用户访问相关的应用系统时可以直接使用缓存的数据进行后继操作。
细心的读者应当已经发现,缓存操作与前面描述的应用系统自更新技术信息的操作可能会发生冲突,缓存的信息与UDDI中的信息可能发生版本不一致的情况,此时后继的应用系统访问操作可能会发生错误,当这种错误发生后,统一身份认证服务应当选择重新缓存相关的UDDI中的应用系统技术信息以恢复数据的一致性。
Web服务接口
根据前面几个部分的描述,我们可以归纳出统一身份认证服务的对外接口,接口基本上由两部分组成:
1.用户Profile维护:
包括用户注册,关联帐号定义,帐号信息维护等。
2.认证服务:
包括用户登录/注销,认证令牌认证,访问转发,访问代理等等。
用户Profile维护
用户Profile维护的XMLSchema定义如下:
xmlversion="1.0"encoding="UTF-8"?
>
schemaxmlns: xs="http: //www.w3.org/2001/XMLSchema" elementFormDefault="qualified"attributeFormDefault="unqualified"> elementname="user"type="userType"> annotation> documentation>USASUserDefinition documentation> annotation> element> complexTypename="userType"> sequence> elementname="userID"type="emailType"/> elementname="credential"type="xs: base64Binary"/> elementname="personalInfo"> complexType> sequence> elementname="name"type="xs: string"/> elementname="alternativeEmail"type="emailType"/> elementname="phone"type="xs: string"/> elementname="fax"type="xs: string"/> elementname="company"type="xs: string"/> elementname="department"type="xs: string"/> sequence> complexType> element> elementname="associatedAccounts"> complexType> sequence> elementname="associatedAccount" type="accountType"minOccurs="0"maxOccurs="unbounded"/> sequence> complexType> element> sequence> complexType> simpleTypename="emailType"> restrictionbase="xs: string"/> simpleType> complexTypename="accountType"> sequence> elementname="applicationID"type="xs: string"/> elementname="accountID"type="xs: string"/> elementname="credential"type="xs: base64Binary"/> sequence> complexType> elementname="save_user"> complexType> sequence> elementref="user"/> sequence> complexType> element> elementname="delete_user"> complexType> sequence> elementname="userID"type="emailType"/> elementname="credential"type="xs: base64Binary"/> sequence> complexType> element> schema> 从这个XMLSchema文档中,我们不难看出,我们可以使用两个API来维护用户帐号: save_user和delete_user。 其中save_user用于新建帐号和更新帐号。 当统一身份认证服务接受到save_userAPI调用时,如果发现服务的用户库中并没有相应的userID,那么就是新建帐号,否则如果发现服务的用户库中有相应的userID,那么就是更新帐号。 而delete_user则用于删除帐号,当然前提是服务的用户库中有相应的userID,否则就是非法调用。 在delete_userAPI调用中,顶级元素是delete_user,delete_user有两个子元素userID和credential,userID是用户的标识,其类型是email地址,使用email地址作为用户标识也是目前非专用用户系统比较通用的一种方式,原因非常简单,email地址不同的人肯定不会重复,这样就避免了帐号无法成功注册的情况。 而credential则是对应的授权信息,可能是用户密码,数字签名等等形式。 对于save_userAPI调用而言,其顶级元素是save_user,而save_user有一个子元素user,user元素完整定义了一个用户帐号的详细信息。 除了userID和credential子元素外,user元素还包括两个复合元素personalInfo和associatedAccounts。 personalInfo元素描述了用户的个人信息,包括: name(姓名)、alternativeEmail(可替换的email,userID是其使用的主要email)、phone(电话)、fax(传真)、company(所属公司)、department(所属部门)。 而associatedAccounts则定义了多个关联帐号,每个关联帐号的定义(associatedAccount)由三个元素组成: applicationID(应用系统的UDDIUUID标识)、accountID(应用系统中的用户ID)、credential(应用系统中相关用户ID对应的授权信息,可能是密码、数字签名等)。 认证服务 认证服务API主要包含sign_in、check_authToken、discard_authToken等API调用。 sign_in消息用于登录统一身份认证服务,并获得认证令牌。 认证令牌是登录之后访问统一身份认证服务以及使用应用系统所必须的不可缺少的必要参数。 sign_inAPI调用的消息语法形如: 其中userID是用户的标识,其类型是email地址,使用email地址作为用户标识也是目前非专用用户系统比较通用的一种方式,原因非常简单,email地址不同的人肯定不会重复,这样就避免了帐号无法成功注册的情况。 而credential则是对应的授权信息,可能是用户密码,数字签名等等形式。 当sign_in成功调用后,统一身份认证服务需要返回认证令牌以供此后的授权访问。 authToken消息是sign_in消息的响应消息。 它返回认证信息authInfo,认证信息将用于后续
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业 统一 身份 认证