专利名称：用于联合单点登录服务的系统、方法和设备的制作方法
技术领域：
本发明一般涉及的是可以提供给多个用户的单点登录服务。更为特别的是，本发明涉及那些为多个使用者提供基于万维网的单点登录服务的装置、系统和方法，其中所述使用者即为移动网络运营商网络的用户。
背景技术：
万维网服务的出现伴随产生了一种允许用户以一种简单便捷的方式来访问所述万维网服务的全新服务，而这种方式就是所谓的单点登录(SSO)。当前的SSO准则规定用户应该能够进行一次验证并且应该准许访问那些由他们预订并且接受这种验证等级的服务。这个准则集中在了方便最终用户这个方面，然而并没有解决终端和网络在实施SSO时遇到的能力方面的问题。因此，当前的发展方向提出了两种实行SSO准则的方法。
在第一种方法，也就是“以终端为中心”的方法中，用户相对于终端进行一次验证，所述终端转而自动追踪一个面向服务的网络接入，并且在没有其他用户参与的情况下以透明方式将恰当的证书提交给请求这种证书的面向服务的网络。
在第二种方法，也就是“以网络为中心”的方法中，用户相对于网络中的验证提供方(AP)来进行一次验证，所述验证提供方转而对用于所述服务的恰当证书进行处理。
当在验证提供方与服务供应商之间存在领域信任关系时，这种所谓的“以网络为中心”的方法是非常合适的，然而在没有这类关系并且终端可以追踪那些为完全不同的领域或服务所执行的验证的时候，以终端为中心的方法将会非常有用。
此外也可以将这两种方法结合起来。网络运营商可以发布那些能够保存在终端或是可存取的读/写卡中的证书，例如数字证书、短期证书、临时票据或令牌。在验证或授权过程中，这些证书将会得到用户的进一步使用。
常规的蜂窝运营商使用了验证服务来授权用户访问所述运营商提供的语音和数据服务。随着蜂窝运营商在价值链中的上升，它们可能会影响到其与自身用户之间的相互信任关系，由此在新兴的商务模型中为各自的用户群体扮演一个验证提供方的全新角色，而在这种新兴的商务模型中，服务域和验证服务属于不同的管理实体。在这一点上，能够提供IP连接和服务这两种访问的运营商还可以为用户提供一个“访问验证SSO”，由此与服务域中的验证一样，在访问等级上执行的验证同样是有效的。这则仅仅是进一步公开本发明目标的起点。
更确切地说，在这里必须对服务域与验证提供方之间的关系以及那些可以提供给用户的服务加以考虑，以便论述以上方法的优缺点。一般来说，验证提供方与提供服务的服务供应商可以同属一个管理域，也可将其委托给一个外部的可信组织或是一个分散联盟。
本发明的一个主要目的是支持用于移动网络运营商(MNO)联盟用户的单点登录(SSO)服务，其中所述用户即为不同服务供应商的使用者。所述SSO服务是以这样一种方式得到支持的，其中用户、移动网络运营商联盟以及与这类联盟中至少一个成员订立协定的服务供应商都是依照本发明而从指定体系和商业参考模型中获取附加益处和增值服务的。
更具体地说，在参考模型协定内部，使用者将会因为具有这种用于访问任何服务供应商(SP)的任何服务的SSO服务而处于一种非常有利的地位。移动网络运营商(MNO)可以向第三方提供SSO服务，尤其是验证和授权，并且还可以通过为各自的移动预订服务增值来保持用户忠诚度，由此所述运营商可以获得收益。最终，服务供应商可以通过一种更为简单和安全的验证授权机制来体验潜在用户即移动用户的增加，其中所述机制根据不同的用户特性而将对于不同机制的支持减至最小。在这种情况下，验证提供方和服务供应商属于不同的管理域。同时，这些分散优点有益于提升一种所谓的移动商务(m-commerce)它被视为是本发明另一个目的。
相关技术上述“以网络为中心”的方法似乎更适合那些包含了服务供应商的使用者的情况，其中所述使用者即为移动网络运营商的用户，而所述移动网络运营商则希望起到验证提供方的作用。然而，在这里参考了一种以网络为中心的常规方法中的SSO服务来论述最接近的已知现有技术，其中所述论述独立于这类充当验证提供方的网络。
例如，Lerner的美国专利申请公开US2002/0010776A1描述了那些用于为验证和授权服务提供单点登录(SSO)型分布式应用服务综合的方法和系统。在这个申请中，相关的教导是在耦合到用户终端的中央服务器从指向第一应用浏览器的用户那里接收到一个第一指示的时候开始的。然后在中央服务器上还接收了来自第一应用浏览器并与用户相对应的一个cookie文件。于是，中央服务器对这个从浏览器中接收的cookie文件进行更新。
cookie文件是一个可变长度数据段并且通常包含了数百个字节。无论这些cookie是处于中央服务器本地还是远端的伙伴站点，它们都是由各个附属万维网服务器中的应用接口库写入、读取和修改的。更具体地说，对接收到的cookie进行更新包含了对cookie文件以及某些预定参数进行比较，并且基于所述比较来对cookie文件进行最终修改。
当在中央服务器上接收到一个来自用户并且表明用户将服务器指向第二应用的第二指示时，中央服务器会将这个经过更新的cookie文件提供给第二应用。
本专利申请规定负责写入、读取和修改cookie文件的应用接口库被配置成在其他应用中对用户进行验证。因此，本领域技术人员很容易发现，所有用户的验证数据和相应功能全都处于各个附属万维网服务器、本地或远程伙伴站点中，这对管理而言是一个附加缺点。特别地，即使使用者受益于SSO服务，但对用户验证而言，在用户将浏览器指向的附属万维网服务器中，在任何一个应用上都采取了特定的操作。由此可以将这种机制视为是验证提供方和服务供应商同属一个管理域的情况的一个实例。
上述教导似乎不适合大型电信系统，在这些系统中包含了移动网络运营商联盟，可能与至少一个联盟成员签约的多个不同服务供应商，以及作为联盟中任何成员的移动用户的大量潜在使用者。
此外，如果用户验证数据和算法是非常敏感的信息，那么MNO是不愿意经由自身场所之外的实体来传播这个信息的。
在Grandcolas等人的欧洲专利申请EP-1089516中描述了用于单点登录型用户访问方法和系统的另一个重要实例，在这个实例中，用户可以使用多个万维网服务器。
该申请描述的是如何在一个第一万维网服务器上对用户进行验证，其中所述第一万维网服务器允许用户选择一个提供预期服务的第二万维网服务器。当用户实际选择了第二万维网服务器的时候，第一万维网服务器将会构造一个经过加密的验证令牌并且将其传送到第二万维网服务器。第二万维网服务器对接收到的令牌进行验证，并且允许用户在第二万维网服务器上具有一个会话。根据所述申请，第一和第二万维网服务器共享一个子域。也就是说，在这个申请的方案中，验证提供方和服务供应商同属一个管理域，其中验证提供方即为第一万维网服务器，而服务供应商则是第二万维网服务器。
这样一来，该申请的教导不能应用于那些验证提供方和服务供应商属于不同管理域的情况。也就是说，在这个申请中，第一万维网服务器即为验证提供方，它是用户对提供服务的第二万维网服务器进行访问所涉及的第一接点。
因此，这种方法似乎不利于在验证提供方与服务供应商属于不同管理域的情况下进行的商业应用。在这种情况下，用户直接访问一个请求验证机构来验证用户的服务供应商，一旦成功执行了验证，则验证机构授权服务供应商为用户提供选定服务。
当前有这样一种已知的解决方案，它表示的是验证提供方与服务供应商属于不同的管理和商业区域的情况，这种解决方案就是Microsoft的。NET护照产品(如http//www.passport.com所述并且在下文中将其简称为“.NET护照”)。这个产品旨在使用一组通用的技术操作原理来构造一个更广阔的因特网信任网络，其中所述技术操作原理对那些支持相应标准的组织而言是开放的。
然而，这种方法并未解决如何构造一个对自身移动用户进行验证的移动网络运营商联盟的问题，其中所述移动用户访问的是与所述联盟中至少一个成员相关联的服务供应商。此外还存在一种旨在成为一个大型因特网验证系统并与.NET护照相类似的方法，该方法是一种基于集中验证机构的封闭式解决方案，由此没有为移动网络运营商和用户提供任何有益处理。
因此，本发明的一个重要目的是提供一种用于构造移动网络运营商(MNO)联盟的系统、装置和方法，其中对那些为联盟中任何MNO的用户提供单点登录(SSO)服务的相关服务供应商(SP)而言，所述联盟充当一个验证机构。由此，本发明的另一个目的是由充当验证机构的联盟在等同或高于移动网络运营商当前使用的层上实现与安全和保密相关联的需求。此外，本发明的另一个目的是根据上述目的的系统、装置和方法并且相对于施动方、作用、关系以及基本使用范例来建立一个结构化的商业参考模型。
发明内容
特别地，上述目的是依照本发明并且通过提供一种为那些访问选定服务供应商的用户提供单点登录的系统、方法和设备来实现的，其中所述用户预订了第一移动网络运营商。
电信系统包括一个属于第一移动网络运营商的第一移动网络，至少一个属于第二移动网络运营商的第二移动网络，以及多个服务供应商中的至少一个服务供应商，其中一旦验证机构为所述至少一个服务供应商验证了所述移动网络运营商的用户，则所述至少一个服务供应商将会向所述用户提供服务。
根据本发明的一个方面，第一移动网络运营商与至少一个第二移动网络运营商符合或属于一个充当验证机构的移动网络运营商的蜂窝电话联盟。
此外，该系统还包括一个属于第一移动网络的验证提供方，其中对于至少一个服务供应商来说，所述验证提供方是联盟中有权验证用户的唯一成员；此外还包括一个属于第二移动网络的验证中介，所述验证中介被调整为进入点，以便从为此目的而与第二移动网络运营商订立协定的这些服务供应商进入所述联盟。在这里，这种类型的协定称为“入口点”协定。
换言之，电信系统包含了用于将一个访问服务供应商的用户重定向到与服务供应商具有这类协定的第二移动网络运营商的验证中介的装置，其中所述用户预订了第一移动网络运营商，并且所述系统包含了用于将这个访问验证中介的用户重定向到用户归属的第一移动网络运营商的验证提供方的装置。此外，电信系统还包含了用于在验证中介上执行用户原籍解析的装置，从而允许服务供应商从属于第一移动网络的验证提供方那里请求关于所述用户的验证声明确认。
特别地，电信系统允许在不涉及验证中介的情况下从那些与第一移动网络运营商订立协定的服务供应商那里直接访问第一移动网络运营商的验证提供方。为此目的，电信系统还包含了用于在没有涉及验证中介的情况下将一个对服务供应商进行访问的用户重定向到用户原籍第一移动网络的验证提供方的装置，其中所述服务供应商与原籍第一移动网络运营商订立了这类协定。此外，这种服务供应商还可以在未曾涉及验证中介的情况下从所述验证提供方那里请求一个关于所述用户的验证声明确认。
通常，上述系统包含了用于将来自一个访问服务供应商用户的单点登录验证请求发布到蜂窝电话联盟中负责为所述服务供应商验证所述用户的验证提供方的装置，其中所述用户是蜂窝电话联盟的一个用户，并且所述系统还包含了用于将接收到的验证助诊文件(artifact)提供给服务供应商的装置。
此外，本发明还提出了一种为访问选定服务供应商的用户提供单点登录服务的方法，其中所述用户预订了第一移动网络运营商，并且每一个选定服务供应商都与一个第二移动网络运营商相关联。该方法包括以下步骤在第一与第二移动网络运营商之间建立一个验证信任关系，由此形成一个移动网络运营商联盟；将所述用户生成的访问请求从选定的服务供应商那里重定向到所述第一移动网络运营商的蜂窝网络；在用户访问请求重定向的所述第一移动网络运营商的验证提供方那里产生一个对访问所述服务供应商的用户有效的验证声明，并且将一个关于所述声明的助诊文件返回给所述用户；请求对从服务供应商传递所述第一移动网络运营商的验证提供方并且包含在用户所给出的助诊文件中的所述验证声明进行确认；以及一旦在服务供应商那里接收到一个成功确认响应，则接受涉及用户的服务访问。
在上述电信系统和方法中，在验证提供方与服务供应商之间借助了一个共享标识来识别用户，其中所述共享标识独立于在用户与蜂窝电话联盟的验证提供方之间使用的验证标识，此外还独立于在用户与服务供应商之间使用的用户标识。
在电信系统内部还具有一个验证中介并且这个验证中介参与了上述方法，所述验证中介包括与预订了第一移动网络运营商的用户进行通信的第一接口装置，以及与关联于第二移动网络运营商的服务供应商进行通信的第二接口装置。在这里可以将这些第一和第二接口装置视为形成了一个中介信道，其中所述中介信道分别允许验证中介将用户重定向到用户原籍网络以及为服务供应商解析用户的原籍网络。这种验证中介可以包括一个万维网前端，该前端包含了分别与用户和服务供应商对接的上述第一和第二接口装置。此外，验证中介还包含了用于存储以各个移动网络运营商为基础的蜂窝电话联盟中的全部验证提供方的存储器，而每一个移动网络运营商则包含在所述蜂窝电话联盟中，并且验证中介包含了用于从存储器中检索用户原籍相关寻址数据的装置。此外，验证中介的万维网前端还包含了用于为那些关联于拥有验证中介的移动网络运营商的服务供应商提供公共密钥架构服务的装置，从而实现了蜂窝电话联盟的安全保密需要，由此实现本发明的另一个目的。
此外，在电信系统内部还具有一个验证提供方并且所述验证提供方法参与了上述方法，其中所述验证提供方包含了一个前向信道和一个后向信道。
这个验证方的前向信道包括一个万维网前端，该前端包含了用于在用户与所述验证提供方之间启用验证会话的第一接口装置。此外，这个前向信道还包含了一个用于对用户的会话状态进行处理的会话管理器和存储器，以及一个用于为用户执行特定验证机制的前端验证服务器。
这个验证提供方的后向信道则包含了一个协议绑定，其中包含了用于在所述验证提供方与用户所访问的服务供应商之间交换那些与用户验证声明相关的信息的第二接口装置。此外，这个后向信道还包含了一个为用户产生验证声明的安全声明标记语言引擎，以及用于保存这些验证声明的存储器。此外，在前向信道与后向信道之间还提供了互通装置，以便为用户生成并保存一个验证声明。
作为具有以上系统、方法和设备即验证中介和验证提供方的另一个优点，在这里提供了一种进行商业活动的方法，其中至少两个移动网络运营商符合或属于一个移动网络运营商联盟，由此在联盟中建立一个支持单点登录服务的验证信任关系。对于那些为联盟中包含的移动网络运营商的用户提供服务的服务供应商而言，所述联盟充当一个验证机构，其中每一个服务供应商都与一个参与联盟的移动网络运营商相关联，以便访问这个联盟。在这种进行商业活动的方法中，每一个移动网络运营商都提供了自己的网络及其相关服务供应商所供应的服务，其中每一个网络都包含了一个用于对该网络中的用户进行验证的验证提供方，以及一个验证中介，用于将相关的服务供应商重定向到一个负责对联盟中的指定用户进行验证的验证提供方。此外，在这种商业活动方法中，每一个服务供应商都被调整成向联盟中包含的任何移动网络运营商的用户提供服务。而服务供应商可以通过一个与服务供应商签订了这类协议的移动网络运营商的公知验证中介来访问联盟，由此与联盟具有验证信任关系。
附图简述通过结合附图来对说明书进行研究，可以清楚了解本发明的上述及其他目的、特征和优点，其中
图1示意性描述了用于单点登录服务的蜂窝电话联盟的结构化商业参考模型。
图2显示的是一个描述了在一种基本情况下实施的对用户进行验证以及授权访问服务供应商所提供的服务的处理的简化顺序图，其中服务供应商与拥有这类用户预定的移动网络运营商签订了一个业务协定。
图3显示的是另一个描述了在一种更普遍的情况下实施的对用户进行验证以及授权访问服务供应商所提供的服务的简化顺序图。在这种情况下，服务供应商与拥有用户预定的移动网络运营商之外的另一个移动网络运营商具有一个业务协定，并且这两个移动网络运营商全都包含在一个蜂窝电话联盟中。
图4概括性介绍了包含一个用户、一个服务供应商，一个验证中介以及一个验证提供方的示范性内部架构和主要接口。
图5A显示的是在用户经由所谓的前向信道访问一个验证提供方(AP)从而发起一个全新验证处理或者在先前执行了有效验证的情况下触发声明处理的时候执行的第一操作序列(I)。
图5B显示的是通过所谓的前向信道而在AP上借助验证后端(下文中将其称为“Auth.B/E”)来对一个先前未曾验证的用户进行验证的第二操作序列(II)。
图5C显示的是第三操作序列(III)，其中通过执行所述序列，可以在发现一个先前经过验证的用户的时候完成一个声明处理，由此具有一个有效会话。
图6给出的是一个示意性组合，其中通过包含图5A到5C中的参考符号而显示了在用户、服务供应商以及验证提供方之间执行的操作序列，其中所述验证提供方对这种在没有预先验证的情况下访问服务供应商的用户进行验证。
图7A给出的是一个示意性组合，其中通过包含图5A和5B中的参考数字而显示了在这种单独的用户验证过程中在用户与验证提供方之间执行的操作序列。
图7B给出的是一个示意性组合，其中通过包含图5A到5C中的参考数字而显示了在用户、服务供应商以及验证提供方之间为已经得到验证并且访问服务供应商的用户所执行的操作序列。
图8描述的依照优选的结构模型而在图3中出现的某些步骤的更详细实施例。
图9描述的依照优选的结构模型而在图3中出现的某些其它步骤的更详细实施例。
图10显示的是在验证提供方那里得到管理的SSO_auth_ID、SSO_MAIN_ID以及SHARED_ID这类标识之间的示范性关系。
优选实施例详述下文描述了用于构造移动网络运营商(MNO)联盟的装置、方法和系统的当前优选实施例，其中对那些为联盟中任何MNO的用户提供服务的相关服务运营商(SP)而言，所述联盟充当一个验证机构。这些优选实施例则是依照本发明提供的结构化商业参考模型并且相对于施动方、作用、关系以及基本使用范例而被描述的。
根据本发明的一个方面，提供了一种用于单点登录(FSSO)服务的蜂窝电话联盟。图1给出的是上文中相对于涉及第一联盟(FFSO-1)的施动方、作用、关系和某些示范性使用范例所描述的结构化商业参考模型。
在图1的参考模型中，施动方即为用户(User@MNO-A，User@MNO-C)、服务供应商(SP-1，SP-2)和用户原籍站点，后者则是保持了用户预定的移动网络运营商(MNO-A，MNO-B，MNO-C)。出于本发明的目的，用户是具有用户标识模块或WAP标识模块(SIM/WIM)以及web/wap浏览器的移动用户；服务供应商即为用户所请求的服务所在的目标；原籍站点则是那些保持用户预定的移动网络运营商。
在图1的参考模型中扮演的角色包括用户(User@MNO-A，User@MNO-C)、目的地站点、验证中介(AB)以及验证提供方(AP)。在这种环境下，用户就是从SP那里请求服务的客户机；而目的地站点则是一个能将指定服务交付客户机的站点，一般来说，对某些服务而言，SP到MNO也可以发挥这种作用；验证中介(1，2)则是旨在充当用于相关SP的通向联盟(SP-1，SP-2)的入口点；验证提供方(4，5，6)则是旨在拥有用户数据并且验证用户信息以及将信息提供给目的地站点的唯一的联盟(FSSO-1)成员。特别地，SP(SP-1，SP-2)始终是经由与之关联的AB(1，2)来访问(S-100，S-200)联盟的。为了简化起见，在这里并未将SP视为是联盟成员，由此将其称为是相关实体。
从商业角度来看，每一个特定MNO(MNO-A，MNO-B，MNO-C)不但向联盟提供了自己的蜂窝网络，而且还提供了很多与之签订特殊协定的相关SP(SP-1，SP-2)。在这里可以经由与每个SP(SP-1，SP-2)签订了协定的MNO(MNO-A，MNO-B)的验证中介(1，2)来访问(S-100，S-200)所述联盟。这一点特别重要，因为蜂窝电话运营商可能希望在加入或创建一个联盟(FSSO-1，FSSO-2)之后仍然保持其与SP制定的业务协定。此外，网络运营商可能会影响到市场中具有牢固地位的相应的SP的服务，而这将会成为关于蜂窝电话多国联盟的范例，其中服务供应商往往与本地运营商签订了服务等级协议(SLA)。
从商业角度来看，支持这个参考模型的基本原理依赖于这样一个事实，那就是由于联盟成员始终对其自身用户起到的是验证提供方的作用，因此所述模型在蜂窝运营商创建或加入联盟的时候为其提供了均等的机会。此外，尽管并非必要，但是对相关的SP而言。联盟成员同样可以对那些来自联盟中其他成员的用户起到验证中介的作用。
更具体地说，验证中介(1，2)负责解析用户的原籍站点。也就是说，AB负责为一个相关SP提供足够的信息，以便能在保持用户预定的MNO与SP之间进行用户数据交换。一旦解析出用户原籍站点，则AB可以将用户重定向到用户原籍站点。作为补充或是选择，AB还可以为与之相关的SP提供公共密钥架构(PKI)服务，从而实现移动网络运营商的安全和保密需要特性。
在进一步描述结构化实体和接口以及支持当前优选实施例的基本原理之前，有必要对图1参考模型中的不同关系进行特别说明。在这点上，用户(User@MNO-A)(User@MNO-C)与他的原籍站点(MNO-A)(MNO-C)具有一种信任关系(R-110，R-120)(R-320)。当用户注册到一个SP(SP-1)(SP-2)时，在用户(User@MNO-A)(User@MNO-C)与SP(SP-1)(SP-2)之间同样存在着直接的信任关系(R-110)(R-120，R-320)。为了清楚起见并且为了简化SP与联盟之间的关系，在这里将每一个SP(SP-1)(SP-2)都视为与唯一的联盟成员具有单独的信任关系(S-100)(S-200)，其中所述唯一成员即为移动网络运营商(MNO-A)(MNO-B)的一个AB(1)(2)，而SP则与所述运营商签订了业务协定。
因此，当用户(User@MNO-A，User@MNO-C)想要使用一个指定的SP(SP-1，SP-2)上的蜂窝SSO服务时，SP会经由AB(1，2)这个SP与蜂窝电话联盟的入口点而将用户请求自动重定向到联盟中一个能够恰当处理用户请求的站点，即AP(4，6)。这样做可以避免SP做出是否应该重定向用户的复杂决定。此外这样做实际上还简化了SP与联盟之间的交互，从而将其对SP的影响减至最小，并且由此提高了其与联盟关联的意愿。在一种更普遍和实际的情况下，SP(SP-2)可能与不同联盟具有信任关系，其中举例来说，所述联盟可以是蜂窝电话联盟(FSSO-1)以及电子银行联盟(FSSO-2)。
在本发明的另一个实施例中，与某个MNO(MNO-A)相关联的SP(SP-1)不需要通过这类MNO的一个AB(1)来访问拥有用户(User@MNO-A)预定的MNO中的AP(4)，其中所述用户请求了这种SP(SP-1)中的服务。这样做特别有利于MNO(MNO-A)与相关SP(SP-1)之间的信任关系(R-110)，特别地，它还对网络接入和性能进行了优化。
虽然这只是另一个实施例，一般来说，由于所有那些希望起到验证中介作用的原籍站点也是联盟成员，因此它们与联盟的所有成员都具有信任关系。如上所述，SP可以将所有用户重定向到它的入口点，也就是蜂窝电话联盟内部的一个蜂窝运营商(MNO)或是一个原籍站点。因此，验证中介(AB)需要知道所有的联盟原籍站点。
然而，AB通常不了解联盟中各个原籍站点的用户，因为这样做要求每一个AB都能填充联盟的所有用户，由此需要提供用于用户容量和可用性控制的附加装置。然而，通过通读依照本发明描述的当前优选实施例就可以了解，具有这些用于用户容量和可用性控制的附加装置以及用于大量用户的数据库设备的唯一或数量减少的AB(1，2)可能适合某种类型的蜂窝电话联盟。举例来说，这种蜂窝电话联盟可以是一个包含了多个全国性MNO的联盟，而这些MNO则属于一个机构扩展到整个世界的全球公司。
在这里参考图1给出的情况来描述两种主要的代表性使用范例，此外在示范性实施例中从结构角度进一步描述所述使用范例的更明确的细节。
第一种使用范例可以是用户(User@MNO-A)访问某个服务供应商(SP-1)，例如书店服务供应商，其中服务供应商(SP-1)是经由MNO-A这类特定移动网络运营商与蜂窝电话的SSO联盟(FSSO-1)相关联。如图2所示，用以验证这类用户以及授权这类服务的处理是在MNO-A的用户(User@MNO-A)请求访问(C-21)书店服务供应商(SP-1)的时候开始的。假设这个SP与MNO-A具有业务协定并且由此与MNO-A所属的蜂窝电话联盟(FSSO-1)具有业务协定，那么SP-1会将请求重定向(C-22)到MNO-A的原籍站点。一旦在MNO-A的原籍站点接收到涉及用户访问SP服务的请求(C-23)，那么举例来说，用户将会使用cookie来给出自己的MNO-A标识。此时可以应用两个在上文中已被说明的可能实施例。更为特别的是，在这里要么由充当验证中介的MNO-A在内部确定MNO-A即为用户的验证提供方，要么如下文所述，MNO-A的AB和AP像一个更通用的情况那样全都涉及其中。
如果用户还未曾在MNO-A那里得到验证，则执行所述验证过程。如果已经对用户进行了验证，那么用户会向MNO-A给出一个cookie，以便允许MNO-A检查一个指定用户会话的状态。除非SP请求执行一种特定的验证机制，否则所述验证并不是特定于每一个SP的。MNO-A将会为明确定向到SP的用户创建(C-24)一个验证声明。然后则将一个引用了用户验证声明的助诊文件回送(c-25)到用户，其中所述用户验证声明很有可能包含了其他验证信息。助诊文件只能使用一次，并且只对它们所定向的特定SP有效。用户则主动将这个助诊文件提供(C-27)给SP-1。然后，SP核实这个助诊文件是否有效并且向原籍站点(MNO-A)请求(C-27)所涉及用户的验证声明。MNO-A则回送(C-28)完整的用户声明，其中带有至少包含了验证信息的用户数据。这样一来，SP-1可以分析用户声明并且相信用户原籍站点(MNO-A)所执行的验证。最终，SP-1向用户告知(C-29)接受了服务访问。
第二种使用范例可以是用户(User@MNO-A)访问某个服务供应商(SP-2)，例如旅行社服务供应商。这样一来，所述服务供应商(SP-2)经由MNO-B这类特定蜂窝运营商而与蜂窝SSO联盟(FSSO-1)相关联，然而所述用户也是作为联盟成员的另一个蜂窝运营商(MNO-A)的用户。如图3所示，用以验证这类用户和批准这类服务的处理是在MNO-A的用户(User@MNO-A)请求访问(C-21)诸如旅行社服务供应商(SP-2)之类的服务供应商的时候开始的。这个SP-2与MNO-B具有一个业务协定，以便将SSO服务提供给MNO-B的用户以及蜂窝电话联盟(MNO-A，MNO-C)中其他成员的用户。当SP-2接收(C-21)到关于SSO的用户请求时，由于所述MNO-B是这个SP进入联盟的唯一入口点，因此所述SP-2会将请求重定向(C-22)到这个MNO-B站点。因此，在这个使用实例中，MNO-B起到了验证中介的作用并且从SP-2那里接收(C-33)了一个用户重定向。为了简化SP，在这里SP并不了解联盟的所有原籍站点，由此不会在重定向消息中传递用户原籍站点的信息。接下来，MNO-B请求(C-34)获取用户的原籍站点名称。在这个参考模型中可以设想，用户标识只在其原籍站点已知。而一种备选方案则是在蜂窝电话联盟内部共享用户标识，然而，这样做将会由于相应的管理任务而导致需要庞大的中心目录。
响应于请求(C-34)，用户使用原籍域名来回应(C-35)MNO-B站点，也就是当前的验证中介(2)。然后，验证中介(AB)将用户重定向(C-36)到其原籍站点，即MNO-A。此后，对SP-2来说，用户为SP-2请求访问(C-23)其原籍站点。与先前的使用范例一样，如果在MNO-A上尚未验证用户，则执行验证程序(C-24)并将一个引用了带有验证信息的用户声明的助诊文件回送(C-25)给用户。此时，用户可以将这个助诊文件交付(C-26)SP-2。然后，SP-2必须核实助诊文件来源并且解析用户原籍。所述SP-2从AB(2)那里请求(C-37)这个信息。并且AB(2)将会回送(C-38)用户的原籍解析响应，以使SP-2能与用户原籍站点(MNO-A)取得联系，从而获取所引用的用户声明。所述MNO-A回送(C-28)带有必要用户数据的完整用户声明，其中所述用户数据至少包含了验证信息。然后，SP-2对用户声明进行分析并且相信用户原籍站点所执行的验证。最终，SP-2允许(C-29)用户访问所述服务。
在依照图1到3中描述的施动方、作用、信任关系和某些示范性使用范例给出了结构化商业参考模型的概述之后，根据一种适合在由多个MNO组成的联盟中所包含的各个移动网络运营商(MNO)上支持联合单点登录(FSSO)服务的优选架构，可以引入一个更详细的实施例。
这种结构是参考了联盟成员、服务供应商与用户之间的外部接口来描述的。这些接口包含了用户，更精确地说应该是用户设备(UE)与验证中介之间的接口(在下文中称为UE-AB i/f)；用户或UE与验证提供方之间的另一个接口(在下文中称为UE-AP i/f)；在服务供应商与验证提供方之间的另一个接口(在下文中称为SP-AP i/f)；以及服务供应商与验证中介之间的另一个接口(在下文中称为SP-ABi/f)。
这些接口或其组合提供了用于在联盟内部和外部所包含的不同实体之间进行通信的信道。在图4中描述的这些信道则为适当架构提供了基础。
因此，UE-AB i/f允许AB将用户重定向到负责对其进行验证的AP。例如，这个接口是通过用户向AB提供AP名称以及AB将其转换到AP站点中的入口端来支持重定向的。本领域的任何技术人员都很容易地想到其他那些实现相似结果的方法或技术。在原籍站点中，这个通信接口属于所谓的“中介信道(AB)”(1、2)。
UE-AP i/f支持施动方、用户以及验证提供方(4、5、6)之间的验证会话。一旦得到验证，则用户将被重定向到某个带有某种令牌或证书的SP。在原籍站点中，这个通信接口称为“前向信道(AP)”(4′)。
SP-AP i/f主要用于交换用户信息，例如验证、属性、授权和声明。这个通信相对用户而言是透明的，并且在下文中将其称为原籍站点中的“后向信道(AP)”(4″)。
SP-AB i/f支持建立后向信道，其中举例来说，AB将助诊文件中包含的源ID转换到用户AP或PKI支持的入口端。在原籍站点中，该接口属于所谓的“中介信道(AB)”(1、2)。
因此，图4还显示了MNO为了在F-SSO解决方案中成为一个AP和一个AB而可能支持的功能组件。如该图所示，在这里可以将所述架构视为包含了一个前向信道、一个后向信道和一个中介信道视图。因此，验证提供方(4、5、6)可以视为包含了一个前向信道(4′)和一个后向信道(4″)。前向信道旨在控制用户验证以及管理用户与AP之间的主会话。而部署F-SSO服务所需要的大量控制逻辑则处于前向信道的实体中。后向信道旨在对SP与AP之间的直达通信进行处理，以便交换用户信息。中介信道则负责支持SP和用户需要的地址解析。
对前述主会话来说，在这里必须引入涉及会话处理地附加细节事项。在这点上，当用户请求一个F-SSO服务时，有必要创建和保持如下所示的若干个会话用户与AP之间的主会话。一旦AP对用户进行了验证，则AP创建一个会话并在用户浏览器中留下一个经过加密的cookie，以便进行后续验证查询。
用户与SP之间的服务会话，以便能够使用在SP上提供的服务。在这里也可以将Cookie用于这个会话管理。
AP需要对在用户与每一个SP之间建立的服务会话进行追踪。因此，根据本发明的一个方面以及如图4所示，AP包含了一个优选处于前向信道之中的SSO会话管理器(41)并且还与后向信道互通，此外AP还与位于前向信道的AP万维网前端(42)相互连接。另外，AP还包含了一个用于保存和维持这类信息的会话数据库(43)，其中所述会话数据库最好位于前向信道并与SSO会话管理器(41)相互连接。
在为上文所介绍的参考图2和图3所描述的使用范例给出当前优选实施例的更详细描述之前，首先将对不同施动方在这个结构化模型中所处理的不同用户标识符进行描述。
在这点上，为了执行一个SSO服务请求，用户必须向他们的验证提供方提供明确的标识，也就是所谓的“单点登录验证标识”(下文中将其称为SSO_auth_ID)，此外，为了实现本发明，所述标识有可能具有下列格式中的任何一种格式适合对或从一个移动电话进行访问的MSISDN/IMSI，User@domain或user@realm，例如user@mno.com用户名(字符串)验证提供方(AP)可以管理备个用户的多个SSO_auth_ID，但是需要为关联于多个SSO_auth_ID的各个用户定义一个所谓的“主单点登录标识”(下文中将其称为SSO_MAIN_ID)。这个SSO_MAIN_ID旨在供运营商使用，更具体地说是应该用于AP，其格式是由运营商许可的，也就是说，它既可以匹配于一个涉及用户的SSO_auth_ID，也可以不匹配所述SSO_auth_ID。
另一方面，与因特网相关的用户相对于不同的服务供应商具有多种用户标识。用户可能希望为每一个服务供应商保持当前的各种标识，以便访问每一个站点上的帐户。出于本发明的目的，这种标识称为“服务供应商用户标识”(在下文中将其称为SP_user_ID)，它表示的是用户在指定服务供应商(SP)那里的标识。这个SP_user_ID只在自己的用户与指定的SP之间才是有意义的。
先前段落将用户的SSO_MAIN_ID描述成了涉及至少一个SSO_auth_ID的相关密钥，其中所述至少一个SSO_auth_ID在用户原籍运营商即AP上唯一验证用户，此外先前段落还描述了在指定的服务供应商那里识别用户的SP_user_ID。在一种常规方案中，SSO_MAIN_ID、SSO_auth_ID以及SP_user_ID并没有相互匹配，并且用户不希望将任何一种标识提供给其他施动方。在这种情况下，用户可能借助于一个在SP与AP之间共享的标识而被这二者所了解，其中所述标识即为所谓的SHARED_ID。根据所设想的特定方案，这个SHARED_ID既可以是永久的，也可以是临时的。在这里也可以将这个标识设想成一个由SP和AP使用的非透明处理，以便引用相同的用户。
因此，根据本发明的一个方面，验证提供方将SSO_auth_ID、SSO_MAIN_ID以及SHARED_ID相互关联，而服务供应商将SP_user_ID与SHARED_ID相互关联。在图10中以一种非限定方式显示了这些标识之间的示范性关系。出于本发明的目的，在这里没有进一步描述不同施动方管理这些标识的方式以及相互连接这些标识的方式。
根据上文描述并且如图4所示的结构模型，在这里分别为上文中参考图2和3的序列所描述的使用范例的特定方面提供了更详细的实施例。正如为这些使用范例所论述的那样，当用户通过向其原籍站点请求(C-23)一个SSO验证来访问一个SP时，根据先前是否对用户进行了验证，有可能会需要执行不同的操作。
因此，图6中的实施例包含了在图5A到5C中分别描述的三个有序操作集合(序列I、II和III)，由此依照图4的结构模型而对图2的使用范例细节进行了描述，其中访问SP的用户并未得到原籍网络的验证。
图6的机制是在用户访问(C-21)一个SP并被重定向(C-22)到原籍站点的时候开始的。然后，图5A中的第一序列(I)显示用户从自己的万维网服务器发布了一个进行SSO验证的http请求(C-23′)。如果在用户的万维网代理中保存了源自过去进行的先前SSO会话的一个加密cookie，那么可以借助于这个经过加密的cookie来对用户进行识别(C-23″)。在这里建议对所述cookie进行加密，这样一来，在其他人以物理方式访问用于SSO会话的计算机或是借助那些旨在从万维网浏览器中获取cookie的脚本而获取了所述cookie的情况下，可以避免暴露用户标识SSO_MAIN_ID。由于cookie是由AP产生和加密并且稍后同样是由AP解密的，因此加密算法和密钥管理完全是由AP许可的。用户的万维网浏览器不需要了解cookie的内容。为了确保处理的安全性以及防止在通向万维网服务器的网络路径中窃取cookie，在这里可以始终经由一个https来实现连接。保存在cookie中的用户标识应该是被选作SSO_MAIN_ID的唯一一个标识。为了进行保密，较为便利的是使用一个不同于MSISDN或IMSI的标识。
更具体地说，用户的万维网浏览器重定向到位于AP前向信道的万维网前端(下文中将其称为Web F/E)。在用户首次对其进行访问的时候，将会通过一个执行验证万维网服务客户端的软件来自动下载一个插件，其中举例来说，所述客户端可以是简单对象访问协议(SOAP)客户机。随后，Web F/E(C-500)与SSO会话管理器(41)对接，从而确定是否存在一个与相关IMSI或是与用于相似目的的其他用户标识相关联的有效会话。在当前范例中，由于用户先前并未得到验证，因而此时是不存在任何有效会话的。
图6中的处理继续到图5B中所示的第二序列(II)，其中SSO会话管理器(41)向Web F/E告知(C-501)不存在有效会话。这样一来，用户将被告知有必要对其进行验证(C-502)。当用户接触到AP前向信道中的Web F/E时，他可以在用户可用的不同验证机制中选择(C-503)借助SIM卡来进行验证，然后SOAP客户机则调用这种服务。应该注意的是，在这里也可以在用户选择了验证机制之后而不是之前下载SOAP客户机，这并不影响本发明的范围。当用户希望借助SIM卡来进行验证的时候，假设提供给(C-505)Web F/E的标识是保存在SIM中的IMSI。此外假设对话在一个安全连接即https上继续进行，那么IMSI最好在SOAP请求中发送，而不使安全需要遭遇危险。此时将会再次联系(C-506)SSO会话管理器，并且所述会话管理器检测到用户并未建立一个有效会话，那么它会充当一个RADIUS客户机并且请求访问(C-507，C-508)一个验证授权记帐(AAA)服务器(44)。如果选择根据SIM来进行验证，则将IMSI用作恰当标识并且将其封装在一个可扩展验证协议(EAP)的属性值对(AVP)以及用户名的AVP中。
在这个阶段，根据所使用的验证机制，AAA服务器(44)可以请求(C-509，C-510)向一个后端验证服务器(72)(下文中将其称为“B/E Auth.Server”)提供一个验证查询。较为优选的是，在这里借助了RADIUS消息来到达这个“B/E Auth.Server”，其中可以根据网络访问标识符(NAI)的域部分来对所述消息进行路由。这样一来，充当RADIUS客户机的SSO会话管理器可以修改这类NAI域。一旦“B/E Auth.Server”接收了包括用户验证标识和EAP APV中的证书在内的访问请求消息，则“B/E Auth.Server”可能会需要其他证书(C-510到C-517)，由此这个处理包含了更多的EAP来回行程。
一旦AAA服务器(44)成功验证了用户，则它会将一个接受访问的消息回送(C-518)到SSO会话管理器。现在，SSO会话管理器(41)必须在会话数据库中为用户创建一个包含SSO_auth_ID和SSO_MAIN_ID的条目。如果SSO会话管理器还不知道SSO_MAIN_ID，那么它会通过提供作为用户查找关键字的SSO_auth_ID来查询(C-519)一个标识管理器(70)。由于具有用于保存SSO_MAIN_ID并经由标识管理器(C-520，C-521)而在一个请求中将其提供给(C-522)SSO会话管理器的公共目录服务(下文中将其称为CDS)，因此在这里很可能会产生附加的优点。此时，SSO会话管理器(41)则包含了这种在用户验证过程中使用的特定SSO_auth_ID以及SSO_MAIN_ID，从而在会话数据库(43)中为用户创建了一个条目，也就是一个会话。一旦在SSO会话管理器中创建了这个条目，那么在图5B中并未显示的Web F/E中，附加逻辑必须保持后续http请求之间的会话状态，例如通过向用户万维网浏览器发送一个cookie来保持所述会话状态。
应该了解的是，在这个验证处理过程中，所述验证与AP后向信道没有任何关系并且也没有产生任何声明。在这里只为指定用户创建了一个全新会话，其中包含了SSO_MAIN_ID、SSO_auth_ID、选定的验证机制以及与归属于用户的IP地址或MSISDN相类似的地址信息。
在序列II之后，图6中的处理继续进行图5C所示的第三序列(III)。在具有了用于指定用户的有效会话之后，SSO会话管理器(41)从标识管理器(70)中为相应的服务供应商(SP)获取(C-550、C-551)用户标识，也就是SHARED_ID。这个SP也就是通过将用户重定向到其原籍验证提供方(AP)来发起初始请求的唯一一个SP。尽管图5C中并未显示，但是这个SHARED_ID和所述标识所用于的相应SP都保存在与用于所述用户的主会话条目相关联的会话数据库(43)中。
一旦完成上述标识映射，则SSO会话管理器(41)调用(C-552)安全声明标记语言(SAML)引擎(45)中的一个服务，以便为指定的SHARED_ID和指定的服务供应商产生一个验证声明。所述声明包含了其他相关数据，例如验证时的日期和时间以及具体验证机制的相关安全强度。而声明则保存(C-553)在声明数据库(46)中，并且很有可能是由一个声明引用来标引的。因此，在这里为所述声明提供了一个“声明引用”，以便稍后唯一识别所述声明。而声明引用则是在SAML引擎上的验证助诊文件中进行编码的，其中所述助诊文件则返回给(C-554)SSO会话管理器，从而经由AP Web F/E进一步提交(C-555给)用户(C-25)。
优选地，这种助诊文件是作为URL的一部分而被编码并返回给用户的，也就是说，所述助阵文件是一个参数。同时，用户的万维网浏览器重定向到这个发送给SP的原始URL。实际上，这个信息是作为在从SP到AP的第一重定向中接收的URL的参数出现的。因此，来自SP、目标资源的原始URL应该保存在AP Web F/E。
此后，用户将助诊文件(C-26)提供给初始联系的SP。所述SP获取助诊文件，并且在解码之后提取声明引用以及发布声明的AP的标识。并且所述SP使用这个信息来与AP后向信道建立一个SAML对话(C-27)，此外还通过在SAML声明请求消息中给出助诊文件来请求初始声明。当AP后向信道中的SAML引擎接收到关于所述声明的请求(C-27)时，它会从声明数据库(46)中取出所述声明(C-556，C-557)，并且对其进行数字签名以及将其回送到SP(C-28)。
然后，SP最好使用自己的公共密钥架构(PKI)或者通过使用可信验证中介的PKI而在一个更常规的范例中对声明的有效性进行检查。
一旦在SP上证实声明有效并且发现信源是可信的，那么SP可以继续分析声明内容并且依照声明中包含的验证事实来实施他的本地策略。最终则向用户告知(C-29)接受了所述服务访问。
可以了解的是，对图6而言，结合图5A到5C所述优选实施例所给出的以上描述提供了涉及先前在图2中给出的使用范例的结构细节。在这里意图以一种说明性和非限制方式来理解这些结构细节。
图7A和7B中的实施例同样包含了在图5A到5C中分别描述的三个有序操作集合(序列I、II、III)，由此依照图4的结构模型而对图2的使用范例细节进行了描述，其中访问SP的用户已经得到了原籍网络的验证。更具体地说，图7A给出的是在处于其原籍网络的验证提供方之前进行的用户的单独验证，而图7B给出的是在用户访问SP时执行的操作，一旦将用户重定向到其原籍网络，那么可以发现用户已经得到验证并且仍旧保持了一个正处于活动之中的有效会话。
图7A中的机制直接始于图5A所示的第一序列(I)，其中如果可用的话，那么与图6使用范例所显示的相应序列一样，用户从自己的万维网服务器发布了一个进行SSO验证的http请求(C-23’)，随后则向AP前向信道上的Web F/E发送了(C-23″)带有加密cookie的用户标识。然后，Web F/E与SSO会话管理器(41)相对接(C-500)，以便检查是否存在一个与用户相关联的有效会话。所述序列流程随后则进行图5B所示的第二序列(II)，在这个序列中将会执行一个很可能由用户选择的验证程序。特别地，一旦SSO会话管理器(41)实际通过包含所使用的特定SSO_auth_ID和SSO_MAIN_ID而在会话数据库(43)中为用户创建了一个会话，则SSO会话管理器会向AP WebF/E发出通知，其中在图5B中并未显示的附加逻辑则保持了后续http请求的会话状态。最终如图7A所示，AP Web F/E向用户万维网浏览器应答(C-70)一个成功的登录。
这个已被验证的用户可能请求(C-21)对一个SP进行访问。根据上文中对图2的使用范例所做出的不需要验证中介的假设，这个SP将用户重定向到其原籍站点。然后，在进行了图5A的序列之后，用户再次访问这个向SSO会话管理器(41)发布了一个指示的指定的AP Web F/E(42)，以便检查是否仍然存在一个有效会话。接着，可能与会话数据库(43)协作的SSO会话管理器(41)发现已经存在一个关于所述用户的会话。然后，如图5C中描述的第三序列(III)所示，SSO会话管理器(41)提取一个将要用于SP的SHARED_ID，并对用于所述SHARED_ID及其在验证助诊文件中的包含物声明的生成和存储进行排序(C-552、C-553、C-554)。而助诊文件则经由Web F/E(C-555)返回到用户(C-25)并且如先前使用范例中那样提供(C-26)给了SP。然后，SP通过AP后向信道(4″)来检查初始声明(C-27、C-556、C-557、C-28)，并且最终向接受用户的服务访问(C-29)。
在先前区分图6的第一操作与图7A和图7B的第二操作的段落中已经描述了关于图2的使用范例的详细实施例，其中在图6的第一操作中，用户是在没有得到验证的情况下访问一个SP的，而在图7A和图7B的第二操作中，用户首先得到了验证并且随后得到了服务认可。
根据本发明的另一个方面，现在将依照图4所示的结构模型来对先前依照图3所描述的使用范例进行进一步描述。特别地，从验证中介的包含物中导出的实施例与从相应的全新接口中导出的实施例是存在差异的。
因此，如图3中所示，第二种使用范例是在用户(User@MNO-A)经由MNO-B这类特定蜂窝电话运营商而对某个与蜂窝电话SSO联盟(FSSO-1)相关联的服务供应商进行访问的时候出现的，然而使用者则是另一个蜂窝运营商(MNO-A)的用户，其中所述运营商同样是联盟中的一个成员。在第二种使用范例中，根据本发明的一个方面，为了接收来自SP(SP-2)的重定向，解析用户原籍站点以及重定向到用户所属的MNO，有必要用到验证中介(AB)。
在这方面，图8显示了在将所述用户重定向到处于用户原籍站点的恰当验证提供方(AP)之前在用户与AB之间执行的操作。更具体地说，图8是参考图4所述的结构模型来显示这些操作的。而图3并未顾及AB可能包含的所有特定设备。因此，与图3一样，当用户向验证中介(AB)发布一个关于SP-2的验证请求(C-33)时，如图8所示，实际在中介信道(2)上的AB Web F/E(21)中接收到了一个http重定向。然后则从AB Web F/E那里请求用户原籍站点的名称(C-34，C-35)。举例来说，这个请求可以通过向用户给出具有联盟中所有AP的网页来完成，其中用户需要做的是仅仅是点击他的原籍运营商标志。接着则从一个验证提供方(AP)数据库(22)中获取(C-84、C-85)用户原籍站点的URI。最终，AB Web F/E(21)将用户的http重定向(C-36)到处于其原籍站点的恰当AP。所述AB可以在用户的万维网浏览器中留下一个cookie，以免在接连重复进行其他与用户原籍有关的查询。如上文中依照图6或图7A、7B所示的使用范例描述的那样，所述流程序列继续向AP Web F/E(42)发布一个SSO验证请求(C-23，C-23′，C-23″)。
图9显示的是为了找出声明有效的地点而在服务供应商与AB之间执行的用于解析用户原籍的操作。更为特别的是，图9是通过参考4所述的结构模型来显示这些操作的，而图3则并未顾及AB可能包含的所有特定设备。在用户向图3和图9中描述的SP(SP-2)给出了(C-26)助诊文件之后，则会向AB请求(C-37)进行用户原籍解析。在处于中介信道(2)的AB Web F/E(21)上接收到这个请求。然后，AB Web F/E(21)从一个AP数据库(22)中请求(C-91、C-92)一个处于原籍站点的AP的URI，其中将所述URI回送到(C-38)SP。SP则最好使用DNS技术来解析原籍URI并且最终对所述验证声明进行确认(C-27，C-28)，其中如图3所示或者更具体的说，如在上文种参考图6或图7A、7B所述使用范例所描述的那样，验证声明是预先获取的(C-23、C-24、C-25)。验证声明的验证(C-27，C-28)可以从SP(SP-2)经由协议绑定(46)发布到SAML引擎(45)，其中较为有利的是，所述绑定插入到SAML引擎与SP之间。这个协议绑定(47)组件则被调整成了从诸如httms这类传送协议中解析出一个XML实例，并且经由SAML引擎来传送所述实例。由此可以授权SP执行SAML标准中定义的任何类型的查询。
对后一种情况中的声明有效性检查而言，SP不需要执行所有PKI的复杂操作，并且也没有在本地安装来自联盟中所有验证提供方的证书，而是仅仅安装了所述联盟中可信实体的证书，也就是作为这个验证中介主机的AP的证书。
很明显，在这里可以根据上述教导而对本发明进行多种修改和变化。因此应该理解，在所公开的概念范围以内，可以采用除这里具体描述的方式之外的其他方式来实施本发明。
权利要求
1.一种用于为访问选定服务供应商的用户提供单点登录服务的电信系统，其中该用户预订了一个第一移动网络运营商，该系统包括一个第一移动网络和至少一个第二移动网络；以及多个服务供应商中的至少一个服务供应商，一旦验证机构为所述至少一个服务供应商验证了所述用户，则向所述移动网络用户提供服务；该系统的特征在于移动网络运营商的蜂窝电话联盟充当验证机构，所述蜂窝电话联盟包括第一移动网络和至少一个第二移动网络，并且还包括一个属于第一移动网络的验证提供方，对至少一个服务供应商来说，所述验证提供方是联盟中有权验证用户的唯一成员；一个属于第二移动网络中的某个特定网络的验证中介，它被调整成了充当从这些服务供应商到所述联盟的入口点，其中这些服务供应商分别与所述特定的第二移动网络运营商具有入口点协定。
2.权利要求1的电信系统，还包括用于在所述用户访问一个服务供应商的时候，将其重定向到一个与所访问的服务供应商具有入口点协定的第二移动网络运营商的验证中介的装置；以及用于在用户访问所述验证中介的时候，将其重定向到处于所述用户原籍网络的验证提供方的装置。
3.权利要求2的电信系统，还包括用于在与服务供应商具有入口点协定的第二移动网络运营商的验证中介上执行用户原籍解析的装置，以便允许服务供应商向第一移动网络的验证提供方发出请求，从而确认关于所述用户的验证声明。
4.权利要求3的电信系统，还包括用于在所述用户访问特定服务供应商的时候，将单点登录验证请求从所述用户发布到负责为所述特定服务供应商验证所述用户的验证提供方的装置，其中所述用户则是蜂窝电话联盟的一个用户；以及用于将接收到的验证助诊文件提交给所述特定服务供应商的装置。
5.权利要求1的电信系统，其中在没有涉及验证中介的情况下，可以从那些分别与所述第一移动网络运营商具有入口点协定的服务供应商那里直接访问属于第一移动网络运营商的所述验证提供方。
6.权利要求5的电信系统，还包含了用于在所述用户访问服务供应商的时候，如果所述受访问的服务供应商与所述用户原籍移动网络运营商具有入口点协定，则在不涉及验证中介的情况下，将所述用户重定向到所述用户原籍移动网络运营商的验证提供方的装置。
7.权利要求6的电信系统，其中与所述第一移动网络运营商具有协定的服务供应商可以在不涉及验证中介的情况下，向所述第一移动网络运营商的验证提供方发出请求，以便对关于一个用户的验证声明进行确认。
8.权利要求7的电信系统，还包括用于在所述用户访问特定服务供应商的时候，将一个单点登录验证请求从所述用户发布到一个负责为所述特定服务供应商验证所述用户的验证提供方的装置，其中所述用户是蜂窝电话联盟的一个用户；以及用于将接收到的验证助诊文件提交给所述特定服务供应商的装置。
9.权利要求1的电信系统，其中所述用户是借助了一个共享标识而在指定的验证提供方与指定的服务供应商之间得到识别的，所述共享标识独立于所述用户与所述指定验证提供方之间的验证标识，并且独立于所述用户与所述指定服务供应商之间使用的用户标识。
10.权利要求9的电信系统，还包括以下组件群中的至少一个组件公共密钥基础设施装置，用于实现蜂窝电话联盟中的移动网络的安全性和保密性需要；一个标识管理器，用于保持和处理所述用户在蜂窝电话联盟场所中的标识与所述用户在各自的服务提供商场所中的标识之间的关系；公共目录服务装置，用于保存可以通过单点登录主标识访问的用户标识；以及后端验证服务器，所述服务器旨在产生一个验证质疑，所述验证质疑取决于所述用户选择的验证机制。
11.一种用于向访问选定服务供应商的用户提供单点登录服务的方法，其中该用户预订了第一移动网络运营商，并且每一个选定的服务供应商都与一个第二移动网络运营商相关联，该方法的特征在于它包括以下步骤在第一与第二移动网络运营商之间建立一个验证信任关系，由此形成一个移动网络运营商联盟；将所述用户生成的访问请求从特定的服务供应商那里重定向到所述第一移动网络运营商的蜂窝网络；在用户访问请求重定向的所述第一移动网络运营商的验证提供方那里产生一个对访问所述特定服务供应商的用户有效的验证声明，并且将一个关于所述声明的助诊文件返回给所述用户；请求对从所述特定服务供应商传递到所述第一移动网络运营商的验证提供方并且包含在用户所给出的助诊文件中的所述验证声明进行确认；以及一旦在服务供应商那里接收到一个成功确认响应，则接受所述用户的服务访问。
12.权利要求11的方法，其中第一和第二移动网络运营商都包含在蜂窝联盟中，并且这个方法的步骤a)根据选定服务供应商所关联的移动网络运营商还包含了以下步骤之一(a1)当选定的服务供应商与第一移动网络运营商相关联的时候，确定主管所述用户的第一移动网络运营商的验证提供方；或者(a2)当选定的服务供应商与所述第二移动网络运营商相关联的时候，将所述用户产生的访问请求从所述选定服务提供方重定向到一个特定第二移动网络运营商的验证中介，其中所述验证中介则负责确定主管所述用户的第一移动网络运营商的验证提供方。
13.权利要求11的方法，其中步骤b)包括以下步骤(b1)从所述用户那里接收一个单点登录验证请求；(b2)确定先前是否验证了所述用户；(b3)如果没有验证所述用户并且由此不具有一个使用中的有效会话，则由此通过关于用户访问所述选定服务供应商的用户偏好来执行一个质疑/响应验证过程；以及(b4)保存一个为访问所述选定服务供应商的所述用户所产生的声明。
14.权利要求11的方法，其中第一和第二移动网络运营商都包含在蜂窝电话联盟中，根据选定服务供应商所关联的移动网络运营商，所述方法的步骤c)还包括以下步骤之一(c1)当服务供应商与所述第一移动网络运营商相关联的时候，确定一个负责确认所述用户所给出的声明的第一移动网络运营商的验证提供方；或者(c2)当所述选定的服务供应商与所述第二移动网络运营商相关联的时候，从所述选定服务供应商那里向特定的第二移动网络运营商的验证中介请求解析所述用户的原籍站点，其中所述验证中介负责确定第一移动网络。运营商的验证提供方，而第一网络运营商则负责确认所述用户所给出的声明。
15.权利要求11的方法，其中步骤d)还包括以下步骤(d1)为访问所述选定服务供应商的用户检索一个存储的验证声明；以及(d2)将所述声明验证响应返回给所述选定的服务供应商。
16.权利要求11的方法，其中所述用户是借助了一个共享标识而在指定的验证提供方与服务供应商之间得到识别的，所述共享标识独立于所述用户与所述验证提供方之间使用的验证标识，并且独立于所述用户与所述服务供应商之间的用户标识。
17.一种包含在电信系统中的验证中介，其中所述电信系统向访问选定服务供应商的用户提供了单点登录服务，所述用户预订了第一移动网络运营商，此外每一个选定服务供应商都与一个第二移动网络运营商相关联，所述验证中介包括第一接口装置，用于与预订了第一移动网络运营商的用户进行通信；第二接口装置，用于与关联于第二移动网络运营商的服务供应商进行通信；以及从所述第一和第二接口装置中形成的中介信道，用于使验证中介分别将所述用户重定向到所述用户的原籍网络，以及为所述服务供应商解析所述用户的原籍网络。
18.权利要求17的验证中介，其中用户和验证中介都属于第一移动网络运营商，而多个选定服务供应商则与所述第一移动网络运营商相关联。
19.权利要求17的验证中介，还包括一个验证中介万维网前端，它包含了分别与所述用户和选定的服务供应商相对接的第一和第二接口装置。
20.权利要求19的验证中介，还包括以每一个移动网络运营商为基础，用于蜂窝电话联盟中的所有验证提供方的存储器，每一个移动网络运营商都包含在这个蜂窝电话联盟中。
21.权利要求20的验证中介，其中验证中介万维网前端还包含了用于从所述存储器中检索与所述用户原籍相关的寻址数据的装置。
22.权利要求21的验证中介，其中验证中介万维网前端还包括用于向那些与拥有验证中介的移动网络运营商相关联的服务供应商提供公共密钥基础设施服务的装置，从而实现蜂窝电话联盟的安全和保密需要。
23.一种包含在电信系统中的验证提供方，其中所述电信系统向访问选定服务供应商的用户提供了单点登录服务，所述用户预订了第一移动网络运营商，此外每一个选定服务供应商都与一个第二移动网络运营商相关联，所述验证提供方包括一个前向信道，其中包括一个万维网前端，所述万维网前端包含了在用户与所述验证提供方之间启用验证会话的第一接口装置；一个后向信道，其中包括一个协议绑定，所述协议绑定包含了用于在所述验证提供方与用户访问的选定服务供应商之间交换那些涉及用户验证声明的信息的第二接口装置。
24.权利要求23的验证提供方，其中前向信道还包括一个用于对用户的会话状态进行处理的会话管理器和存储器，以及一个用于为用户执行特定验证机制的前端验证服务器。
25.权利要求24的验证提供方，其中验证提供方的后向信道还包括一个用于为用户产生一个验证声明的安全声明标记语言引擎，以及用于保存那些验证声明的存储器。
26.权利要求25的验证提供方，还包含了介于前向信道与后向信道之间的互通装置，以便为用户产生和保存一个验证声明。
27.权利要求26的验证提供方，其中介于前向信道与后向信道之间的互通装置的操作是分别借助了会话管理器和安全声明标记语言引擎而被执行的。
28.权利要求27的验证提供方，其中会话管理器包含了通过使用公共目录服务装置而从标识管理器中检索用户在蜂窝联盟场所中的标识与其在各自服务供应商场所的标识之间的关系的装置，其中所述标识由一个单点登录主标识相关联。
29.权利要求24的验证提供方，其中前端验证服务器与充当后端验证服务器的蜂窝电话联盟中的其他实体互通，以便在移动网络运营商的场所中提供特定的用户数据。
30.权利要求29的验证提供方，其中前端验证服务器是一个通常可以从蜂窝电话网络中的网络接入服务器那里进行访问的验证、授权和计费服务器。
31.一种用于进行商业活动的方法，其中至少两个移动网络运营商形成了一个移动网络运营商联盟，由此在联盟中建立一个用于支持单点登录服务的验证信任关系，对于那些为联盟中包含的移动网络运营商的用户提供服务的服务供应商而言，所述联盟充当一个验证机构，其中每一个服务供应商都与一个联合移动网络运营商相关联，以便访问这个联盟。
32.权利要求31的进行商业活动的方法，其中每一个移动网络运营商都提供了它自己的网络及其相关服务供应商所提供的服务，其中每一个网络都包含了一个用于对这种网络中的用户进行验证的验证提供方，以及一个验证中介，用于将相关的服务供应商重定向到一个负责对联盟中的给定用户进行验证的验证提供方。
33.权利要求32的进行商业活动的方法，其中每一个服务供应商都被调整成向联盟中包含的任何移动网络运营商的用户提供服务，指定的服务供应商可以通过一个与服务供应商签订了接入点协议的移动网络运营商的验证中介来访问联盟，并且由此与联盟具有了一种验证信任关系。
全文摘要
服务供应商向用户提供了全新和复杂的万维网服务，这些服务分别需要对用户进行验证并对访问进行授权，由此需要一种全新的服务来简化这种验证和访问，这种服务就是名为单点登录(SSO)的服务。支持SSO的基本原理是用户只在特定等级进行一次验证，然后则访问所有那些接受这种验证等级的预订服务。本发明提供了一种系统、方法和设备，其中移动网络运营商的蜂窝电话联盟成为联盟中的用户的验证机构，所述用户则对那些与联盟中的移动网络运营商订立了这类协定的服务供应商进行访问。根据本发明，移动网络运营商可以影响其运营商－用户信任关系，以便为这些用户充当SSO验证结构，而所述用户访问的是不同于所述移动网络域的其他服务域中的服务供应商。
文档编号G06F21/41GK1640175SQ03804871
公开日2005年7月13日 申请日期2003年2月28日 优先权日2002年2月28日
发明者L·巴里加, A·帕多布拉斯奎斯, J·M·沃尔克, J·A·德格雷戈里奥 申请人:艾利森电话股份有限公司