企业和用户认证标准及协议的对比云计算服务的IAM 相关标准和协议在之前的部分中,我们确立了对云计算服务应用标准的IAM 原理与实践的需求和益处。在这部分,我们将讨论有关IAM 的标准,这个标准是企业采用云计算服务的催化剂。目前正在基于业务和运作准则来评估云计算服务的机构,应当考虑到云计算服务提供商的承诺以及对于身份及访问管理标准的支持。 5.7.1 机构的IAM 标准与规范 下面的IAM 的标准与规范将有助于机构在云计算中实施有效果、有效率的用户访问管理实践及流程。在用户及访问管理方面,面对云计算用户的挑战分为以下四类: 1. 应如何避免复制身份、属性和证书,并为用户提供单点登录的用户体验?安全断言标记语言(SAML )。 2. 应如何为用户账户自动化提供云计算服务以及自动化用户开通及移除的流程?服务供应标记语言(SPML )。 3. 应如何为用户账户提供合适的权限,并为用户管理权限权利?可扩展访问控制标记语言(XACML )。 4. 应如何授权云计算服务X进而在不披露证书的情况下,访问云计算服务Y中的数据?开放式身份认证(OAuth )。 5.7.1.1 安全断言标记语言(SAML) SAML 是最成熟详细且被广泛采用的云计算用户基于浏览器的身份联合单点登录规范族。当用户通过了身份服务的认证后,就可以自由访问在信任域内提供的云计算服务,从而规避云计算专用的单点登录程序。由于SAML 支持代理(单点登录),通过使用基于风险的认证策略,用户可以为某些云计算服务选择实施强认证(多因素认证)。使用机构的IdP (身份提供商)可以很容易实现,支持强认证和委派认证。通过实施强认证技术例如双因子认证,用户不那么容易遭受在互联网上稳步增长的钓鱼攻击。云计算服务的强认证对于保护用户证书不受中间人攻击也是可取的,例如当计算机或浏览器被攻陷而使用户遭受木马和僵尸网络攻击的情况。通过支持委派认证模式的SAML 标准,云计算服务提供商可以对用户机构委派认证策略。简言之,SAML 将使云计算服务提供商无须了解用户的认证需求。 图5-3 描述了如何通过浏览器单点登录到Google Apps 。图片解释了Google 身份联合用户单点登录过程的具体步骤。
1. 机构的用户试图访问在Google 上的应用程序,例如Gmail、Start Pages 或其他Google 服务。 2. Google 生成一个SAML 认证请求。SAML 请求是编码并内嵌到URL (统一资源定位符)中的,机构的IdP 支持单点登录服务。包含用户试图访问的Google 应用程序编码URL 的中继状态参数也同样内嵌在单点登录URL 中。这个中继状态参数的意思是一个不透明的标识符,传回时无须修改和检查。 3. Google 发送到用户浏览器一个重定向URL 。重定向URL 包括编码的SAML 认证请求,这个请求应当提交给机构的IdP 服务。 4. IdP 对SAML 请求编码,并为Google 声明使用者服务(ACS )和用户目标URL (中继状态参数)提取URL 。接下来IdP 认证用户。IdP 可以通过询问有效的登录证书或者检查有效会话cookie 来认证用户。 5. IdP 生成SAML 答复,包含着认证用户的用户名。按照SAML 2.0 规范,这个答复是使用合作伙伴公共和私有DSA/RSA 密钥,采用了数字签名。 6. IdP 编码SAML 答复以及中继状态参数,并返回这个信息到用户浏览器。IdP 提供一个机制,是浏览器将这个信息提交Google 声明使用者服务。例如,IdP 可以内嵌SAML 答复以及目标URL 并生成表格,然后提供一个按钮,用户点击后将该表格提交给Google 。IdP 也可以在页面上包含JavaScript ,自动把表格提交给Google 。 7. Google 声明使用者服务使用IdP 公钥验证SAML 答复。如果成功验证答复,声明使用者服务将重定向用户到目标URL 。 8. 用户重定向到目标URL ,并登录Google Apps。 5.7.1.2 服务供应标记语言(SPML) SPML 是基于XML 框架,由结构化信息标准推动组织开发,用来在合作组织间交换用户、资源和服务供应信息。SPML 是新兴的标准,可以帮助机构为云计算服务自动化用户身份的开通(例如,运行在客户网站的应用程序或服务向Salesforce.com 提出请求,请求创建新账户)。当可以采用SPML 时,机构应当用它来开通云计算服务中用户账户和配置文件。如果支持SPML ,软件即服务(SaaS )提供商便可以做到“即时开通”,为新用户实时创建账户(相对于预注册用户)。在这种模式下,云计算服务提供商从SPML 的标记中提取新用户的属性,迅速创建SPML 信息,并把需求传递给用户开通服务,以在云计算用户数据库中增加用户身份。 SPML 的采用可以使用户或系统的访问以及享有的权利实现标准化和自动化,这样用户不会锁定在私有解决方案中。 图5-4 描述了一个SPML 用例,其中人力资源系统使用SPML 请求向云计算中的用户开通系统提出请求。在图中,人力资源系统记录(请求当局)是一个SPML Web 服务客户端,在云计算服务提供商处与SPML 用户开通服务的供应商相互作用,而后者负责在云计算服务中提供用户开通服务(用户开通服务目标)。
5.7.1.3 可扩展访问控制标记语言(XACML) XACML 是一个由结构化信息标准推动组织批准的,通用的基于XML 的对于策略管理和访问决断的访问控制语言。它为通用策略语言提供一个XML 模式,用来保护任何类型的资源和在这些资源上制定访问决策。XACML 标准不仅仅为策略语言提供模式,还提出了一个用来管理策略和访问判断的处理环境模式。XACML 中还规定了应用程序环境能用来与决策点交流的请求/答复协议。访问请求的答复也使用XML 进行了规定。 大多数应用程序(网络应用程序或其他)都有内建授权模块,基于分配给用户的权限,授予或拒绝对特定应用程序功能或资源的访问。在集中管理的身份及访问管理架构中,应用程序特定授权模式(竖井)使得跨越所有应用程序中说明个人用户的访问权限变得十分困难。因此,XACML 的目标是提供一个标准化语言、访问控制方法和跨越所有应用程序的策略执行,实施一个共同的授权标准。这些授权决策是基于集中在用户角色和工作职能的各种授权策略和规则。简言之,实施一个共同认可的标准允许统一的授权政策(例如,用户对多个服务实施一个共同认可的标准策略)。 图5-5 描述了在各种有着特有角色(授予权限)的卫生保健参与者之间的交互,对在卫生保健应用程序中存储的敏感病例进行访问。
图5-5说明了关于XACML 用例的具体步骤: 1. 卫生保健应用程序管理各种访问各种病例要素的医院同事(医师、注册护士、护士助手和卫生保健主管)。这个应用程序依赖于政策执行点(PEP ),并把请求交给政策执行点。 2. 政策执行点实际上是应用程序环境的接口。它接受访问请求,并在决策点(PDP)的帮助下评估这些请求,然后允许或者拒绝对资源(卫生保健记录)的访问。 3. 政策执行点把请求送到决策点。决策点是访问请求的主要决定点,决策点从可用的信息资源收集所有必需信息,并决定给予什么样访问。决策点应当位于可信网络并使用强访问控制策略,例如在用企业防火墙保护的企业可信网络。 4. 在评估之后,决策点把XACML 答复送到政策执行点处。 5. 政策执行点履行其责任,执行决策点的授权决定。 需求答复协议使用XACML 信息并作为其有效负载,通过这种方式实现交互。这样,使用XACML 来传达策略的评估,应对访问请求的决定。 5.7.1.4 开放式身份认证(OAuth) OAuth 是新兴的认证标准,允许用户与另一个云计算服务提供商共享其存储在其他云计算服务提供商的私有资源(例如照片、视频、联系人名单和银行账户),而不用出示认证信息(例如用户名和密码)。OAuth 是个开放式协议,其建立的目标是通过安全应用程序编程接口(API )实现授权,为台式机、移动及网络应用程序提供一个简单和标准的方法。对于应用程序开发者,OAuth 是用来发布和交互受保护数据的方法。对于云计算服务提供商,OAuth 提供了为用户访问他们在其他提供商上的数据的方法,同时保护他们的账户证书。 在企业内,OAuth 可能扮演重要的角色,它通过部署Web 服务单点登录模式,在可信服务提供商处实现单点登录。OAuth 促使一对服务授权进行交互,而不需要一个明确的身份联合结构。就像OpenID (开放式认证系统),OAuth 的出发点是以消费者为中心的世界,并帮助用户服务访问跨提供商处的用户数据。Google 已发布了OpenID 和OAuth 协议的混合版本,以较少的步骤结合了授权和认证流程并加强了可用性。Google 的GData API 宣布支持OAuth 。(GData 也支持安全断言标记语言以实现浏览器单点登录。) 图5-6 描述了用户、合作伙伴网络应用程序、Google 服务以及终端用户的交互顺序。
1. 用户网络应用程序联络Google 授权服务,要求对一个或多个Google 服务的请求令牌。 2. Google 对内容进行验证,确保网络应用程序已注册,并以一个未授权请求令牌进行回复。 3. 网络应用程序引用请求令牌,重定向终端用户到Google 授权页面。 4. 在Google 授权页面上,用户被提示要求登录用户账户(为了验证),然后授予或者拒绝网络应用程序对其Google 服务数据的有限访问。 5. 用户决定是否授予或拒绝网络应用程序的访问。如果用户拒绝访问,用户将被重定向到Google 页面而不是返回网络应用程序。 6. 如果用户授予访问,认证服务将重定向用户到通过Google 注册的网络应用程序指定页面。重定向包括已授权的请求令牌。 7. 网络应用程序传送请求到Google 授权服务,更换授权请求令牌为访问令牌。 8. Google 验证请求并返回有效的访问令牌。 9. 网络应用程序传递请求到正在讨论的Google 服务。签署请求,请求包含访问令牌。 10. 如果Google 服务识别令牌,将会提供被请求的数据。 5.7.2 身份及访问管理对用户的标准、协议和规范 下列协议和规范是面向用户云计算服务的,与企业云计算立场无关。 5.7.2.1 开放式认证系统(OpenID) OpenID 是对用户认证和访问控制的开放的分散标准,允许用户使用相同的数字身份登录许多服务,例如使用支持OpenID 的服务实现单点登录用户体验。因此,OpenID 代替了使用登录用户名和密码的常用登录过程,而允许用户登录一次便获得对多个软件系统资源的访问。OpenID 主要针对由互联网公司提供的用户服务,这些公司包括Google 、eBay 、Yahoo! 、Microsoft 、AOL 、BBC 、PayPal 等。由于信任问题,采用OpenID 作为企业用途(例如非用户用途)几乎是不存在的。一些研究发现OpenID 可能加速钓鱼攻击,而这可能会损害用户证书。 5.7.2.2 信息卡(Information card) 信息卡是对于网络身份的另一个开放标准。这个标准自身是由信息卡基金会管理的,信息卡基金会的督导委员包括来自Google 、Microsoft 、PayPal 、Oracle Novell 和Equifax 的代表。基金会声明其任务是“保障数字身份的安全并取代传统的登录和密码,以此减少身份盗窃的事件”。这个标准的目标是为用户提供一个安全、一致、可抵御钓鱼攻击的用户接口,而并不需要用户名和密码。人们为了获得方便,可以使用信息卡数字身份跨越多个站点,而不用担心他们的登录信息陷入危险(类似使用OpenID 身份跨越多个站点)。信息卡协议是设计使用在高价值的情况下,例如银行业,对钓鱼攻击的抵御以及对安全认证机制例如智能卡的支持是关键的业务需求。 任何服务提供商都可以实施、发布和接受信息卡(也称作i-card )。信息卡是使用Web 服务联合语言(WS-* )规范构建的,而不是HTTP 重定向,因此与OpenID 相比信息卡的规范要明显复杂。虽然这个系统对于身份盗窃和钓鱼攻击提供了非常大的保护,但还是存在一些阻止实现其任务的问题。系统的最大问题是,只有用户使用的网站参与并接受信息卡,系统才能工作。如果不存在这个联系,信息卡便是没有用的。随着越来越多的网站接受信息卡,系统也将变得越来越有用,但即便到了那个时候,使用也还是有限定的。例如,用户可以使用由Microsoft Windows Live ID 发行的受监管的信息卡,提供对大多数Microsoft 的网站的单点登录,这些网站包括MSDN 、TechNet 、Live 和Connect 。 5.7.2.3 开放式身份认证(OATH) OATH 是IT 行业领导者协作的成果,为了提供可以跨越网络上所有用户及所有设备并广泛适用的强认证的参考架构。这个方案的目标是解决三个主要的认证方法: 基于用户识别模块(SIM )的认证(使用全球移动通信系统GSM/ 通用无线分组业务GPRS 用户识别模块)。 基于公钥基础设施(PKI )的认证(使用X.509v3 证书)。 基于一次性密码(OTP )的认证。 OATH 认证协议利用了行之有效的基础设施组件,例如目录服务器和远程认证拨号用户服务(RADIUS )服务器,并利用了身份联合协议。 5.7.2.4 开放式身份认证应用程序接口(OpenAuth) OpenAuth 是美国在线(AOL )专有的应用程序接口(API ),它使得第三方网站和应用程序可以通过网站和程序认证美国在线以及美国在线即时消息(AIM )用户。使用这种认证方法,美国在线即时消息或者美国在线的注册用户可以登录第三方网站或者应用程序,并访问美国在线服务或者在美国在线服务上搭建的新的服务。根据美国在线的材料,OpenAuth 应用程序接口提供下面的功能: 一种登录的安全方法。用户证书不会暴露给用户登录的网站或者应用程序。 一种控制允许哪个网站读取隐私或者受保护的内容的安全方法。 当用户在同意页面选择了总是允许时,自动授予权限。 当网站或者应用程序试图读取任何隐私或者受保护的内容时(例如,对好友信息、即时消息和相册读取的单独同意请求),征求用户同意的提示。 无须创建一个新的账户便可以访问其他非美国在线网站(支持美国在线OpenAuth 应用程序接口的网站)。 考虑到该协议的私有性,云计算团体没有把OpenAuth 作为开放式标准,OpenAuth 在美国在线网络之外也不被采用。 5.7.3 企业和用户认证标准及协议的对比 鉴于在认证、授权、身份联合协议及标准方面流通着许多“开放式*”这样的缩写词,表5-1 试图从对开放标准支持的角度,以及在企业和用户云计算服务的相关性的角度对它们进行比较。 表5-1 :身份及访问管理标准和协议的比较
| ||||||||||||||||||||||||||||
[返回] |