一种以用户为中心的移动互联网身份管理及认证方法

1.一种以用户为中心的移动互联网身份管理及认证方法，用于用户通过用户端上的用户端应用程序连接到Web站点时进行认证，其特征在于：在用户端设置负责管理用户公私钥对和身份信息的用户身份代理，记为IdA；用户的身份信息采用虚拟卡向用户预登录的Web站点提供，所述虚拟卡为用户提供的自建卡或第三方身份提供者提供的托管卡；
采用自建卡的注册过程包括以下步骤，
第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP；
第二步，RP将所需要的身份信息发送给用户端应用程序；
第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后向用户提示要提交给RP的身份信息，用户授权提交后进入第四步；
第四步，IdA请求与RP建立SSL安全连接；
第五步，RP与IdA建立SSL安全连接，RP产生一个随机数nonce1，发送给IdA；在建立SSL安全连接的协商过程中，通信双方交换各自的公钥；
第六步，IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密会话密钥K；随后，将用户端和RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要运算，并通过用户端的私钥进行签名，生成身份令牌Token；最后将身份令牌Token、IdA自己的公钥、以及RP需要的身份信息通过会话密钥加密后作为自签名的身份信息一起发送给RP；
自签名的身份信息表示为SSL{EPubkRP{K},rp,c,nonce1,nonce2,EK{PubkC,claims,SigPrikC{SHA1(rp,c,nonce1,PubkC,claims)}}}，其中rp和c分别表示RP和用户端的标识，claims表示发送给RP的身份信息，PubkRP表示RP的公钥，K表示会话密钥，PubkC表示用户端的公钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce1是RP发送的随机数，nonce2是IdA产生的随机数，SHA1表示所采用的hash算法，SigPrikC{}表示利用用户端的私钥对消息进行签名，SSL{}表示以SSL方式发送；
第七步，RP收到IdA所发送自签名的身份信息之后，利用用户端的公钥验证数字签名，如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成一个User ID，同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA；IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则记录UserID，将UserID与CardID建立关联，允许用户端应用程序访问RP的授权资源；
采用托管卡的注册过程包括以下步骤，
第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP；
第二步，RP将所需要的身份信息发送给用户端应用程序；
第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后进入第四步；
第四步，IdA将用户端定向到IdP，用户在IdP进行身份认证；所述IdP为身份提供方；
第五步，身份认证成功后，IdP给IdA发送一个用IdP私钥签名的身份令牌Token，以及IdP的公钥和RP需要的身份信息；身份令牌Token中包括RP需要的身份信息，IdP产生的随机数nonce及IdP和RP的标识，并用IdP的私钥签名；
第六步，IdA将IdP发送给RP的身份信息显示给用户，在用户授权提交后，请求与RP建立SSL安全连接；
第七步，RP与IdA建立SSL连接，并产生一个随机数nonce1发送给IdA；
第八步，IdA产生一个会话密钥，将IdP签发的身份令牌Token、IdP的公钥以及产生的随机数nonce2，以会话密钥加密后将信息发送给RP；
具体发送的信息格式为SSL{EPubkRP{K},rp，c,nonce1,nonce2,EK{nonce1,nonce2,idp，c,nonce,claims,PubKIdP,SigprivkIdP(SHA1(idp，rp,nonce,claims))}}，其中，rp和c、idp分别表示RP和用户端、IdP的标识，claims表示发送给RP的身份信息，PubkRP表示RP的公钥，K表示IdA生成的会话密钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce是IdP产生的随机数，nonce1是RP发送的随机数，nonce2是IdA产生的随机数，PubKIdP表示IdP的公钥；SHA1表示所采用的hash算法，SigprivkIdP表示利用IdP的私钥对消息进行签名，SSL{}表示以SSL方式发送；
第九步，RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签名验证成功，则获得用户端发送的身份信息，允许用户访问RP的授权资源，并为该用户生成一个UserID，同时利用会话密钥将UserID和nonce2加密发给IdA；IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是则记录UserID，将UserID与CardID建立关联，允许用户端应用程序访问RP的授权资源。
2.如权利要求1所述以用户为中心的移动互联网身份管理及认证方法，其特征在于：
采用自建卡注册后，再次登录RP时，IdA无需再取得RP所需要的身份信息，仅需产生一个随机数，并将RP分配给用户的User ID、随机数和RP的标识通过用户的私钥进行签名，生成认证令牌，并产生会话密钥进行加密，通过SSL的方式发送给RP。
3.如权利要求1所述以用户为中心的移动互联网身份管理及认证方法，其特征在于：
采用托管卡注册后，再次登录RP时，IdA自动显示用户首次进行身份认证的卡，并在用户确认后与 IdP通信，获得IdP颁发的认证令牌；RP通过该认证令牌鉴别用户的身份。

一种以用户为中心的移动互联网身份管理及认证方法\n技术领域\n[0001] 本发明属于互联网技术领域，特别是涉及一种新的基于虚拟卡的以用户为中心的移动互联网身份管理及认证。\n背景技术\n[0002] 从身份管理的发展历程看，大概经历了三个发展阶段：集中式的身份管理，联合式身份管理和分布式身份管理。\n[0003] 集中式的身份管理的特点是用户的身份信息由域内的身份提供方（Identity Provider，IdP）进行管理，并且只在该域内使用，如Kerberos, 微软的Cardspace。用户在该域内有一个唯一的身份标识，通过这个数字标识，可以使用该域内所有的服务。集中式的身份管理便于在一个特定的范围内使用，无法满足跨域环境下身份认证的需求，于是便出现了联合式的身份认证。\n[0004] 联邦式身份认证的特点是存在多个身份提供方，每个身份提供方负责一个域内用户身份信息的管理。为使用户能够利用本域的唯一身份访问其它域的服务，而不用在各个域内的IdP都进行注册，各IP必须事先建立信任关系， 然后通过事先建立的信任关系及用户身份信息映射，实现跨域的身份认证。联邦式身份管理方式的典型代表，如OpenSSO、Shibboleth。联邦式身份管理方式要求用户在身份认证前，各IP必须建立信任关系，这对于开放、分布式的互联网来说，是难于实现的，于是以Web站点中心的分布式身份管理方式开始被采用。\n[0005] 以Web站点中心的分布式身份管理中，用户在各个Web服务提供方注册，然后通过用户名/密码访问该Web服务提供方的服务。这种方式，简单灵活，却造成了目前用户身份信息隐私泄露、一个用户多个身份标识，以及由于用户名/密码登录方式而造成的网络钓鱼攻击等日益严重的身份管理问题。\n[0006] 为解决日益严峻的互联网身份泄露问题，近年来以用户为中心的分布式身份管理模式（见有关文献）被提出。以用户为中心(User-Centric)的身份管理包含了两层含义：\n一、用户的一些身份隐私信息不再由 Web站点（Relying Party，RP）保存，而是由用户自己保存或者保存在可信的第三方身份提供者（Identity Provider, IdP） ，从而避免了存储在Web 站点的用户身份信息的泄露。此外，这些分布式的 IdP 之间不需要事先建立信任关系，用户可以自己选择任何一个信任的 IdP 存储身份信息。二、用户身份信息的揭漏必须经过用户的授权，并满足用户的策略，即用户身份信息的使用是用户可控的。\n[0007] 有 关 文 献：K. Cameron and M.B.Jones.2006.Design Rationale behind the Identity Metasystem Architecture,Microsoft Corporation,Redmond,Wash. K.Bhargavan, C. Fournet, A. D. Gordon, and N. Swamy. 2008.Verified \nimplementations of the information card federated identity-management protocol. In ASIACCS '08, pages 123-135. ACM. Gail-Joon Ahn, Moonam Ko, Mohamed Shehab. Privacy-enhanced User-Centric Identity Management. IEEE international Conference on Communication, 2009. PP 40-48。\n[0008] 目前，美国和欧盟已经启动了多个身份管理的项目，如SWIFT，PRIME等，研究互联网中以用户为中心的身份信息管理技术。比较有代表性的以用户为中心的身份管理技术是以URI作为身份标识OpenID。\n[0009] OpenID是一个分布式的Internet身份认证技术。OpenID利用一个带有IP地址的URI作为身份标识。当用户需要在其它Web站点认证时，只需要提供URI表示的身份标识,该Web站点便可直接重定向到URI指示的IP服务器进行身份认证。一旦用户通过了该IP的身份认证,那么用户就可以直接访问Web站点了。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。\n[0010] 我国对于身份管理的研究工作（见有关文献），主要集中在联邦式身份管理技术方面。此外，2008年，刘润达等对OpenID技术进行了介绍。2010年，信息网络安全公安部重点实验室（公安部第三研究所），对英国的电子身份证制度进行了研究。从现状看，尚缺乏对以用户为中心的分布式身份管理技术的深入研究。\n[0011] 有关文献：刘润达; 王卷乐; 杜佳. OpenID:一种开放的数字身份标识管理及其认证框架. 计算机应用与软件,2008(12):41-46.Cardspace在校园网身份认证系统中的应用研究，电子科技大学硕士论文，2011李建； 沈昌祥； 韩臻； 何永忠； 刘毅；身份管理研究综述. 计算机工程与设计 ,2009(7):1365-1370.黄道丽. 国家网络空间可信身份制度研究 以英国电子身份管理(eIDM)制度为个案. Proceedings of 2010 Asia-Pacific Conference on Information Network and Digital Content Security（2010APCID）. 信息网络安全公安部重点实验室（公安部第三研究所）。\n[0012] 经过前期的研究，我们发现以用户为中心的身份管理机制尚存在一些问题。\nOpenID是互联网分布式身份管理的典型代表，虽然OpenID通过URI的形式表示用户身份，简单易用，但是由于缺乏对IdP的身份确认，使得任何人都可以建立一个网站提供OpenID验证服务，导致其信任度不高。此外，OpenID系统中，用户的身份信息全部交给IdP管理和存储，使得IdP容易成为身份认证系统的瓶颈。最后，利用OpenID在第三方站点认证时，需要在表单中输入自己的用户名和IdP域名，这也在一定程度上泄露了用户的隐私。\n[0013] 综上所述，以用户为中心的身份管理作为一种新技术，国内外对于这种新的身份管理技术的研究刚刚起步，在体系结构、身份信息的隐私保护以及互操作性等方面缺乏足够的理论研究和技术支持，导致目前互联网用户身份信息泄漏的问题仍然难以解决，为此，必须进一步研究以用户为中心的身份管理技术，从理论和技术上解决互联网用户身份信息泄漏、密码疲劳及钓鱼攻击等的问题。\n发明内容\n[0014] 针对上述问题，本发明提出一种基于虚拟卡的以用户为中心的移动互联网身份管理及认证方法。该方法可用于移动互联网的身份管理及认证，解决移动平台在访问Web站点时采用用户名/密码方式带来的密码输入低效、密码疲劳、钓鱼攻击等问题。\n[0015] 本发明的技术方案为一种以用户为中心的移动互联网身份认证方法，用于用户通过用户端上的用户端应用程序连接到Web站点时进行认证，在用户端设置负责管理用户公私钥对和身份信息的用户身份代理，记为IdA；用户的身份信息采用虚拟卡向用户预登录的Web站点提供，所述虚拟卡为用户提供的自建卡或第三方身份提供者提供的托管卡；\n[0016] 采用自建卡的注册过程包括以下步骤，\n[0017] 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP；\n[0018] 第二步，RP将所需要的身份信息发送给用户端应用程序；\n[0019] 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后向用户提示要提交给RP的身份信息，用户授权提交后进入第四步；\n[0020] 第四步，IdA请求与RP建立SSL安全连接；\n[0021] 第五步，RP与IdA建立SSL安全连接，RP产生一个随机数nonce1，发送给IdA；在建立SSL安全连接的协商过程中，通信双方交换各自的公钥；\n[0022] 第六步，IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密会话密钥K；随后，将用户端和RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要运算，并通过用户端的私钥进行签名，生成身份令牌Token；最后将身份令牌Token、IdA自己的公钥、以及RP需要的身份信息通过会话密钥加密后作为自签名的身份信息一起发送给RP；\n[0023] 自签名的身份信息表示为SSL{EPubkRP{K},rp,c,nonce1,nonce2,EK{PubkC,claims,SigPrikC (SHA1(rp,c,nonce1,PubkC,claims)} }，其中rp和c分别表示RP和用户端的标识，claims表示发送给RP的身份信息， PubkRP表示RP的公钥，K 表示会话密钥，PubkC 表示用户端的公钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce1是RP发送的随机数，nonce2是IdA产生的随机数， SHA1表示所采用的hash算法，SigPrikC{}表示利用用户端的私钥对消息进行签名，SSL{}表示以SSL方式发送；\n[0024] 第七步，RP收到IdA所发送自签名的身份信息之后，利用用户端的公钥验证数字签名，如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成一个User ID，同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA；IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则记录UserID，将UserID与CardID建立关联，允许用户端应用程序访问RP的授权资源；\n[0025] 采用托管卡的注册过程包括以下步骤，\n[0026] 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP；\n[0027] 第二步，RP将所需要的身份信息发送给用户端应用程序；\n[0028] 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后进入第四步；\n[0029] 第四步，IdA将用户端定向到IdP，用户在IdP进行身份认证；\n[0030] 第五步，身份认证成功后，IdP给IdA发送一个用IdP私钥签名的身份令牌Token，以及IdP的公钥和RP需要的身份信息；身份令牌Token中包括RP需要的身份信息，IdP产生的随机数nonce及IdP和RP的标识，并用IdP的私钥签名；\n[0031] 第六步，IdA将IdP发送给RP的身份信息显示给用户，在用户授权提交后，请求与RP建立SSL安全连接；\n[0032] 第七步，RP与IdA建立SSL连接，并产生一个随机数nonce1发送给IdA；\n[0033] 第八步，IdA产生一个会话密钥，将IdP签发的身份令牌Token、IdP的公钥以及产生的随机数nonce2，以会话密钥加密后将信息发送给RP；\n[0034] 具体发送的信息格式为SSL{EPubkRP{K},rp，c, nonce1, nonce2,EK{nonce1,nonce2, idp，c, nonce, claims,PubKIdP ,SigprivkIdP(SHA1(idp，rp, nonce, claims) )}}，其中，rp和c、idp分别表示RP和用户端、IdP的标识，claims表示发送给RP的身份信息，PubkRP表示RP的公钥，K表示IdA生成的会话密钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce是IdP产生的随机数，nonce1是RP发送的随机数，nonce2是IdA产生的随机数， PubKIdP表示IdP的公钥；SHA1表示所采用的hash算法，SigprivkIdP表示利用IdP的私钥对消息进行签名，SSL{}表示以SSL方式发送；\n[0035] 第九步，RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签名验证成功，则获得用户端发送的身份信息，允许用户访问RP的授权资源，并为该用户生成一个UserID，同时利用会话密钥将UserID和nonce2加密发给IdA；IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是则记录UserID，将UserID与CardID建立关联，允许用户端应用程序访问RP的授权资源。\n[0036] 而且，采用自建卡注册后，再次登录RP时，IdA无需再取得RP所需要的身份信息，仅需产生一个随机数，并将RP分配给用户的User ID、随机数和RP的标识通过用户的私钥进行签名，生成认证令牌，并产生会话密钥进行加密，通过SSL的方式发送给RP。\n[0037] 而且，采用托管卡注册后，再次登录RP时，IdA自动显示用户首次进行身份认证的卡，并在用户确认后与IdP通信，获得IdP颁发的认证令牌；RP通过该认证令牌鉴别用户的身份。\n[0038] 本发明的特点：\n[0039] （1）用户通过身份管理代理来管理和使用自己的身份信息，而不是像OpenID将所有的身份信息交给第三方身份管理机构管理。此外，用户身份信息的提交需要得到用户的授权，从而真正体现了身份管理中以用户为中心以及身份信息用户可控的特点。\n[0040] （2）用户通过公私钥对或数字证书证明其身份，不再依赖于用户名/密码的身份认证方式。\n[0041] （3）如果RP具有合法的数字证书，则可通过身份管理代理验证RP的数字证书，防止钓鱼攻击。\n附图说明\n[0042] 图1是本发明实施例的原理示意图。\n[0043] 图2是本发明实施例的为用户自创建卡身份认证过程图。\n[0044] 图3是本发明实施例的托管卡（第三方卡）身份认证过程图。\n具体实施方式\n[0045] 以下结合附图和实施例详细说明本发明技术方案。\n[0046] 如图1所示，实施例的运行涉及三方，具体运行系统由用户（User）、用户端应用程序（Client Application，通常指浏览器）、身份代理（IdA，Identity Agent）、身份提供者（Identity Provider, IdP）和用户预登录的Web站点(Relying Party, RP)组成。用户、用户端应用程序、身份代理属于用户端一方，用户端应用程序和身份代理设置在用户所使用的用户端设备（如计算机、移动智能设备Mobie Platform等）上。浏览器可以使用任意一款浏览器，IdA是本发明独创设置，具体实施时可采用计算机软件技术实现，例如在Android系统上实现。RP与IdP通常是一个网站，可以采用接入互联网的服务器提供，但需支持虚拟卡身份认证方式。用户端设备与RP、IdP分别通过互联网建立通信连接。\n[0047] 其中关键部分的具体实现说明如下：\n[0048] 1、用户身份代理\n[0049] 用户身份代理（IdA）负责管理用户公私钥对和身份信息，包括用户身份信息的建立、获取、授权、使用和维护。用户可以通过身份管理代理创建自己的身份信息卡（自创建卡），也可以通过虚拟卡（Vcard）的形式管理IdP颁发的身份信息（可称为第三方卡或托管卡）。\n[0050] 通过IdA，用户可以以虚拟卡的形式创建、删除、导入、导出及发送身份信息。用户可以预先创建多张含有不同身份信息内容的虚拟卡。当用户利用RP认证时，选择虚拟卡方式后，浏览器将自动触发IdA，此时用户可选择一张合适的虚拟卡在RP进行身份认证，可以是自创建卡，也可以是托管卡。如果是自建卡，则IdA直接与RP进行通信；如果是托管卡，IdA将与该卡的身份信息提供方（IdP）通信，取得RP需要的身份信息及IdP用其私钥签名的身份令牌，并转发给RP进行身份认证。\n[0051] 2、用户预登录的Web站点\n[0052] 用户预登录的Web站点(Relying Party, RP) 代表用户要进行身份认证的网站，该网站需要支持Vcard身份认证方式。\n[0053] 实施例中，RP采用JSP/Servlet技术，以Tomcat为应用服务器，使用JDK6的Keytool工具生成密钥库。除了用户名/密码登录外，将支持自建卡注册、登录，托管卡注册、登录，已有账户和虚拟卡(自建卡或托管卡)建立关联三种注册使用虚拟卡的方式。\n[0054] 3、身份提供者\n[0055] 身份提供者（Identity Provider, IdP）的主要功能是给用户颁发托管卡以及在用户利用托管卡登录RP的过程中，为用户生成身份令牌。托管卡中主要包含了卡ID和IdP的URL，IdA根据卡中的URL去IdP取得身份令牌。身份令牌采用1024位的RSA非对称算法签名，并通过HTTPS协议进行传输。IdA收到回复消息之后，将解析HTTP报文正文部分取得IdP颁发的身份令牌。\n[0056] 虚拟卡为用户提供的自建卡或第三方提供的托管卡。具体实施时，认证过程可采用计算机软件技术实现自动运行。\n[0057] 用户自创建卡：由用户自己创建，可以包含用户的各种身份信息，可以有很多张，每张卡有一个ID号（CardID），用来登录不同的网站。身份认证的方式主要利用公钥/私钥的方式。用户在安装IdA时， IdA会根据用户的口令自动为用户产生一对公私钥对，用于以后的身份认证。具体自建卡身份认证过程见附图2，其通信流程如下：\n[0058] 第一步：用户端应用程序（浏览器）访问某Web站点。该站点支持虚拟卡(Vcard) 登录,用户选择Vcard方式登录。\n[0059] 第二步：RP将所需要的身份信息发送给浏览器。具体实施时可以Policy的形式发送，Policy表示RP需要的信息，一般包括多个用户属性，如用户名，用户邮箱等等，通常网站的Policy还对信息的格式进行了要求。\n[0060] 第三步：浏览器调用IdA。IdA弹出选卡界面，用户根据RP需要的身份信息选择一张合适的卡（系统也可以根据上述RP需要的身份信息，将满足需要的卡提示给用户）。选卡后，IdA向用户提示要提交给RP的身份信息，用户授权后，身份信息才可提交给RP。当RP需要的身份信息只是所选卡中的部分信息时，从中提取相应信息进行提交即可，不必发送整张卡的所有信息。如果找不到合适的卡，用户也可以相应创建一张。\n[0061] 第四步：IdA请求与RP建立SSL安全连接，其后的通讯过程都将通过SSL方式安全通信。\n[0062] 第五步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL发送给IdA。在建立连接协商的过程中，通信双方将交换各自的公钥。\n[0063] 第六步：IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密该会话密钥K。随后，将用户端和RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要运算，并通过用户端的私钥进行签名，生成身份令牌（Token），同时将Token、自己的公钥、以及RP需要的身份信息通过会话密钥加密后一起发送给RP。\n[0064] 自签名的身份信息表示为SSL{EPubkRP{K},rp,c,nonce1,nonce2,EK{PubkC,claims,SigPrikC (SHA1(rp,c,nonce1,PubkC,claims)} }，其中rp和c分别表示RP和用户端的标识，claims表示发送给RP的身份信息， PubkRP表示RP的公钥，K 表示会话密钥，PubkC 表示用户端的公钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce1是RP发送的随机数，nonce2是IdA产生的随机数， SHA1表示所采用的hash算法，SigPrikC{}表示利用用户端的私钥对消息进行签名，SSL{}表示以SSL方式发送。\n[0065] 第七步：RP收到用户端的IdA所发送自签名的身份信息之后，利用用户端的公钥验证数字签名，如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成一个User ID，同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则记录UserID，将UserID与CardID建立关联。此时用户端的浏览器即可访问RP的授权资源。\n[0066] 成功登陆完成后，可以由IdA记录日志，包括登陆的CardID和相应网站。此后，用户再登录该网站，IdA将自动显示用户首次进行身份认证的卡，用户确认后即可登录RP。此时，用户发送给RP的认证信息与用户首次注册登录有所不同。由于在首次登录该RP之后，RP已经为该用户分配了一个ID（User ID），并保存了该用户的ID和公钥，因此再次登录该RP时，IdA无需再取得RP的policy。此时，IdA仅需产生一个随机数，并将RP分配给用户的User ID、随机数和RP的标识通过用户的私钥进行签名，生成认证令牌，并产生会话密钥进行加密，通过SSL的方式发送给RP。由于该RP已经保存了用户的公钥及ID，因此可以直接通过用户的公钥验证用户的签名信息，以鉴别用户的身份。\n[0067] 具体通信步骤如下：\n[0068] 第一步：用户端应用程序（浏览器）访问某Web站点。\n[0069] 第二步：浏览器调用IdA。IdA在选卡界面中自动显示首次进行身份认证的卡，用户确认此卡。IdA向用户提示要提交给RP的身份信息。用户授权后，IdA将身份信息提交给RP。\n[0070] 第三步：IdA请求与RP建立SSL安全连接，其后的通讯过程都将通过SSL方式安全通信。\n[0071] 第四步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL发送给IdA。\n[0072] 第五步：IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密该会话密钥。随后，将用户端和RP的标识、nonce1、UserID进行摘要运算，并通过用户端的私钥进行签名，生成认证令牌（Token），同时将Token、UserID通过会话密钥加密后一起发送给RP。\n[0073] 具体传送信息表示为SSL{EPubkRP{K},rp,c,nonce1,nonce2,EK{UserID,SigPrikC (SHA1(rp,c,nonce1,UserID ) )} }，其中rp和c分别表示RP和用户端（client）的标识，EK{m}表示用密钥K对消息m加密，PubkRP表示RP的公钥，K 表示会话密钥，SHA1表示所采用的hash算法，SigPrikC表示利用client的私钥进行签名。SSL{ }表示通过安全套接层协议传送信息。\n[0074] 第六步：RP收到用户端的IdA所发送自签名的认证信息之后，利用用户端的公钥验证数字签名，如果签名验证成功，则从发送的信息中取得UserID，与RP端存储的UserID进行比较。如果相同，则可确认用户的身份。同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA 。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则用户浏览器可访问RP的授权资源。\n[0075] 托管卡：身份信息由第三方（IdP）认证后颁发，非用户自己创建颁发。例如电子身份证等。卡中除了用户信息，还需提供认证方的信息，因此具有更高的可信度。用户可利用这些第三方颁发的身份信息登录RP。\n[0076] 托管卡身份认证过程见附图3，其通信流程如下：\n[0077] 第一步：用户端（浏览器）访问某Web站点。该站点支持虚拟卡(Vcard) 登陆，用户选择Vcard方式登陆。\n[0078] 第二步：RP将所需要的身份信息以Policy的形式发送给浏览器。\n[0079] 第三步：浏览器调用IdA。IdA弹出选卡界面，用户根据RP需要的身份信息选择一张合适的卡（系统也可以根据上述RP需要的身份信息，将满足需要的卡提示给用户）。如果找不到合适的卡，用户也可以创建一张。\n[0080] 第四步：IdA将用户端定向到IdP，用户在IdP进行身份认证。\n[0081] 第五步：身份认证成功后，IdP给用户端发送一个用IdP私钥签名的Token，以及IdP的公钥和RP需要的身份信息。Token中包括RP需要的身份信息，IdP产生的随机数nonce及IdP和RP的标识，并用IdP的私钥签名。\n[0082] 第六步：IdA将IdP发送给RP的身份信息显示给用户，用户授权提交该身份信息。\nIdA请求与RP建立SSL安全连接。\n[0083] 第七步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL通道发送给IdA。\n[0084] 第八步：IdA产生一个会话密钥，将IdP签发的身份令牌、IdP的公钥以及产生的随机数，以会话密钥加密，发送给RP。\n[0085] 具体发送的信息格式为SSL{EPubkRP{K},rp，c, nonce1, nonce2,EK{nonce1,nonce2, idp，c, nonce, claims,PubKIdP ,SigprivkIdP(SHA1(idp，rp, nonce, claims) )}}，其中，rp和c、idp分别表示RP和用户端、IdP的标识，claims表示发送给RP的身份信息，PubkRP表示RP的公钥，K表示IdA生成的会话密钥，EPubkRP{K}表示用RP的公钥PubkRP加密密钥K，EK{}表示用密钥K对消息加密，nonce是IdP产生的随机数，nonce1是RP发送的随机数，nonce2是IdA产生的随机数， PubKIdP表示IdP的公钥；SHA1表示所采用的hash算法，SigprivkIdP表示利用IdP的私钥对消息进行签名，SSL{}表示以SSL方式发送。\n[0086] 第九步：RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签名验证成功，则获得用户端发送的身份信息。用户即可通过用户端应用程序访问RP的授权资源，并为该用户生成一个UserID，同时利用会话密钥将UserID和nonce2加密，通过SSL方式发给IdA。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是， 则记录UserID，将UserID与CardID建立关联。此时用户浏览器即可访问RP的授权资源。\n[0087] 成功登陆完成后，可以由IdA记录日志，包括登陆的CardID和相应网站。这是用户第一次利用第三方卡登录某网站的过程，以后用户再登录该网站，IdA将自动显示用户首次进行身份认证的卡，用户确认后，与IdP通信，获得IdP颁发的认证令牌。RP通过该认证令牌鉴别用户的身份。实现时，可以为Token设置生存期，在生存期内，用户可直接利用IdA保存的认证Token登录RP。只在认证Token过期后，IdA才需与IdP通信，再次获得新的认证Token。\n[0088] IdA需要缓存IdP颁发的认证Token、时间戳及nonce值，如果当前请求时间在Token的有效期内，则IdA与RP建立SSL连接，生成会话密钥及随机数nonce1, nonce2，直接将Token发送给RP。RP收到后，需验证Token的来源，并检查Token的有效期。如果Token已经过了有效期，则IdA需要与IdP建立连接，重新获取认证Token。\n[0089] 具体通信流程如下：\n[0090] 第一步：用户端应用程序（浏览器）访问某Web站点。该站点支持虚拟卡(Vcard) 登陆，用户选择Vcard方式登陆。\n[0091] 第二步：浏览器调用IdA。IdA在选卡界面中自动显示首次进行身份认证的卡，用户确认此卡。\n[0092] 第三步：IdA将用户端定向到IdP，用户在IdP进行身份认证。\n[0093] 第四步：身份认证成功后，IdP给IdA发送一个用IdP私钥签名的认证令牌Token。\nToken中包括claims、IdP产生的随机数nonce及IdP和RP的标识，并用IdP的私钥签名。\n[0094] 第五步：IdA将IdP发送给RP的身份信息显示给用户，用户授权提交该身份信息。\nIdA请求与RP建立SSL安全连接。\n[0095] 第六步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL通道发送给IdA。\n[0096] 第七步：IdA产生一个会话密钥，将IdP签发的认证令牌、随机数和UserID，以会话密钥加密，发送给RP。具体发送的信息格式为SSL{EPubkRP{K},rp，c, nonce1, nonce2,EK{nonce1,nonce2, idp,c, nonce, userID ,t,SigprivkIdP(SHA1(idp，rp, nonce,t) )}}，其中userID表示首次注册之后，RP为用户生成的ID。T代表时间戳。其它符号的含义与利用托管卡注册过程相同。\n[0097] 第八步：RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签名验证成功，则首先从获得信息中获得时间戳，判断认证Token是否在有效期内，然后获得UserID，与RP端存储的UserID进行比较。如果相同，则可确认用户的身份。同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA 。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则用户浏览器可访问RP的授权资源。\n[0098] 本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。