引言
除非一项服务仅提供匿名访问,否则它就需要对用户进行管理。为了分析和实现用户体验的个性化,服务需要确定每个连接用户的身份。因此,对用户身份的管理非常重要。但是,许多传统的应用都在彼此隔绝地解决身份认证问题,从而导致了用户管理存储及系统的数量激增。这种各自为战的身份管理方法会产生如下一些问题:
1)用户必须记住和手动重新输入各种各样数目繁多的账户和凭据。
2)这种给用户带来的额外负担往往会导致用户使用弱口令或在不同安全域中重复使用相同的凭据。因此,数据的敏感性可能就会受到损害。
3)用户可能在另外创建账户时会踌躇不前,这就会导致网站访问者的注册率和转化率都很低。
4)应用提供商需要重新设计并管理一个身份管理系统。这要涉及相当多的工作,而这一领域往往并不是Web开发人员的核心竞争力所在。
5)各自为战的方式会失去在经过用户授权后可以充分利用一些共同的网站需求和共享所获得的信息的机会。
为解决这一问题,人们曾经尝试了各种各样的方法,比如目录同步、实时查找等。这些方法虽然解决了一些问题,但又制造出另外一些问题。因此,必须引入新的身份管理方法,其中联合身份管理就是目前众多企业所采取的身份管理方案,它能够处理多个单位、大量应用并支持数千甚至数百万用户公共身份的管理。尽管其需要一系列复杂的技术和业务流程,但目的却很简单:跨越管理边界,自动共享身份信息。
1 身份管理的通用架构
身份管理是一个集中式的、自动的方法,提供雇员或者其他授权的个人对资源拥有企业范围的访问。其重点是为用户定义一个身份,为该身份关联属性,并完成用户的身份认证。图1 即为通用的身份管理架构。
图1 通用的身份管理架构
图中说明了通用身份管理结构中的实体和数据流。一个当事人就是一个身份持有者,也就是一个想要访问网络资源和服务的人,用户设施、代理程序和服务器系统都可能作为当事人。当事人向身份提供者证明自己,身份提供者为当事人关联认证信息,如属性等。
数据消费者是一些实体,能够得到并使用由身份和属性提供者提供的数据,数据消费者常被用于支持授权决定和收集审计信息,如数据库服务器或者文件服务器,需要客户的证书来决定为该客户提供什么样的访问权限。
2 联合身份管理的通用架构
在本质上,身份联合是身份管理在多个安全域上的一个扩展,这些域包括自治的内部商业单元、外部的商业伙伴以及其他第三方的应用和服务。目的是提供数字身份共享,使得用户只需要一次认证就可以访问多个域的应用和资源。这些域是相对自治或者独立的,因此可以采用非集中化控制,当然,合作的组织之间必须形成一个基于协商和相互信任的标准来安全地共享数字身份。图2 给出了通用联合身份管理结构中的实体和数据流。
图2 联合身份管理架构
其中具体的数据流为:
①终端用户的浏览器或其他应用需要和同一个域的身份提供者“通话”,终端用户也提供与身份关联的属性值;
②一些与身份关联的属性,如许可的角色,可能由同一个域的管理员提供;
③用户想要访问的服务提供者的其他域,从资源域的身份提供者处获取身份信息,认证信息和关联信息;
④服务提供者和远程用户会话,执行基于用户身份和属性的访问控制限制。
身份提供者通过和用户以及管理者会话、协议交换来获得属性信息,身份管理使得用户一次性提供这些信息并将其保存,在满足授权和隐私策略时发布给数据消费者。而服务提供者是一些实体,能够得到和使用由身份和属性提供者维持和提供的数据,数据消费者常被用于支持授权决定和收集审计信息。一个服务提供者可以和用户以及身份提供者在同一个域,但联合身份管理中服务提供者和用户在不同的域。
3 联合身份管理的标准
目前涉及联合身份管理的标准主要有两大系列。在消费者市场中,开放式认证系统(OpenID,Open Identification)很流行;而在企业市场上,较为普通的是使用安全断言标记语言(SAML,SecurityAssertion Markup Language)。
3.1 OpenID
OpenID 是一个对于以用户为中心的数字身份的开放式、分散的自由框架。它消除了跨越不同站点的多个用户名的需求,简化了用户的在线体验。也就是说,它提供了一种可使用某一家服务提供商来建立账户并向其他接受OpenID 身份验证的网站提供登录功能的框架。即它是一个联合式身份认证系统,可用于跨不同Web服务的用户身份验证工作。用户可以使用OpenID 身份认证提供商网站上的凭据,登录到OpenID 依赖方的网站上。图3 显示了利用谷歌应用程序(Google Apps)的Web 应用的过程。在这种情况下,Web 应用是依赖方,而Google是身份认证提供商。
其中的数据流为:①用户要在一个OpenID 身份提供商处创建一个账户;②用户访问一个OpenID依赖方的网站;③该网站提供了多种登录选项,其中包括指向OpenID 身份认证提供商的链接。依赖方将用户指向身份认证提供商,进行身份认证;④用户使用身份认证提供商来验证自己的身份;⑤身份认证提供商向依赖方提供一个令牌,以此来确认用户的身份;⑥用户现在无需再次输入密码就可以访问依赖方的网站了。
图3 Google登录认证
3.2 SAML
SAML 是一种基于可扩展标记语言(XML,eXrensible Markup Language)的标准,用于在安全域之间,也就是在身份提供商与服务提供商之间交换认证及授权数据。它与OpenID 类似,也允许服务提供商仅提供服务而无须自己实现一个身份验证系统。相反,该服务提供商会委托身份认证提供商来验证用户的身份。
SAML 是一个抽象的框架,它规定了断言的定义以及用于获取和传输这些断言的协议。最重要的是,SAML 的核心规范并没有定义任何最终用户可见的行为。
对于那些需要与顾客身份存储相连接的GoogleApps 托管服务,托管在Google 上的应用就是依赖方,但客户要负责提供一个基于SAML 的用户认证服务,因此它就是身份认证提供商。图4 为对GoogleApps 进行SAML 验证的过程,其步骤如下述。
图4 对Google Apps进行SAML验证
①在开始进行身份验证之前,合作伙伴首先要向Google 提供其单点登录(SSO,Single Sign-On)服务的统一资源定位符(URL,Uniform ResourceLocator),还要提供一个公钥,Google 要使用它来对SAML相应进行验证;
②当用户请求访问一个托管的Google 时,就会开始一个这样的认证过程;
③Google 会产生一个SAML 身份验证请求。然后,Google 就会将用户浏览器重定向到身份认证提供商那里,在该SSO 服务的URL 中,嵌入有SAML 请求和所请求的Google 应用的URL;
④身份认证提供商会对该SAML请求进行解码,然后再验证用户的身份验证。在验证用户身份时,可以要求用户提供一个有效的登录系统,也可以通过检查有效的会话Cookie 来进行验证;
⑤身份认证提供商生成一个SAML 响应,其中包含验证用户的用户名。这一响应使用非对称加密算法的公钥和私钥进行了数字签名。身份认证提供商会对SAML响应进行编码,然后将其返回到用户浏览器,同时还带有对浏览器的重定向指令;
⑥浏览器将此消息转发给Google 的断言消费者服务(ACS,Assertion Consumer Service);⑦Google 的ACS 会使用验证提供商的公共密钥来对SAML响应进行校验。如果验证成功,ACS 就会将用户重定向到目标URL中,并登录到Google Apps的账户上。
总之,这两个标准很相似。SAML 较为灵活,但实施起来也较难。OpenID迎合了Web SSO 的需要,它定义了一种专门的用户交互方式。如果你的目标是基于Web 的单点登录,那么OpenID 就是最简单的一种解决方案了。在其他情况下,比如在使用后端身份存储进行透明身份验证的情况下,则SAML能够提供更多的选择。
4 结语
集成的身份管理是云计算所面临的最大挑战之一。目前最佳的解决方案是不要建立自己的身份管理解决方案,而是积极采用联合式身份识别解决方案,要使用OpenID 或SAML 来利用别人的身份存储,这样就可以使得企业能够更好地进行日志记录和审计工作,同时还能降低与密码重置和安全访问现有的异构应用相关的成本[7]。同样,它们还能减少孤儿账户的风险,从而防止那些已离开公司的前雇员们访问应用。它们用一个全面的关于访问权限的视图来取代了那些基于电子表格的报表机制,这一视图能够让你清楚地了解安全态势,并能帮助你实现集中式的、全企业范围的安全控制。
核心关注:拓步ERP系统平台是覆盖了众多的业务领域、行业应用,蕴涵了丰富的ERP管理思想,集成了ERP软件业务管理理念,功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理,全面涵盖了企业关注ERP管理系统的核心领域,是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处:拓步ERP资讯网http://www.toberp.com/
本文标题:云计算环境下联合身份管理研究