doi：10.3969/j.issn.1671-1122.2012.08.022
云计算中的身份认证技术研究
余幸杰1,2，高能1,2，江伟玉1
（1.中国科学院信息工程研究所信息安全国家重点实验室，北京 100093；
2.中国科学院研究生院，北京 100049）
文章对目前云计算中典型的身份认证技术——基于安全凭证的身份认证和基于单点登录的联摘 要：
合认证，进行了系统的综述，并对现有的几种方案进行了深入的分析和比较，提出了一些改进意见。
身份认证；安全凭证；单点登录；OpenID；SAML关键词：
中图分类号：TP393.08 文献标识码：A 文章编号：1671-1122（2012）08-0071-04
Research on the Authentication in Cloud Computing
YU Xing-jie1,2, GAO Neng1,2, JIANG Wei-yu1
( 1. State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences,
Beijing 100093, China )
Abstract: We analyze the security-credentials-based authentication and the single sign-on-based federated authentication, and make a comparison among the popular schemes. In addition, we present some methods and suggestions to improve the authentication mechanisms in cloud computing.
Key words: identity authentication; security credential; single sign-on; OpenID; SAML
0 引言
用户对计算资源的控制程度大大降低。因此，云计算的发展带来了海量的访问认证请求和复杂的用户权限管理，推动了身份认证技术的不断发展。云计算中出现了基于多种安全凭证的身份认证技术。随着云计算的普及，云端存储了大量的用户敏感数据，一旦用户身份被仿冒，就很容易造成隐私和敏感数据的泄露。传统的基于单一凭证的身份认证技术已经不能满足用户的安全需求，许多云服务提供商都采用了基于多种安全凭证的身份认证技术，但是目前缺少对这些技术的总结和比较。因此，本文对目前云计算中广泛使用的基于多种凭证的身份认证技术进行了总结。云计算中有着复杂的身份认证场景，API调用源鉴别就是一种典型的认证场景。根据API种类的不同，API调用源鉴别使用的安全凭证也有所不同。本文重点阐述了基于不同安全凭证的API调用源鉴别机制。云计算的发展推动了基于单点登录的联合身份认证技术的发展。联合身份认证技术的发展使用户可以通过单一账号登录多个云服务，极大地简化了用户操作，基于单点登录方案可以很好地实现联合身份认证机制。本文详细介绍了目前使用最为广泛的单点登录方案——OpenID协议和基于SAML的单点登录方案，并进行了分析和比较，提出了一些改进意见。
1 基于安全凭证的身份认证
传统的身份认证，往往基于用户名和口令。面对云计算中复杂的应用环境和角色定义，以用户名和口令作为单一安全凭证的方式，已经不能满足云计算中多种认证场景的安全需求。因此，云计算中出现了多种安全凭证，本节分析了Google、Amazon、Microsoft等云计算环境中使用的多种基于安全凭证的身份认证技术，并进行了比较。
1.1 基于安全凭证的API调用源鉴别
在云计算环境中，云服务提供商为用户提供了大量的API访问资源和使用服务，用户使用云服务的实质就是调用API。与传统的本地API调用不同，云计算中的API调用通常是基于Web的调用，除了资源所有者以外，其他合法第三方也可以通过API调用实现对资源的访问。而且，在调用一个API时，大多数情况下会涉及对敏感数据的获取。因此，基于安全凭证对API请求
收稿时间：2012-07-12基金项目：中国科学院战略性先导专项子课题海云信息安全共性关键技术研究[XDA06010702]、国家自然科学基金[70890084/G021102、61003274]作者简介：余幸杰（1988-），女，湖南，硕士研究生，主要研究方向：云安全；高能（1976-），女，陕西，副研究员，主要研究方向：云安全、PKI技术、网络与系统安全；江伟玉（1987-），女，湖南，博士研究生，主要研究方向：云计算安全。
71
的发起者进行身份鉴别是云计算中必不可少的安全技术。API调用的源鉴别中，API调用请求的发起者可以是云用户也可以是某个部署在云环境中的应用程序，为了叙述的简洁，本小节将API调用请求的发起者统称为用户。
文件。证书文件中包含该证书的公钥和其他一些元数据。私钥文件中包含用户对API请求进行数字签名的私钥，由用户唯一持有，验证服务器不保存该私钥文件的任何副本。
当用户发起一次API请求时，使用证书私钥对该请求进行数字签名，并将证书文件包含在API请求包中一起发送给验证服务器。验证服务器收到API请求后，检查接收到的用户证书与服务器端的证书备份是否匹配，并对数字签名进行验证。
1.1.2 Access Key与证书的比较
Access Key基于对称密码学中的概念，而证书基于公钥密码学。使用Access Key对API请求进行签名和验证的过
图1 基于安全凭证的API调用源鉴别基本流程
程，与使用证书作为安全凭证的模式相比，更为方便。但是，Access Key安全凭证使用对称密码算法，用户和验证服务器共享Secret Access Key。因此，恶意的云服务提供商可以利用用户的Secret Access Key伪造对API的调用，进而依据伪造的API调用作为计费标准向用户多收取费用。以证书作为安全凭证，基于非对称密码算法，可以有效的避免上述情况的发生。
基于安全凭证的API调用源鉴别的基本流程如图1所示。首先，用户利用安全凭证中的密钥对API请求的部分内容创建一个数字签名，并将该签名和API请求包一起发送给云服务提供商。然后，验证服务器对该签名进行验证，鉴别API调用源是否合法。如果签名通过了验证，用户才能对相应的API进行访问；否则，返回拒绝访问的信息。1.1.1 API调用源鉴别中的安全凭证
用户使用何种类型的安全凭证取决于请求的API的类型，目前主要有Access Key和证书两种类型的安全凭证。
1）Access Key安全凭证。Access Key由Access Key ID和Secret Access Key组成。用户在创建账户时，由云服务提供商为该账户分配Access Key。另外，对于某些部署在云环境中的应用程序，可以由该应用程序的用户管理员为其域内的用户创建Access Key 。例如，使用Google App Engine的应用程序管理员，可以通过API控制台为其用户创建Access Key。Access Key ID用于标识API请求的发起者，通常包含在API请求中。每个Access Key ID都关联一个Secret Access Key，API请求的发起者使用Secret Access Key对该请求进行数字签名，用户与验证服务器共享Secret Access Key。
当用户发起一次API请求时，使用Secret Access Key为该请求创建一个数字签名，并将Access Key ID包含在API请求包中一起发送给验证服务器。验证服务器收到API请求时，根据Access Key ID查找对应的Secret Access Key，对数字签名进行验证。
2）证书安全凭证。证书是指一个X.509证书，可以由云服务提供商为用户生成数字证书及私钥文件，也可以由用户自己通过第三方工具（如Open SSL等）生成。如果用户使用自己生成的证书作为安全凭证，必须在发起API请求之前将证书上传至验证服务器，该证书不需要由特定的CA签发，只要语法和密码逻辑正确，并且在有效期内，就会被验证服务器认定为合法证书。X.509证书包括一个证书文件和相应的私钥
[1]
1.2 多因素认证
除了在API调用源鉴别中使用了多种安全凭证之外，用户在登录云计算平台或者某个云服务时，可以根据自身的安全需求，在使用传统的标准安全凭证的基础上附加使用多种安全凭证，这样的用户登录机制采用了多因素身份认证技术。
多因素认证机制中，用户首先提供用户名和口令，然后提供验证码，验证码由云服务提供商支持的多因素认证设备生成。认证设备可以是手机、电脑等用户本身拥有的设备，用户通过手机短信、电话接收验证码，或者通过手机、电脑上运行的身份验证应用程序生成验证码[7]；也可以是云服务提供商专门提供给用户的动态口令卡。
许多云服务提供商都支持上述两类认证设备。如果使用手机、电脑等作为认证设备，这些设备本身很可能存有用户云服务账户的口令。所以，如果想要保证更强的安全性，用户应当使用专用动态口令卡。不过，一些云服务提供商基于手机、电脑等非专用认证设备的多因素认证服务是免费提供给用户的，基于专门的动态口令卡的多因素认证服务则需要收取一定的费用[8]。所以，用户在选择多因素认证方案时需要综合考虑安全性和经济性的要求。
2 基于单点登录的联合身份认证
除了第二节中介绍的基于多种安全凭证的身份认证技术，云计算中另一种迅速发展的身份认证技术是基于单点登录（SSO, Single Sign-On）的联合身份认证技术。随着云计算的发展和普及，用户往往使用了许多不同的云服务提供商的云
服务，拥有了大量不同的口令，很容易造成口令的混淆与遗忘。
联合身份认证技术就是为了解决这一问题，用户只需要在使用某个云服务时登录一次，就可以访问所有相互信任的云平台，而不需要重复注册和登录多个账号。单点登录方案是实现联合身份认证的有效手段，目前许多云服务提供商都支持基于单点登录的联合认证。本节介绍了两种典型的单点登录实现方案：OpenID协议和基于SAML的单点登录，并对两种方案进行了比较和讨论。
XML的开放标准，用于在不同的安全域中请求认证和交换认证数据[11]。SAML是一种抽象的框架，可以基于该框架实现不同的具体应用，如单点登录、会话初始化、授权等。基于SAML可以很好的实现单点登录，在基于SAML的单点登录方案中，用户通过用户代理向SAML资源提供者请求Web资源，一个SAML资源提供者需要确定用户的身份，就会通过用户代理向SAML身份提供者（IDP, Identity Provider）发送认证信息。这里的SAML资源提供者相当于OpenID2.0协议中的RP，SAML身份提供者相当于OpenID2.0协议中的OP。
根据不同的安全需求和应用需求，可以基于SAML部署实现不同的单点登录方案。
2.1 OpenID协议
OpenID是一个以用户为中心的身份识别框架，以统一的身份标识来唯一的标记用户身份[9]，用户使用自己的身份标识登录支持OpenID协议的各个网站。用户可以自己建立一个OpenID服务网站，也可以选择一个可信任的OpenID服务网站，完成OpenID的注册。注册完成后，用户对应于一个唯一的URI，口令则被安全的存储在一个OpenID服务网站中。
OpenID2.0协议是OpenID协议的最新版本[10]，其中用户代理是终端用户的代理，通常为可执行HTTP协议的web浏览器；OpenID依赖方是支持用户使用OpenID登录的网络应用；OpenID提供商是用户注册OpenID的网站，对用户的URI进行认证，并将结果返回给RP，进行认证过程如下：
1）用户通过UA向RP提供身份标识，通常为HTTP或HTTPS形式的URI或者XRI格式。2）RP对身份标识进行标准化，依靠标准的身份标识完成自动发现。自动发现的过程包括：确定该用户的OP的URL地址，以及该OP支持的OpenID认证协议版本。3）RP与OP建立关联: RP和OP之间使用Diffie-Hellman密钥交换协议协商共享密钥。OP用协商的密钥对消息进行签名，RP验证这些消息，这可以省略每次请求/响应后续的验证签名的请求。这种关联过程是可选过程，OpenID2.0协议允许RP直接向OP请求认证，并在OP返回认证结果后，向OP发起签名验证请求。4）RP将用户重定向到OP服务器，并带上认证请求参数。5）OP服务器直接从用户浏览器中读取cookie，对用户进行认证，避免向RP泄露认证细节。大多数OP服务器都为用户提供一个页面，选择允许或者拒绝来自RP的认证请求。6）OP服务器通过将用户重定向到RP的方式发送认证请求的回应，确保RP和OP服务器在认证请求/回应过程中没有直接通讯。OP服务器在重定向参数中指明本次认证是否通过。7）RP校验重定向参数，检查认证结果，包括：检查返回的URL与之前请求认证的URL是否一致，验证自动发现的信息与回应信息是否匹配，检查nonce参数判断是否遭受了重放攻击，并用步骤3中协商的密钥验证签名或者重新发起一个签名验证请求。
2.3 OpenID协议与基于SAML的单点登录的比较和讨论
OpenID协议和基于SAML的单点登录方案，在实现单点登录时的流程和功能十分类似，我们对两种方案从用户身份标识、OP/IDP发现机制、安全、用户体验等方面进行了比较。2.3.1 用户身份标识和OP/IDP自动发现
OpenID协议中明确说明和指定了用户身份标识为“HTTP:”或者“HTTPS:”URI，因此，在使用HTTP或HTTP/TLS与OP进行通信时，可以直接使用用户的身份标识[12]。SAML为协议层提供了多种身份标识类型，不同的方案可以独立的规定便于控制和使用的用户身份标识类型。
OpenID协议中明确规定了OP/IDP发现机制，因为规定了用户标识是URI或XRI格式，PR执行OP自动发现时，根据用户标识，调用相应的XRDS文档或者尝试基于HTML的自动发现[10]。SAML标准支持多种自动发现机制，基于SAML的单点登录方案可以根据需求，灵活的设计自动发现机制[11]。
从这点来看，如果为了实现更广泛的联合身份认证，可以选择OpenID协议，该协议的首要目的就是方便用户。如果想在企业内部或者较少的互相信任的安全域内部署单点登录方案，可以选择基于SAML的单点登录方案，并自行规定方案内使用的身份标识类型，最大限度的符合自身的安全需求和应用需求。2.3.2 安全性分析
在OpenID2.0版本中，指定了一些安全措施，包括：密钥建立、消息签名、验证机制以及SSL/TLS加密通道。但是，在使用OpenID2.0部署单点登录方案时，这些安全措施都是可选项，并没有要求必须采取这些安全保障。SAML标准明确规定了某些健壮的安全措施和遵从性要求，基于SAML的单点登录方案可以根据具体需求灵活部署，因此基于SAML的单点登录方案可以实现很强的安全性。
1）网络钓鱼
从遭遇网络钓鱼的角度考虑，OpenID2.0协议中，RP和OP在建立关联时，使用匿名Diffie-Hellman密钥协商[10]，参
73
2.2 基于SAML的单点登录
SAML(Security Assertion Markup Language)是一种基于
与协商的一方都不知道另一方的具体身份，因此，在遭到中间人攻击时，OP或者RP都很难察觉到遭遇了网络钓鱼。因此，OpenID2.0协议需要增加一些基于PKI技术的消息签名机制。如果基于SAML部署单点登录方案时，采用与OpenID协议相同的初始化和发现技术以及相同的身份标识，那么也会面临相同的网络钓鱼风险。不过，由于SAML可以使用基于公钥密码体制的消息签名[11]，在部署单点登录方案时，可以使用这些签名机制抵御网络钓鱼。
2）消息签名
OpenID2.0协议中如果RP和OP没有建立关联，则RP需要在收到认证结果之后向OP请求验证签名
[10]
及该账号目前登录的云服务，并且用户可以通过该插件，分别管理该账号对不同的云服务的登录和退出。
3 结束语
本文对云计算中主流的身份认证与授权技术从基于安全凭证的身份认证和基于单点登录的联合身份认证两个方面进行了归纳和介绍。同时，我们还对现有技术从多个角度进行了比较和分析，并提出了一些改进措施。本文对大多数云服务提供商采用的主流身份认证技术进行了比较全面的分析和研究，但是，却没有对某些云服务提供商采用的并未广泛应用的身份认证技术进行探讨。在下一步的工作中，我们将在已有基础上，围绕某些云服务中采用的具有自身特色的身份认证 ）技术，展开进一步的分析和研究。（责编 程斌
。RP向OP
发送OP的签名请求验证时，虽然发送的是签过名的消息，但该请求却没有进行签名，因此，很容易遭到UA或者用户系统中恶意代码的篡改。OpenID2.0协议通过SSL/TLS加密通道来抵御这种中间人攻击[10]，但由于 SSL/TLS加密通道中传输的信息由UA处理时是未加密的，这一安全措施并不能有效抵御来自UA或者用户系统的攻击。相较而言，SAML标准则支持对所有的消息进行数字签名，并对具体应用明确规定了必须或者应当对SAML断言本身进行数字签名，同时还支持TSL/SSL加密通信[11]。
3）安全设计灵活性
由于OpenID认证协议是一个具体的协议，因此很难将其某部分认证协议或安全机制用于其它环境，而可以进行自主设计和部署的安全细节也有限。SAML标准的安全特征则设计为模块化可用，安全特征制定在底层的SAML断言和SAML消息中。所以，基于SAML的单点登录方案可以根据需求设计灵活的安全细节。2.3.3 用户体验
OpenID协议设计的首要目标是改善用户体验，而SAML标准设计的最初目的是保证安全。因此，OpenID协议虽然在安全性方面不如基于SAML的单点登录方案严格和灵活，但是却因为标准化、具体化的设计，为更多的云服务系统的互相信任提供了方便，可以很好的简化用户操作，优化用户体验。
然而，推广基于OpenID协议的单点登录仍然存在一些障碍。根据相关调查统计，许多用户并不了解OpenID协议的实现细节，因此拒绝使用基于该协议的单点登录。用户的担忧主要集中在几个方面：误以为自己的口令会被所有互相信任的系统共享；对账号的登出机制存在误解；以及登录某个云服务时，会不会导致其它云服务的自动登录等。对此，我们可以采取其他的技术进一步改善用户体验，比如，开发适用于客户端浏览器的插件，实时显示用户当前使用的OpenID账号，以
参考文献：
[1] Schaudin.com. Machine Translation Add-On for RC-WinTrans [EB/OL]. http://rc-wintrans.s,.chaudin.com/addons/MT/,February 07, 2012/June 07,2012.
[2]Amazon web services. Amazon Elastic Compute Cloud[EB/OL]. http://aws.amazon.com/documentation/ec2/,June 01 ,2012/ June 07,2012.
[3] Amazon web services. AWS Identity and Access Management [EB/OL]. http://aws.amazon.com/documentation/iam/, May 08 ,2010/ June 07,2012.
[4] Amazon web services. Amazon Simple Storage Service [EB/OL]. http://aws.amazon.com/documentation/s3/, March 01 ,2006/ June 07,2012.
[5]Charlie Kaufman, Ramanathan Venkatapathy. Windows AzureTM Security Overview [EB/OL]. http://news.softpedia.com/news/Free-Windows-Azure-Security-Overview-Whitepaper-Released-151892.shtml, August,2010/ June 07,2012.
[6] Mcrosoft. Windows Azure Security Notes [EB/OL]. http://blogs.msdn.com/b/usisvde/archive/2012/03/09/windows-azure-security-best-practices-part-3-identifying-your-security-frame.aspx, 2012.[7]Google. Google App Engine[EB/OL]. http://code.google.com/intl/zh-CN/appengine/docs/[8] Amazon web services. AWS Multi-Factor Authentication [EB/OL]. http://aws.amazon.com/mfa/, 2012.
[9] Eldon, Eric. Single sign-on service OpenID getting more usage [EB/OL]. http://venturebeat.com/2009/04/14/single-sign-on-service-openid-getting-more-usage/, April 25, 2009/ June 07,2012.
[10]OpenID.net. OpenID Authentication 2.0 specification - Final [EB/OL]. http://openid.net/specs/openid-authentication-2_0.html, December 5, 2007/ June 07, 2012.
[11]OASIS Standard. SAML V2.0 [EB/OL]. http://docs.oasis-open.org/security/saml/v2.0/, March, 2005/ June 07,2012.
[12] J. Hodges. Technical Comparison: OpenID and SAML - Draft 07a[EB/OL]. http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html, July 3, 2009/ June 07,2012.
doi：10.3969/j.issn.1671-1122.2012.08.022
云计算中的身份认证技术研究
余幸杰1,2，高能1,2，江伟玉1
（1.中国科学院信息工程研究所信息安全国家重点实验室，北京 100093；
2.中国科学院研究生院，北京 100049）
文章对目前云计算中典型的身份认证技术——基于安全凭证的身份认证和基于单点登录的联摘 要：
合认证，进行了系统的综述，并对现有的几种方案进行了深入的分析和比较，提出了一些改进意见。
身份认证；安全凭证；单点登录；OpenID；SAML关键词：
中图分类号：TP393.08 文献标识码：A 文章编号：1671-1122（2012）08-0071-04
Research on the Authentication in Cloud Computing
YU Xing-jie1,2, GAO Neng1,2, JIANG Wei-yu1
( 1. State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences,
Beijing 100093, China )
Abstract: We analyze the security-credentials-based authentication and the single sign-on-based federated authentication, and make a comparison among the popular schemes. In addition, we present some methods and suggestions to improve the authentication mechanisms in cloud computing.
Key words: identity authentication; security credential; single sign-on; OpenID; SAML
0 引言
用户对计算资源的控制程度大大降低。因此，云计算的发展带来了海量的访问认证请求和复杂的用户权限管理，推动了身份认证技术的不断发展。云计算中出现了基于多种安全凭证的身份认证技术。随着云计算的普及，云端存储了大量的用户敏感数据，一旦用户身份被仿冒，就很容易造成隐私和敏感数据的泄露。传统的基于单一凭证的身份认证技术已经不能满足用户的安全需求，许多云服务提供商都采用了基于多种安全凭证的身份认证技术，但是目前缺少对这些技术的总结和比较。因此，本文对目前云计算中广泛使用的基于多种凭证的身份认证技术进行了总结。云计算中有着复杂的身份认证场景，API调用源鉴别就是一种典型的认证场景。根据API种类的不同，API调用源鉴别使用的安全凭证也有所不同。本文重点阐述了基于不同安全凭证的API调用源鉴别机制。云计算的发展推动了基于单点登录的联合身份认证技术的发展。联合身份认证技术的发展使用户可以通过单一账号登录多个云服务，极大地简化了用户操作，基于单点登录方案可以很好地实现联合身份认证机制。本文详细介绍了目前使用最为广泛的单点登录方案——OpenID协议和基于SAML的单点登录方案，并进行了分析和比较，提出了一些改进意见。
1 基于安全凭证的身份认证
传统的身份认证，往往基于用户名和口令。面对云计算中复杂的应用环境和角色定义，以用户名和口令作为单一安全凭证的方式，已经不能满足云计算中多种认证场景的安全需求。因此，云计算中出现了多种安全凭证，本节分析了Google、Amazon、Microsoft等云计算环境中使用的多种基于安全凭证的身份认证技术，并进行了比较。
1.1 基于安全凭证的API调用源鉴别
在云计算环境中，云服务提供商为用户提供了大量的API访问资源和使用服务，用户使用云服务的实质就是调用API。与传统的本地API调用不同，云计算中的API调用通常是基于Web的调用，除了资源所有者以外，其他合法第三方也可以通过API调用实现对资源的访问。而且，在调用一个API时，大多数情况下会涉及对敏感数据的获取。因此，基于安全凭证对API请求
收稿时间：2012-07-12基金项目：中国科学院战略性先导专项子课题海云信息安全共性关键技术研究[XDA06010702]、国家自然科学基金[70890084/G021102、61003274]作者简介：余幸杰（1988-），女，湖南，硕士研究生，主要研究方向：云安全；高能（1976-），女，陕西，副研究员，主要研究方向：云安全、PKI技术、网络与系统安全；江伟玉（1987-），女，湖南，博士研究生，主要研究方向：云计算安全。
71
的发起者进行身份鉴别是云计算中必不可少的安全技术。API调用的源鉴别中，API调用请求的发起者可以是云用户也可以是某个部署在云环境中的应用程序，为了叙述的简洁，本小节将API调用请求的发起者统称为用户。
文件。证书文件中包含该证书的公钥和其他一些元数据。私钥文件中包含用户对API请求进行数字签名的私钥，由用户唯一持有，验证服务器不保存该私钥文件的任何副本。
当用户发起一次API请求时，使用证书私钥对该请求进行数字签名，并将证书文件包含在API请求包中一起发送给验证服务器。验证服务器收到API请求后，检查接收到的用户证书与服务器端的证书备份是否匹配，并对数字签名进行验证。
1.1.2 Access Key与证书的比较
Access Key基于对称密码学中的概念，而证书基于公钥密码学。使用Access Key对API请求进行签名和验证的过
图1 基于安全凭证的API调用源鉴别基本流程
程，与使用证书作为安全凭证的模式相比，更为方便。但是，Access Key安全凭证使用对称密码算法，用户和验证服务器共享Secret Access Key。因此，恶意的云服务提供商可以利用用户的Secret Access Key伪造对API的调用，进而依据伪造的API调用作为计费标准向用户多收取费用。以证书作为安全凭证，基于非对称密码算法，可以有效的避免上述情况的发生。
基于安全凭证的API调用源鉴别的基本流程如图1所示。首先，用户利用安全凭证中的密钥对API请求的部分内容创建一个数字签名，并将该签名和API请求包一起发送给云服务提供商。然后，验证服务器对该签名进行验证，鉴别API调用源是否合法。如果签名通过了验证，用户才能对相应的API进行访问；否则，返回拒绝访问的信息。1.1.1 API调用源鉴别中的安全凭证
用户使用何种类型的安全凭证取决于请求的API的类型，目前主要有Access Key和证书两种类型的安全凭证。
1）Access Key安全凭证。Access Key由Access Key ID和Secret Access Key组成。用户在创建账户时，由云服务提供商为该账户分配Access Key。另外，对于某些部署在云环境中的应用程序，可以由该应用程序的用户管理员为其域内的用户创建Access Key 。例如，使用Google App Engine的应用程序管理员，可以通过API控制台为其用户创建Access Key。Access Key ID用于标识API请求的发起者，通常包含在API请求中。每个Access Key ID都关联一个Secret Access Key，API请求的发起者使用Secret Access Key对该请求进行数字签名，用户与验证服务器共享Secret Access Key。
当用户发起一次API请求时，使用Secret Access Key为该请求创建一个数字签名，并将Access Key ID包含在API请求包中一起发送给验证服务器。验证服务器收到API请求时，根据Access Key ID查找对应的Secret Access Key，对数字签名进行验证。
2）证书安全凭证。证书是指一个X.509证书，可以由云服务提供商为用户生成数字证书及私钥文件，也可以由用户自己通过第三方工具（如Open SSL等）生成。如果用户使用自己生成的证书作为安全凭证，必须在发起API请求之前将证书上传至验证服务器，该证书不需要由特定的CA签发，只要语法和密码逻辑正确，并且在有效期内，就会被验证服务器认定为合法证书。X.509证书包括一个证书文件和相应的私钥
[1]
1.2 多因素认证
除了在API调用源鉴别中使用了多种安全凭证之外，用户在登录云计算平台或者某个云服务时，可以根据自身的安全需求，在使用传统的标准安全凭证的基础上附加使用多种安全凭证，这样的用户登录机制采用了多因素身份认证技术。
多因素认证机制中，用户首先提供用户名和口令，然后提供验证码，验证码由云服务提供商支持的多因素认证设备生成。认证设备可以是手机、电脑等用户本身拥有的设备，用户通过手机短信、电话接收验证码，或者通过手机、电脑上运行的身份验证应用程序生成验证码[7]；也可以是云服务提供商专门提供给用户的动态口令卡。
许多云服务提供商都支持上述两类认证设备。如果使用手机、电脑等作为认证设备，这些设备本身很可能存有用户云服务账户的口令。所以，如果想要保证更强的安全性，用户应当使用专用动态口令卡。不过，一些云服务提供商基于手机、电脑等非专用认证设备的多因素认证服务是免费提供给用户的，基于专门的动态口令卡的多因素认证服务则需要收取一定的费用[8]。所以，用户在选择多因素认证方案时需要综合考虑安全性和经济性的要求。
2 基于单点登录的联合身份认证
除了第二节中介绍的基于多种安全凭证的身份认证技术，云计算中另一种迅速发展的身份认证技术是基于单点登录（SSO, Single Sign-On）的联合身份认证技术。随着云计算的发展和普及，用户往往使用了许多不同的云服务提供商的云
服务，拥有了大量不同的口令，很容易造成口令的混淆与遗忘。
联合身份认证技术就是为了解决这一问题，用户只需要在使用某个云服务时登录一次，就可以访问所有相互信任的云平台，而不需要重复注册和登录多个账号。单点登录方案是实现联合身份认证的有效手段，目前许多云服务提供商都支持基于单点登录的联合认证。本节介绍了两种典型的单点登录实现方案：OpenID协议和基于SAML的单点登录，并对两种方案进行了比较和讨论。
XML的开放标准，用于在不同的安全域中请求认证和交换认证数据[11]。SAML是一种抽象的框架，可以基于该框架实现不同的具体应用，如单点登录、会话初始化、授权等。基于SAML可以很好的实现单点登录，在基于SAML的单点登录方案中，用户通过用户代理向SAML资源提供者请求Web资源，一个SAML资源提供者需要确定用户的身份，就会通过用户代理向SAML身份提供者（IDP, Identity Provider）发送认证信息。这里的SAML资源提供者相当于OpenID2.0协议中的RP，SAML身份提供者相当于OpenID2.0协议中的OP。
根据不同的安全需求和应用需求，可以基于SAML部署实现不同的单点登录方案。
2.1 OpenID协议
OpenID是一个以用户为中心的身份识别框架，以统一的身份标识来唯一的标记用户身份[9]，用户使用自己的身份标识登录支持OpenID协议的各个网站。用户可以自己建立一个OpenID服务网站，也可以选择一个可信任的OpenID服务网站，完成OpenID的注册。注册完成后，用户对应于一个唯一的URI，口令则被安全的存储在一个OpenID服务网站中。
OpenID2.0协议是OpenID协议的最新版本[10]，其中用户代理是终端用户的代理，通常为可执行HTTP协议的web浏览器；OpenID依赖方是支持用户使用OpenID登录的网络应用；OpenID提供商是用户注册OpenID的网站，对用户的URI进行认证，并将结果返回给RP，进行认证过程如下：
1）用户通过UA向RP提供身份标识，通常为HTTP或HTTPS形式的URI或者XRI格式。2）RP对身份标识进行标准化，依靠标准的身份标识完成自动发现。自动发现的过程包括：确定该用户的OP的URL地址，以及该OP支持的OpenID认证协议版本。3）RP与OP建立关联: RP和OP之间使用Diffie-Hellman密钥交换协议协商共享密钥。OP用协商的密钥对消息进行签名，RP验证这些消息，这可以省略每次请求/响应后续的验证签名的请求。这种关联过程是可选过程，OpenID2.0协议允许RP直接向OP请求认证，并在OP返回认证结果后，向OP发起签名验证请求。4）RP将用户重定向到OP服务器，并带上认证请求参数。5）OP服务器直接从用户浏览器中读取cookie，对用户进行认证，避免向RP泄露认证细节。大多数OP服务器都为用户提供一个页面，选择允许或者拒绝来自RP的认证请求。6）OP服务器通过将用户重定向到RP的方式发送认证请求的回应，确保RP和OP服务器在认证请求/回应过程中没有直接通讯。OP服务器在重定向参数中指明本次认证是否通过。7）RP校验重定向参数，检查认证结果，包括：检查返回的URL与之前请求认证的URL是否一致，验证自动发现的信息与回应信息是否匹配，检查nonce参数判断是否遭受了重放攻击，并用步骤3中协商的密钥验证签名或者重新发起一个签名验证请求。
2.3 OpenID协议与基于SAML的单点登录的比较和讨论
OpenID协议和基于SAML的单点登录方案，在实现单点登录时的流程和功能十分类似，我们对两种方案从用户身份标识、OP/IDP发现机制、安全、用户体验等方面进行了比较。2.3.1 用户身份标识和OP/IDP自动发现
OpenID协议中明确说明和指定了用户身份标识为“HTTP:”或者“HTTPS:”URI，因此，在使用HTTP或HTTP/TLS与OP进行通信时，可以直接使用用户的身份标识[12]。SAML为协议层提供了多种身份标识类型，不同的方案可以独立的规定便于控制和使用的用户身份标识类型。
OpenID协议中明确规定了OP/IDP发现机制，因为规定了用户标识是URI或XRI格式，PR执行OP自动发现时，根据用户标识，调用相应的XRDS文档或者尝试基于HTML的自动发现[10]。SAML标准支持多种自动发现机制，基于SAML的单点登录方案可以根据需求，灵活的设计自动发现机制[11]。
从这点来看，如果为了实现更广泛的联合身份认证，可以选择OpenID协议，该协议的首要目的就是方便用户。如果想在企业内部或者较少的互相信任的安全域内部署单点登录方案，可以选择基于SAML的单点登录方案，并自行规定方案内使用的身份标识类型，最大限度的符合自身的安全需求和应用需求。2.3.2 安全性分析
在OpenID2.0版本中，指定了一些安全措施，包括：密钥建立、消息签名、验证机制以及SSL/TLS加密通道。但是，在使用OpenID2.0部署单点登录方案时，这些安全措施都是可选项，并没有要求必须采取这些安全保障。SAML标准明确规定了某些健壮的安全措施和遵从性要求，基于SAML的单点登录方案可以根据具体需求灵活部署，因此基于SAML的单点登录方案可以实现很强的安全性。
1）网络钓鱼
从遭遇网络钓鱼的角度考虑，OpenID2.0协议中，RP和OP在建立关联时，使用匿名Diffie-Hellman密钥协商[10]，参
73
2.2 基于SAML的单点登录
SAML(Security Assertion Markup Language)是一种基于
与协商的一方都不知道另一方的具体身份，因此，在遭到中间人攻击时，OP或者RP都很难察觉到遭遇了网络钓鱼。因此，OpenID2.0协议需要增加一些基于PKI技术的消息签名机制。如果基于SAML部署单点登录方案时，采用与OpenID协议相同的初始化和发现技术以及相同的身份标识，那么也会面临相同的网络钓鱼风险。不过，由于SAML可以使用基于公钥密码体制的消息签名[11]，在部署单点登录方案时，可以使用这些签名机制抵御网络钓鱼。
2）消息签名
OpenID2.0协议中如果RP和OP没有建立关联，则RP需要在收到认证结果之后向OP请求验证签名
[10]
及该账号目前登录的云服务，并且用户可以通过该插件，分别管理该账号对不同的云服务的登录和退出。
3 结束语
本文对云计算中主流的身份认证与授权技术从基于安全凭证的身份认证和基于单点登录的联合身份认证两个方面进行了归纳和介绍。同时，我们还对现有技术从多个角度进行了比较和分析，并提出了一些改进措施。本文对大多数云服务提供商采用的主流身份认证技术进行了比较全面的分析和研究，但是，却没有对某些云服务提供商采用的并未广泛应用的身份认证技术进行探讨。在下一步的工作中，我们将在已有基础上，围绕某些云服务中采用的具有自身特色的身份认证 ）技术，展开进一步的分析和研究。（责编 程斌
。RP向OP
发送OP的签名请求验证时，虽然发送的是签过名的消息，但该请求却没有进行签名，因此，很容易遭到UA或者用户系统中恶意代码的篡改。OpenID2.0协议通过SSL/TLS加密通道来抵御这种中间人攻击[10]，但由于 SSL/TLS加密通道中传输的信息由UA处理时是未加密的，这一安全措施并不能有效抵御来自UA或者用户系统的攻击。相较而言，SAML标准则支持对所有的消息进行数字签名，并对具体应用明确规定了必须或者应当对SAML断言本身进行数字签名，同时还支持TSL/SSL加密通信[11]。
3）安全设计灵活性
由于OpenID认证协议是一个具体的协议，因此很难将其某部分认证协议或安全机制用于其它环境，而可以进行自主设计和部署的安全细节也有限。SAML标准的安全特征则设计为模块化可用，安全特征制定在底层的SAML断言和SAML消息中。所以，基于SAML的单点登录方案可以根据需求设计灵活的安全细节。2.3.3 用户体验
OpenID协议设计的首要目标是改善用户体验，而SAML标准设计的最初目的是保证安全。因此，OpenID协议虽然在安全性方面不如基于SAML的单点登录方案严格和灵活，但是却因为标准化、具体化的设计，为更多的云服务系统的互相信任提供了方便，可以很好的简化用户操作，优化用户体验。
然而，推广基于OpenID协议的单点登录仍然存在一些障碍。根据相关调查统计，许多用户并不了解OpenID协议的实现细节，因此拒绝使用基于该协议的单点登录。用户的担忧主要集中在几个方面：误以为自己的口令会被所有互相信任的系统共享；对账号的登出机制存在误解；以及登录某个云服务时，会不会导致其它云服务的自动登录等。对此，我们可以采取其他的技术进一步改善用户体验，比如，开发适用于客户端浏览器的插件，实时显示用户当前使用的OpenID账号，以
参考文献：
[1] Schaudin.com. Machine Translation Add-On for RC-WinTrans [EB/OL]. http://rc-wintrans.s,.chaudin.com/addons/MT/,February 07, 2012/June 07,2012.
[2]Amazon web services. Amazon Elastic Compute Cloud[EB/OL]. http://aws.amazon.com/documentation/ec2/,June 01 ,2012/ June 07,2012.
[3] Amazon web services. AWS Identity and Access Management [EB/OL]. http://aws.amazon.com/documentation/iam/, May 08 ,2010/ June 07,2012.
[4] Amazon web services. Amazon Simple Storage Service [EB/OL]. http://aws.amazon.com/documentation/s3/, March 01 ,2006/ June 07,2012.
[5]Charlie Kaufman, Ramanathan Venkatapathy. Windows AzureTM Security Overview [EB/OL]. http://news.softpedia.com/news/Free-Windows-Azure-Security-Overview-Whitepaper-Released-151892.shtml, August,2010/ June 07,2012.
[6] Mcrosoft. Windows Azure Security Notes [EB/OL]. http://blogs.msdn.com/b/usisvde/archive/2012/03/09/windows-azure-security-best-practices-part-3-identifying-your-security-frame.aspx, 2012.[7]Google. Google App Engine[EB/OL]. http://code.google.com/intl/zh-CN/appengine/docs/[8] Amazon web services. AWS Multi-Factor Authentication [EB/OL]. http://aws.amazon.com/mfa/, 2012.
[9] Eldon, Eric. Single sign-on service OpenID getting more usage [EB/OL]. http://venturebeat.com/2009/04/14/single-sign-on-service-openid-getting-more-usage/, April 25, 2009/ June 07,2012.
[10]OpenID.net. OpenID Authentication 2.0 specification - Final [EB/OL]. http://openid.net/specs/openid-authentication-2_0.html, December 5, 2007/ June 07, 2012.
[11]OASIS Standard. SAML V2.0 [EB/OL]. http://docs.oasis-open.org/security/saml/v2.0/, March, 2005/ June 07,2012.
[12] J. Hodges. Technical Comparison: OpenID and SAML - Draft 07a[EB/OL]. http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html, July 3, 2009/ June 07,2012.