电子通信的增强的安全性 技术领域 以下的公开一般地涉及用于为电子通信提供增强的安全性的技术， 如通过在两个 服务之间的消息中包括使用该服务已知的秘密信息来产生的数字签名， 因此， 如果接收者 可以使用该接收者已知的秘密信息来复制接收到的数字签名， 则接收者接收到关于该发送 者的身份的保证。
背景技术 在日常生活中使用计算机已经变得普遍， 如使用户能够通过因特网或经由其他访 问机制 ( 例如蜂窝电话网络 ) 来访问和使用多种类型的远程服务。例如， 一些这样的服务 可以提供各种类型的信息 ( 例如当前新闻或参考材料 )， 而其他服务可以提供各种类型的 活动和能力 ( 例如在线银行、 在线购物、 电子邮件或其他消息收发服务等 )。虽然一些服务 可以向任何人提供信息和能力， 但是， 许多其他服务限制于授权用户， 如通过使其仅对授权 用户可用来保护用户信息的隐私 ( 例如， 要求用户在使该用户的电子邮件可用之前签入电 子邮件服务 )、 管理用于正在执行的活动的用户数据 ( 例如在线商户存储用户的财务和送 货信息以方便用户购物， 如作为针对该用户而维护的帐户的一部分 )、 以及确保用户已经提 供和合适的支付或满足使用服务的其他条件。
为了能够签入 (sign on)( 或登录 (logon) 或联机登录 (login)) 服务以证明对访 问限制信息或功能的授权， 典型地， 用户必须首先注册该服务， 并获得该服务独有的合适的 签入信息 ( 例如用户名和密码 )。然而， 由于这样的服务激增而每个具有独有的签入信息， 因此迫使用户针对不同的因特网站点不便地记忆许多不同的签入信息集合。此外， 许多因 特网站点的运营者和其他这样的服务的提供者可能更希望能够减轻为实现这样的用户签 入提供功能的负担， 以及减轻维护用户签入和其他鉴权数据的负担。
在为解决这些情形的一种尝试中， 创建了单一签入系统， 在该系统中， 用户创建单 一签入信息集合， 该签入信息集合能够访问一组多个从属服务或系统。 不幸的是， 当前的单 一签入系统具有种种问题。例如， 许多服务的运营者不愿意使用由另一个运营者提供的签 入功能。这种不情愿可能是由于， 在与该签入系统交互时在用户体验方面缺少一致性 ( 例 如， 由于缺少一致的品牌或其他一致的外观和功能 )， 其原因是可用的签入系统可能不会提 供所需功能， 等等。此外， 服务运营者和用户可能有关于安全性方面的担心， 如害怕冒名者 可能能够在与该单一签入系统的交互中假扮用户或服务运营者， 从而不适当地获得了对限 制信息或功能的访问。
因此， 提供技术来改进单一签入服务并提供其他益处是有益的。
发明内容 附图说明
图 1A-1C 示出了访问管理器系统、 服务和用户之间各种类型的交互的示例。图 2A-2E 示出了访问管理器与作为访问管理器的客户的服务之间的交互的示例， 该交互是为了定制要向该客户服务的用户提供的功能。
图 3A-3B 示出了访问管理器代表客户服务向用户提供的定制的签入过程的示例。
图 4 是一个框图， 示出了访问管理器服务器计算系统的示例实施例。
图 5 是客户注册管理器的过程的示例实施例的流程图。
图 6 是用户交互管理器的过程的示例实施例的流程图。
图 7 是证书管理器的过程的示例实施例的流程图。
图 8 是客户状态管理器的过程的示例实施例的流程图。
图 9A 和 9B 是对接收的消息进行鉴权的过程的示例实施例的流程图。 具体实施方式
描述了用于提供用于与用户交互的可定制功能的技术， 如经由访问管理器系统， 该访问管理器系统向其他服务提供单一签入功能和其他功能。在一些实施例中， 用户可用 的服务的运营者可以与访问管理器系统交互， 来定制并另外配置该访问管理器系统将要提 供给该服务的用户的单一签入功能和 / 或其他功能。在各种实施例中， 访问管理器系统可 以以各种方式向其他服务提供这样的功能， 如通过以交互的方式实现服务运营者要执行的 初始配置， 以及通过以程序化的方式、 经由访问管理器系统的 API(“应用程序接口” ) 实现 要向服务的用户提供的定制功能。在至少一些这样的实施例中， 访问管理器系统为各种用 户维护各种签入和其他帐户信息， 并使用该维护的信息， 代表与这些用户交互的多个不相 关的服务， 来为这些用户提供单一签入功能。此外， 在至少一些实施例中， 访问管理器系统 代表其来提供定制功能的那些服务是访问管理器的每个客户， 以便先前已注册了该访问管 理器系统的客户服务配置所要提供的定制功能 ( 例如兑换费用 )。 在一些实施例中， 访问管理器可以允许对该访问管理器提供的单一签入功能和 / 或其他功能进行各种类型的定制。客户服务的运营者可以配置各种类型的定制， 以便为特 定的客户服务定制该访问管理器代表该客户服务与用户进行的交互。例如， 在至少一些 实施例中， 这样类型的定制可以包括， 在与服务的用户进行交互时访问管理器所使用的服 务的各种类型的品牌联合 (co-branding)， 如包括使用要呈现给用户的一组或更多组信息 ( 例如要向用户显示的一个或更多个 Web 页面 ) 中的每一组来为服务配置的各种信息， 如一 个或更多个所示的图像 ( 例如标志 )、 所示的文本、 所示的用户可选择的链接、 其他所示的 用户可选择的控件 ( 例如所显示的菜单条， 如可以从所示的 URL(“统一资源定位符” ) 或从 正在执行的所示代码获得的菜单条 )、 由正在执行的所示代码提供的能力， 等等。 此外， 在至 少一个实施例中， 对访问管理器提供的功能的定制包括在与该访问管理器交互期间从服务 的用户收集来的各种类型的信息， 如基于服务运营者所选择的一个或更多个预定义的问题 和 / 或有服务运营者所指定的一个或更多个问题， 从用户收集信息 ( 例如， 关于用户的人口 统计信息、 偏好信息、 服务在执行其操作中使用的用户专有信息， 等等 )。 以下更详细地讨论 品牌联合和信息收集的定制。
在一些实施例中， 在用户与访问管理器交互以完成服务定制的签入过程之后， 访 问管理器为用户向该服务提供证书 (credential)， 如表示该用户是该服务的授权用户和 / 或代表该用户， 使得该服务可以代表该用户做出后续请求以执行动作 ( 例如， 为用户进行
支付、 为用户修改存储的帐户信息， 等等 )。在各种实施例中， 证书可以采用多种形式， 如包 括用户专用的信息 ( 例如用户的唯一用户名或其他标识符、 用户的真实姓名或其他标识信 息、 在定制签入过程期间从用户收集的信息， 等等 )， 不论以加密或不加密的形式， 或者在如 果返回的情况下， 代之以仅是该访问管理器以后可以映射至该用户的信息 ( 例如， 用于该 访问管理器的或与服务有关的唯一数 )。此外， 在至少一些实施例中， 访问管理器将代表用 户向服务提供的证书视为该服务专用的， 因此， 以后代表用户使用该证书的请求仅当由该 服务提供或代表该服务提供时才被视为有效。在至少一些实施例中， 证书也可以具有各种 其他类型的特性。例如， 特定的证书可以仅在有限的时间段内有效， 和 / 或仅对代表用户的 特定类型的活动或操作有效。如果是这样， 则访问管理器可以基于这样的特性来限制证书 的使用。以下讨论关于证书的补充细节。
在一些实施例中， 对于至少一些与允许服务进行的活动类型相关的服务， 访问管 理器允许附加类型的定制。例如， 可以以各种方式来限制允许一些服务对其签入用户进行 的动作的种类， 如反映访问管理器授予该服务的信任度——作为一个示例， 在一些实施例 中， 证书可以仅在有限时间段内有效， 如果是这样， 至少在一些情况下 ( 例如， 以无限和不 受限制的方式， 达到指定的次数、 达到指定的总有效期， 等等 )， 可以授权一些服务更新其 用户证书来扩展其有效期。此外， 在至少一些实施例中， 对至少一些服务， 访问管理器所允 许的定制包括一种或更多个种权威机构的委托， 主要服务可能能够向其他次要服务提供该 委托来代表用户进行动作， 如反映访问管理器授予主要服务和 / 或次要服务的信任度。例 如， 可以授权至少一些被提供了证书的主要服务为其他服务委托权威机构以按照各种方式 来使用这样的证书， 包括使用证书来代表所代表的用户进行至少一些类型的动作、 在至少 一些情况下对具有有限有效期的证书执行更新、 请求授予该次要服务专用的用户的新证书 ( 例如， 当证书仅对其原始授予的服务有效时 )， 等等。以下包括了与权威机构委托的类型 相关的补充细节。
在各种实施例中， 可以以各种方式 ( 如基于关于服务和 / 或服务运营者的可用信 息， 以自动的方式 ) 确定访问管理器将提供给服务的定制的类型。例如， 如果允许恶意服务 ( 或者试图假扮或代表善意服务来操作的恶意方 ) 执行定制时， 一些类型的定制可以提供 更高的安全性和责任风险。相对于品牌联合类型的定制， 允许服务添加要向用户显示的文 本和 / 或图像带有相对较小的风险 ( 假设该文本的上下文不是攻击性的或不合法的 )。相 反， 允许服务指定在产生要向用户提供的信息时访问管理器将使用的可执行代码、 或向用 户提供的信息中包括的可执行代码 ( 例如， 所包括的作为向用户发送的 Web 页面的一部分 的 Java applet) 可能带有相对较高的风险 ( 例如， 允许服务所指定的代码不适当地获得关 于用户信息， 如通过监控用户向访问管理器提供的服务不应获得的签入信息 )。 以下包括了 与确定可向服务提供的定制的类型相关的补充细节。
此外， 在一些实施例中， 使用了各种技术来防止恶意方执行未授权活动， 如防止网 络钓鱼 (phishing) 攻击， 在网络钓鱼攻击中， 恶意方试图假扮真实的授权方。例如， 为了 禁止恶意用户试图在假扮被授权执行与访问管理器的交互的服务时与访问管理器交互， 可 以使用附加的安全技术来对从至少一些服务发送的一些或全部消息进行鉴权。特别地， 在 一些实施例中， 对被授权与访问管理器交互的每个服务提供了至少一个唯一的秘密访问密 钥， 该服务和访问管理器知道该密钥， 然后， 在发送消息或与访问管理器进行其他通信时，该服务使用服务的秘密访问密钥， 使得访问管理器可以验证消息的发送者实际上是该服 务。 例如， 来自服务的每个这样的消息可以包括该服务的唯一标识符的指示， 也可以包括使 用该秘密访问密钥、 基于该消息内容的至少一部分来产生的数字签名。当访问管理器接收 到这样的消息时， 该访问管理器可以使用服务标识符来标识该服务， 并检索该服务的秘密 访问密钥， 然后， 可以以相同的方式， 使用检索到的秘密访问密钥和该消息内容的相同部分 来产生其自己的数字签名。如果访问管理器产生的数字签名与发送者的消息中包括的数 字签名匹配， 则访问管理器可以验证该发送者能够访问该服务的唯一标识符和秘密访问密 钥， 从而该发送者很可能实际上是该服务。 在各种实施例中， 秘密访问密钥可以采取多种形 式， 如共享秘密， PKI(“公共密钥基础设施” ) 密钥对、 X.509 认证、 使用硬令牌产生的秘密， 等等。 在至少一些实施例中， 还可以使用其他安全技术， 以下包括了与秘密访问密钥的使用 相关的补充细节。
出于解释的目的， 以下描述了一些实施例， 在这些实施例中， 具体类型的服务以具 体的方式配置由访问管理器系统向具体类型的服务用户提供的具体类型的功能的具体类 型的定制。然而， 可以认识到， 可以在广泛的各种其他情形中使用所描述的技术， 本发明不 局限于所提供的示例性细节。 图 1A 示出了访问管理器系统、 服务和用户之间的各种类型的交互的示例。特别 地， 图 1A 示出了访问管理器系统 114、 作为该访问管理器的客户的服务 110、 该客户服务的 用户 112、 从属于该客户服务的可选的其他次要服务 118 以及帐户管理器系统 116 之间的交 互。在本示例中， 作为单个实体所提供的一组系统 115 的部分来提供帐户管理器 116 和访 问管理器 114( 例如， 如果从授权方接收到请求， 帐户管理器代表具有访问管理器的帐户的 用户来执行各种动作 )， 在一些实施例中， 至少一些从属服务 118 也可以是系统 115 的部分。 所示的系统、 服务和用户之间出现各种消息， 如以下消息 ： 用户与访问管理器系统之间的消 息， 作为建立用户帐户的部分 ( 例如签入信息 ) ； 客户服务与访问管理器之间的消息， 用于 配置客户服务的定制的功能 ； 用户与客户服务之间的消息 ( 包括初始交互， 在初始交互中， 将用户重定向至与访问管理器交互来参加为客户服务定制的签入过程 ) ； 客户服务与帐户 管理器系统之间的消息 ( 例如用于代表已签入至客户服务的用户执行活动 ) ； 客户服务与 从属次要服务之间的消息 ( 例如用于代表已签入至客户服务的用户执行活动 ) ； 以及从属 服务与访问管理器和帐户管理器系统之间的消息 ( 例如代表已签入至客户服务的用户 )。 此外， 至少一些包含服务的消息可以基于服务的秘密访问密钥来使用数字签名 ( 未示出 ) ( 例如， 客户服务 110 和 / 或从属服务 118 与访问管理器 114、 帐户管理器 116 以及其他客 户服务或从属服务之间的消息 )。
图 1B 示出了访问管理器系统、 服务和用户之间的各种类型的交互的一个具体示 例， 特别示出了一个实施例， 在该实施例中， 由应用开发者的应用提供了客户服务。 特别地， 如在本示例中， 例如通过与客户注册过程 158( 例如， 可以由客户注册管理器组件提供 ) 进 行交互， 应用开发者 120( 在本示例中名为 “Bob” ) 首先为该开发者的应用 122 要提供的服 务向访问管理器系统 150 注册 180。 虽然在其他实施例中， 这样的应用可以代之以具有多种 其他形式， 如 Web 应用、 可下载的 applet 或其他可执行代码、 客户端和 / 或服务器应用、 移 动应用 ( 例如在蜂窝电话或在其他形式的移动计算设备上执行 ) 等等， 但是在本示例中， 应 用 122 是向该应用的最终用户提供服务和 / 或其他功能的应用程序 ( 例如在通用个人计算
机上执行 )。作为步骤 180 的一部分， 开发者可以提供各种信息， 包括联系人信息和关于应 用 122 的信息 ( 以及可选地提供该应用的拷贝 )。作为注册交互 180 的一部分， 开发者可 以根据访问管理器系统授予该开发者的许可等级， 来配置各种定制供该应用的最终用户以 后使用， 该定制例如品牌联合、 信息收集和权威机构委托。 备选地， 可以不使用一些定制， 如 在该应用直接与最终用户交互来获得签入信息， 并然后程序化地向访问管理器系统发送该 签入信息以进行验证的情况下， 可以不配置品牌联合。此外， 在应用的最终用户与应用 122 提供的图形用户界面交互的所示的实施例中， 该应用按合同或被强制以特定的方式经由该 图形用户界面向最终用户提供至少一些信息。例如， 这样的信息可以与向访问管理器系统 的签入相关， 以用该访问管理器的品牌来进行品牌联合的方式来向最终用户呈现该访问管 理器系统。备选地， 可以强制该应用提供该访问管理器专用的其他类型的信息或功能， 和/ 或采用各种指定的安全措施来保护最终用户的签入信息。在注册之后， 开发者可以从访问 管理器接收 181 各种信息， 如要使用的秘密密钥的指示 ( 或对开发者作为交互 180 的一部 分所指定的秘密密钥的确认 ) 以及该应用的非秘密的唯一标识符 ( 例如， 与该秘密访问密 钥相关联的标识符 )。 在开发者向各最终用户 130 分发 182 该应用之后， 最终用户可以使用 该应用来获得各种类型的功能。
然后， 示例用户 130 与该应用交互 183， 如通过请求操作， 在该操作中， 用户将签入 以使用远程第三方 Web 服务提供者 140( 例如， 该用户拥有已与其建立的帐户的 Web 服务提 供者 ) 提供的一个或更多个 Web 服务。Web 服务可以允许异构的应用和计算机进行交互， 并可以使用多种下层协议和技术来被定义和实现。例如， 一些 Web 服务实施方式响应于以 URI( 如包括指定的操作和一个或更多个询问参数的 URL) 指定的 Web 服务调用请求， 使用 HTTP(“超文本传输协议” )， 以 XML(“可扩展标记语言” ) 格式来返回数据。在其他实施方 式中， 使用附加的下层协议用于各种目的， 如 SOAP(“简单对象访问协议” ) 用于标准消息交 换、 WSDL(“Web 服务描述语言” ) 用于描述服务调用、 以及 UDDI(“统一描述、 发现和集成服 务” ) 用于发现可用服务。在一些情形中， 应用 122 和 Web 服务提供者 140 可以具有预定义 的关系， 而在其他实施例中， 应用可以仅与代表该应用的最终用户来提供的没有这样的预 定关系的 Web 服务而定义的 API 进行交互， 如同该 Web 服务提供者也是访问管理器系统的 客户并被配置为接受并使用访问管理器系统的证书来代表用户。
在用户请求触发签入的操作之后， 该应用产生签入请求消息 ( 例如， 使用该应用 的秘密密钥来产生数字签名， 以验证请求方是该应用 )， 并向用户交互管理器过程 152 发送 184 该消息。如果该消息被验证， 则访问管理器可以在从用户收集签入信息的过程中， 可选 地返回 185 该应用所要使用的签入信息 ( 例如， 指示询问用户以收集信息的问题、 或者要向 用户显示的一个或更多个页面或屏幕 ( 如果该应用是这样设计的 ))， 该应用可以与用户执 行签入过程， 以收集各种签入信息 ( 在本示例中， 该签入信息反映了该用户先前已经与访 问管理器系统建立的帐户 )。 然后， 可以将所收集的信息发送 186 至访问管理器用户交互管 理器 152。在其他实施例中， 该应用可以代之以从用户收集签入信息， 而无需任何与访问管 理器系统的初始交互， 并将用户的签入信息与初始请求 184 一起发送 ( 例如， 取决于该应用 被授予的许可等级 )， 尽管这样的情形可能将最终用户的签入信息暴露给应用。 当访问管理 器用户交互管理器 152 接收签入信息时， 它向帐户管理器系统 160 发送 187 该签入信息， 帐 户管理器系统 160 使用用户帐户数据库 ( “DB” )162 中的信息来验证该签入信息。然后， 将用户鉴权的指示 ( 如用户 ID 和错误消息 ) 发送回 188 访问管理器用户交互管理器。如果 该签入信息有效， 则向证书管理器 156 发送 189 请求 ( 例如带有用户 ID)， 该证书管理器产 生该应用使用的代表该用户的证书， 并将该证书返回 190 访问管理器用户交互管理器。在 访问管理器用户交互管理器接收该证书之后， 它将该证书发送回 191 该应用。
然后， 该应用产生 Web 服务请求， 并将其发送 192 给 Web 服务提供者 140， 该请求可 选地包括使用该应用的秘密访问密钥来产生的数字签名。当 Web 服务提供者 140 接收到该 请求时， 如果该请求附有数字签名， 则它可选地使用该数字签名来验证请求方的身份 ( 如 通过向访问管理器发送请求以请求验证 ( 未示出 ))。此外， 在本示例中， Web 服务提供者通 过向证书管理器发送 193 用户证书来验证该用户证书， 证书管理器产生合适的响应 ( 例如 确认该证书有效 ) 并将其发送 194 至 Web 服务提供者。当该证书被确认有效时， Web 服务 提供者为用户提供所请求的 Web 服务， 并向应用发送 195 响应。然后， 该应用可基于该响应 来向用户提供对应的信息和 / 或功能。在一些实施例中， 该应用还可以制作各种附加类型 的 Web 服务和其他请求， 如直接与帐户管理器系统交互以改变用户帐户或从用户帐户数据 库 162 中检索数据。在完成所有请求之后， 该用户可以经由该应用签退， 或只要允许证书在 其为有效的有限时间段之后到期。 图 1C 示出了单一签入 Web 服务 101、 示例客户服务 103 以及正在与该客户服务交 互的最终用户 ( 未示出 ) 所使用的 Web 浏览器 105 之间的各种类型的交互的一个示例。在 本示例中， 如所示交互的第一步骤， 该最终用户使用浏览器 105 来向客户服务 103 发送基于 HTTP 的请求 121， 以获得所示的功能。该服务确定所请求的功能仅对已签入用户可用， 并相 应地向该最终用户发送签入请求 123 以执行签入过程。在该所示的实施例中， 该签入请求 附有数字签名 ( 例如使用 X.509 认证 )， 以在其他地方更详细地描述的方式来产生该签入 请求。在本示例中， 单一签入服务向许多客户服务提供签入过程， 以如下方式向浏览器 105 发送签入请求 123， 即， 使得浏览器 105 将包括数字签名的请求 125 转发至该单一签入服务 ( 例如， 如经由 HTTP 301 状态码， 通过发送重定向 URL)。然后， 如在其他地方更详细地描述 的， 单一签入服务 101 试图验证请求 125 的数字签名， 如果成功， 则其继续向浏览器 105 发 送回 127 签入页面。然后， 当签入页面在浏览器 105 上显示时， 最终用户在签入页面中输入 他 / 她的签入信息 ( 例如用户名和密码 )。可以基于用户与该单一签入服务先前为创建对 应的用户帐户而进行注册期间 ( 或在交互式注册过程 ( 未示出 ) 之后 ) 所提供的信息来产 生该签入页面。 然后， 将该签入信息传送回 129 单一签入服务 ( 例如， 当最终用户选择了 “完 成” 控件或其他类似的控件时 )。 在本示例中， 尤其由于不与客户服务 103 共享签入信息， 所 以最终用户信任该单一签入服务提供者， 并愿意将他 / 她的签入信息发送至该单一签入服 务。在接收签入信息之后， 单一签入服务 101 确定接收到的签入信息是否有效， 如果有效， 则执行该最终用户的签入并产生代表该用户作为已签入最终用户的证书。然后， 以如下方 式将所产生的证书发送 131 至浏览器 105， 即， 使得如经由该客户服务的 cookie 或经由重定 向 URL 将该证书转发 133 至客户服务 103。在该客户服务接收到指示该最终用户的成功签 入的证书之后， 客户服务 103 向该最终用户提供初始请求的功能 ( 未示出 )。 虽然这里没有 示出， 但是， 客户服务也可以使用该证书来代表最终用户进行各种后续动作。例如， 可以将 该证书和与该用户的帐户相关的请求一起返回至单一签入服务 ( 例如， 基于用户帐户中存 储的财务信息来做出支付 )。这样的基于证书的使用可以基于客户服务 103 与单一签入服
务 101 之间的直接交互， 或代之以经由与一个或更多个从属中间服务 ( 未示出 ) 和 / 或最 终用户的交互。此外， 出于安全的原因， 可以有利地在 HTTP/S 上传送各种消息中的至少一 些消息。
图 2A-2E 示出了访问管理器与作为访问管理器的客户的服务之间的交互的示例， 该交互是为了定制要向该客户服务的用户提供的功能。特别地， 图 2A 示出了如经由向服务 ( 该服务向访问管理器注册以代表该服务的用户获得定制的功能 ) 的运营者显示的 Web 页 面， 可以向访问管理器的预期客户服务的代表显示的第一组信息。 在本示例中， 初始注册信 息包括指令信息 201 和部分 202， 在部分 202 中， 访问管理器的客户可以指定各种类型的信 息， 如名称和因特网地址 202a( 例如提供该服务的服务的 URL)、 管理联系人信息 202b 以及 关于服务的有限的总览信息 202c。在其他实施例中， 可以以各种方式获得关于服务和服务 运营者的各种其他类型的信息， 并可以使用这些信息作为对信任等级和对应的许可的确定 的一部分， 访问管理器将授予访问管理器的客户该对应的许可， 以限制可向该客户提供的 定制的类型。在输入该信息之后， 在本示例中， 通过点击用户可选择的 “注册” 控件 203， 将 该信息提交给访问管理器。可选地， 可以代之以使用用户可选择的 “复位” 控件 204 来复位 该表单中提供的信息。在本示例中， 通过选择 “注册” 控件 203， 将如图 2B 所示的后续组的 信息 ( 例如下一个 Web 页面 ) 呈现给预期客户， 以继续与访问管理器的注册。在其他实施 例中， 可以代之以其他方式 ( 例如作为一起显示的单个信息组的一部分 ) 来呈现所有信息 请求和定制控件。 图 2B 示出了第二组信息的示例， 向预期客户服务代表显示该第二组信息以指定 一个或更多个种类的品牌联合定制。在本示例中， 品牌联合定制的可用种类相对较少， 如 反映授予该客户的相对低等级的许可 ( 例如， 除非可以验证更高的信任等级， 否则作为针 对任何客户的初始缺省值， 或基于关于图 2A 而提供的信息和 / 或关于服务或服务运营者的 其他可用信息， 如基于与该服务或运营者过去的交互经验 )。在本示例中， 允许该客户指定 多个品牌， 并针对每个品牌定制不同的信息。在其他实施例中， 可以不使用这样的品牌， 或 代之以将服务和品牌的每个组合视为不同的客户。 类似地， 虽然在这里未示出， 但是在其他 实施例中， 客户可能能够指定其他类型的区别， 针对该区别来指定和使用不同的品牌联合 或其他定制， 如用户或其他用户组可以与之相关联的多个地理地点。 在指定多个品牌、 地点 或其他不同分组时， 在一些实施例中， 可以为每个这样的分组提供单独的标识符， 并可选地 提供单独的秘密访问密钥， 以允许使用对特定分组的引用。 在本示例中， 所显示的信息包括 指示正在配置的品牌的部分 206( 或者， 如果不使用不同的品牌或者如果对所有品牌应用 该定制， 则留空 )、 指令信息 205 以及区域 207， 该区域 207 具有供客户指定一个或更多个定 制的各种问题和信息选择 / 说明区域。例如， 客户可以指定要向用户显示的服务的一个或 更多个标志图像 ( 例如通过上传对应的文件或指定网络地址， 从该网络地址可以检索到该 图像 )， 在本示例中示出了指定的标志图像的预览 208， 以及要使用的标志位置、 要向用户 显示的文本和要向用户显示的链接。 可以认识到， 在其他实施例中， 可以提供多种其他类型 的品牌联合定制。此外， 在本示例中， 向客户提供了用户可选择的 “预览” 控件 209， 使用其 可以预览由指定的品牌联合定制所产生的一个或更多个签入页面或屏幕， 以及用户可选择 的 “保存” 控件 210， 用于保存指定的品牌联合定制。虽然在其他实施例中， 可以指定多个 不同集合的品牌联合定制， 但是在本示例中， 将客户示为仅执行单一组的品牌联合定制。 例
如， 可以为单一品牌提供多个不同集合的品牌联合定制， 以反映访问管理器要向用户显示 的多个页面或其他组的信息 ( 例如， 用于签入过程的多个页面和 / 或用于诸如签出或签退 (sign-off 或 sign-out) 过程、 从用户收集信息、 呈现错误、 更新证书、 基于授予主要服务的 证书来产生用于次要服务的新证书 ( 称为 “复制” 证书 ) 等之类的其他相关类型活动的页 面 )。
以与图 2B 类似的方式， 图 2C 示出了第二组信息的备选示例， 向预期客户服务代表 显示该第二组信息以指定一个或更多个种类的品牌联合定制。在本示例中， 可以向客户提 供附加类型的品牌联合定制， 以反映授予该客户的相对高等级的许可 ( 例如， 基于关于图 2A 所提供的信息和 / 或关于服务或服务运营者的其他可用信息 )。在其他实施例中， 出于 其他原因 ( 例如对于高级客户， 如兑换附加费用 ) 可以提供附加类型的品牌联合定制。在 本示例中， 所显示的信息包括对来自图 2 的信息 205-208 的指示 211， 还包括附加的品牌联 合定制 212。 在本示例中， 该附加类型的品牌联合定制包括进一步指定要向用户显示的信息 的外观的能力、 指定用户可选择的控件和 / 或标题中要包括的其他信息或要向用户显示的 其他信息的能力、 以及指定要被包括作为页面或要向用户显示或提供的其他信息的一部分 的其他可执行代码的能力。 这些附加的品牌联合定制类型仅是示意性的， 然而， 备选实施例 中可以提供其他附加类型的定制。 虽然在本示例中， 客户服务的运营者或其他代表响应于对应的提示， 单独指定了 各种定制， 但是在其他实施例中， 可以使用其他技术来指定品牌联合定制。例如， 在一些实 施例中， 可以采用 WYSWYG(“所见即所得 (What You See is What You Get)” ) 系统， 其中， 客户图形化地指定定制的签入页面或要向用户显示或呈现的其他信息的外观， 或代之以使 用合适的格式 ( 例如 XML 或 (X)HTML(“( 可扩展 ) 超文本标记语言” ) 片段 ) 来在文件中 指定品牌联合定制， 并将其发送给访问管理器。
图 2D 示出了第三组信息的示例， 向客户服务代表显示该第三组信息以指定在与 服务的用户交互时要执行的一个或更多个种类的信息收集。在一些实施例中， 可以仅对具 有足够高许可等级的客户和 / 或基于其他准则 ( 例如仅对高级客户提供 ) 来提供一些或全 部种类的信息收集。在本示例中， 提供了要收集的各种预定义类型的信息 ( 例如， 每个预定 义类型的信息具有要向用户显示的对应的问题 ( 未示出 ))， 提供了复选框 213 来选择一个 或更多个预定义的信息类型。虽然这里没有示出， 但是， 在至少一些实施例中， 客户服务还 可能能够配置要询问用户的一个或更多个客户指定的问题集合， 如键入要询问的问题并可 选地列举或指示该问题所允许的答案。 此外， 在本示例中， 客户还可以指定访问管理器要跟 踪的一个或更多个种类的用户活动 215， 如签入尝试 ( 成功和 / 或不成功 )、 签退尝试、 获得 对所显示或所指示的项目和条件的同意 ( 例如， 在注册过程中由客户指定 ( 未示出 )、 用户 通过选择 “接受” 控件或通过用户同意的其他指示来接受的项目和条件 )。虽然在其他实施 例中， 询问用户预定的和 / 或客户指定的类型的信息的定时是固定的 ( 例如仅在用户第一 次签入至服务 ( 或其他活动 ) 过程中进行一次、 对每次签入都进行等等 )， 但是在本示例中， 如用户可选择的定时控件 214 所示， 客户还可以指定询问用户预定义的和 / 或客户指定的 类型的信息的时间。在本示例中， 客户也可以指定格式信息 216， 以针对至少一些要收集的 预定义类型的信息， 指示可允许的答案的类型。在一些实施例中， 在配置信息收集时， 也可 以提供其他类型的信息， 如用于动态确定所提供的用户答案是否可允许的逻辑、 用于确定
是否要询问特定用户一些问题的逻辑 ( 例如， 基于指示用户是否有配偶或孩子的用户先前 的答案， 确定是否询问关于涉及用户的配偶或孩子的详细信息的问题 ) 等等。
图 2E 示出了第四组信息的示例， 向客户服务代表显示该第四组信息以指定对其 他从属次要服务的一个或更多个类型的权威机构委托， 以代表主要客户服务的用户来执行 特定类型的动作， 尽管在一些实施例中， 可以仅向具有高许可等级的客户提供这样的定制 ( 权威机构委托的具体类型可以基于许可等级和 / 或其他因素而变化 )。 在本示例中， 图 2E 具有指令信息 217 和部分 219、 221 和 223， 客户可以经由这些部分来指定用于接收权威机 构委托的服务。 虽然这里没有示出， 但是在一些实施例中， 客户还可以为每个从属次要服务 指定权威机构委托的具体类型， 如通过修改权威机构委托的缺省集合。客户还可以指定对 从属服务能够访问的信息的控件 ( 例如可用用户信息的指定子集 )。在本示例中， 部分 219 提供了从属于访问管理器的各种其他服务 ( 例如基于相同实体所提供的服务 )， 如支付服 务 ( 例如使得能够从用户帐户和 / 或对用户帐户进行支付 ) 和推荐服务 ( 例如， 如根据之 前指定的用户偏好， 代表用户获得和 / 或提供推荐 )。此外， 部分 221 提供了各种其他流行 服务 ( 在本示例中， 包括关于服务的信息， 如流行或可靠级别 )， 部分 223 允许客户指定其他 服务。
在一些实施例中， 从属于主要客户服务的次要服务自身可能需要与访问管理器注 册， 以代表用户与访问管理器交互， 因此， 流行的服务可以基于已经与访问管理器注册的服 务。 备选地， 如果指定的服务尚未与访问管理器注册， 则访问管理器可以自动询问指定的服 务来提供注册的能力。当客户服务正与用户交互时， 对另一个服务的权威机构委托可能以 各种方式出现， 如在由用户启动时 ( 例如， 基于与经由次要服务提供的能力相对应的主要 客户服务所显示的用户选择的链接或控件， 如用于从用户帐户进行将被委托给支付服务的 支付的链接 ) 和 / 或如果由主要客户服务自动执行。此外， 在一些实施例中， 可以以对用户 透明的方式来执行与次要服务的交互。 例如， 如果需要与支付相关的能力， 则次要的从属支 付服务可以产生并向用户发送页面或其他信息组， 以从用户获得对应的信息 ( 例如， 对一 个或更多个其他方的指示、 对用户签入或针对至少一些类型的动作的其他信息的验证， 等 等 )。 此外， 为了向用户提供一致的体验， 在至少一些实施例中， 次要从属服务可以使用向用 户显示的信息中的先前指定的针对主要客户服务的品牌联合信息。 为了获得对这样的先前 指定的品牌联合的访问， 如果使用品牌联合信息的权威机构已经被委托给次要从属服务， 则该次要从属服务可以与访问管理器交互来获得该品牌联合信息。例如， 主要客户服务可 以向次要从属服务委托权威机构， 以使其能够以指定的方式使用主要客户服务的指定类型 的品牌联合信息 ( 例如主要客户服务的一个或更多个标志或其他图像 )， 如果是这样， 则从 属服务可以通过向访问管理器发送合适的请求 ( 例如这样的请求， 即该请求指示了次要服 务、 主要客户服务、 所需信息类型以及可选地指示了主要客户服务的具体的品牌联合信息 ) 来获得对这样的品牌联合信息的使用。 如果访问管理器确定授权次要服务使用该品牌联合 信息， 则访问管理器发送回该品牌联合信息 ( 或次要服务能够使用其来获得品牌联合信息 的信息 )。
图 3A-3B 示出了访问管理器代表客户服务向用户提供的定制的签入过程的示例。 特别地， 图 3A 示出了为客户服务定制的要向该服务的用户显示的初始签入页面。在本示 例中， 访问管理器功能的提供者可以为具有相对低的许可等级的客户 ( 或未选择以包括与更高许可等级相关联的定制的客户 ) 产生该签入页面。在本示例中， 根据品牌联合定制来 显示客户标志 301 和客户图像 303， 也示出了访问管理器或提供访问管理器的实体的标志 305。 在其他实施例中， 可以不使用标志 305。 如基于访问管理器提供者的用户帐户， 指令信 息 307 通知用户使用针对帐户管理器提供者的签入信息来启动签入过程。然后， 用户可以 在合适的空白 309 输入签入信息。此外， 显示定制的链接 313 来提供对客户的使用条件和 客户的私有策略的访问。也可以呈现用于提交该签入信息的各种用户可选择的控件 311。
图 3B 示出了要向服务的至少一些用户显示的、 为客户服务定制的签入过程的后 续页面， 如在用户首次签入客户服务期间或针对满足指定准则的后续签入尝试而向用户显 示的页面。特别地， 在本示例中， 提供该页面， 通过询问由客户指定的问题 325 来执行定制 类型的信息收集。 这样的问题可以包括但不限于 ： 送货地址、 电话号码和用户的其他联系人 信息。客户标志 321 示出了可以作为信息收集页面的一部分来呈现的各种类型的品牌联合 的示例， 不论其是与图 3A 的标志 301 相同还是代之以不同的客户标志。也可以向用户呈现 指令信息 323 来通知他 / 她回答问题， 这些问题是缺省的或由客户服务指定的。一些问题 也可以示意出客户所指定的定制数据格式， 例如电话号码 327。在一些实施例中， 可以使用 客户端脚本 ( 例如 JavaScript) 来向可允许的值施加任何指定的限制， 以及实现用于确定 是否应询问用户一些问题的指定的逻辑。即使不执行其他一次性信息收集， 每次用户签入 到客户时， 也可以询问用户附加问题 329。在用户回答了这些问题之后， 用户可以通过使用 用户可选择的控件 331 来提交该信息。
在不同实施例中， 可以以各种方式来完成签入和信息收集。例如， 虽然图 3A 和 3B 示出了 Web 页面， 但是在一些实施例中， 可以利用其他界面， 包括程序化的访问界面。此外， 可以使用多个页面来收集关于用户的信息， 尤其是针对用户对客户的初始签入， 在用户界 面中可以使用各种用户界面窗口小部件。
虽然这里没有示出， 但是， 也可以以多种其他情形或方式来使用定制的签入过程 和其他类型的定制的用户交互。例如， 虽然在图 3A 和 3B 中将定制技术示出为一个或更多 个 Web 页面的部分， 但是类似地， 可以代之以对各种其他类型的消息和信息进行定制， 如一 个或更多个电子邮件消息 ( 例如以 HTML 格式指定的电子邮件消息 ) 或向最终用户发送的 其他类型的电子消息。此外， 可以使用该技术来对向用户提供的各种其他类型的信息进行 品牌联合， 如搜索引擎结果或由社交联网服务提供的信息。
图 4 是一个框图， 示出了访问管理器计算系统 400 的示例实施例， 以及各种用户计 算系统 450、 从属服务计算系统 490 和客户服务计算系统 470。在所示的实施例中， 访问管 理器计算系统包括 CPU 405、 各种 I/O 组件 410、 存储装置 430 和存储器 420， 其中该 I/O 组 件包括显示器 411、 网络接口 412、 计算机可读介质驱动器 413 和其他 I/O 设备 415。
在存储器 420 中执行访问管理器系统 423 和帐户管理器系统 428 的实施例， 它们 通过网络 480( 例如经由因特网和 / 或万维网 ) 与其他计算系统交互。 用户可以首先与帐户 管理器系统交互， 以建立和使用帐户 ( 例如， 每个用户通过使用用户计算系统的存储器 457 中执行的浏览器 458)， 以指定签入信息、 联系人信息、 财务信息等等， 这些信息存储在存储 装置 430 的用户帐户数据库 432 的数据结构中——在一些实施例中， 帐户管理器系统和 / 或一个或更多个其他从属系统 ( 未示出 ) 还可以向用户提供多种类型的功能， 如在线购物 功能、 消息收发服务功能、 信息访问功能等等。所示的访问管理器系统 423 的实施例包括提供各种功能的若干管理器组件， 包括客户注册管理器组件 421、 用户交互管理器组件 422、 证书管理器组件 424、 客户状态管理器组件 425 以及客户验证管理器组件 426， 然而在其他 实施例中， 可以代之以以其他方式来组织管理器组件的功能。客户注册管理器组件与服务 的运营者和其他代表进行交互， 以将这些服务注册为访问管理器系统的客户， 并定制签入 和要向服务的用户提供的其他功能， 其中， 将客户提供的信息存储在存储装置的客户信息 数据库 440 的数据结构中。在预期客户服务注册为客户之后， 一个或更多个用户可以与服 务和客户服务计算系统提供的其他功能进行交互， 并可以被定向至访问管理器系统来执行 对客户服务的签入。 然后， 用户交互管理器组件与用户交互， 如基于先前存储的用户帐户信 息和 / 或基于将该用户注册为帐户管理器系统的新用户 ( 不论直接还是通过重定向用户来 与帐户管理器系统交互 )， 以便为客户服务提供定制的签入过程。此外， 在一些实施例中， 用户交互管理器组件以定制的方式收集用户的各种信息， 并将该信息存储在收集用户信息 数据库 436 的数据结构中。如果签入尝试成功， 则证书管理器组件将产生代表用户的证书， 将证书信息存储在存储装置的证书数据库 438 的数据结构中， 并将该证书返回至客户服务 ( 例如经由对被重定向回客户服务的用户的响应 )， 以在客户服务的计算系统的存储装置 471 上将其存储为证书 473， 并可选地提供所收集的用户的任何信息。 然后， 客户服务可以与帐户管理器和 / 或访问管理器系统交互， 如通过提供代表 用户的证书， 以代表用户执行各种动作 ( 例如修改和 / 或使用用户的帐户信息 )。在一些 情况下， 客户服务可以将用户定向至从属服务计算系统提供的从属服务， 其中， 将授予客户 服务的针对用户的证书提供给该从属服务， 并在该从属服务计算系统的存储装置 491 上将 其存储为证书 493。然后， 可选地， 从属服务可以类似地将用户重定向， 以与帐户管理器系 统和 / 或访问管理器系统进行交互， 以便代表用户执行动作。客户服务 ( 或其代表 ) 也可 以与客户状态管理器组件交互， 以获得关于服务的各种信息， 包括关于服务自身与访问管 理器系统的客户帐户的信息和从收集用户信息数据库收集的用户信息。此外， 在至少一些 实施例中， 一些客户服务中的每一个可以请求访问管理器系统和帐户管理器系统提供附加 定制功能来跟踪并提供与客户服务的用户的动作有关的多种类型的信息， 以向客户服务提 供该客户服务可以拥有的多数或全部与用户相关的信息 ( 如果客户服务实现了其自己的 签入服务 )。如果是这样， 将这样的用户信息存储在备选的用户池数据库 434 的数据结构 中， 并由客户状态管理器组件向这些客户服务提供该用户信息， 而在所示的实施例中， 不向 这些客户服务提供关于其他用户 ( 或者在与其他服务交互时， 关于相同用户 ) 的类似的详 细信息。
在至少一些实施例中， 使用客户验证管理器组件来提供各种附加安全措施， 该附 加安全措施是关于客户服务与访问管理器系统和 / 或帐户管理器系统的交互。特别地， 在 这样的实施例中， 从客户服务发出的至少一些消息必须包括数字签名， 该数字签名是基于 该消息中的信息， 使用该服务和客户验证管理器组件已知的秘密访问密钥 ( 例如在服务的 初始注册期间确定的及服务信息数据库 440 中存储的秘密访问密钥 ) 来产生的——在所示 的实施例中， 客户服务经由客户服务的计算系统 470 的存储器 477 中执行的签名产生器组 件 478， 使用该客户服务的秘密访问密钥 ( 未示出 ) 来产生这样的数字签名。如果是这样， 则客户验证管理器组件验证所包括的数字签名 ( 例如通过使用该组件已知的针对该客户 的秘密访问密钥来产生新的匹配数字签名以对其进行复制 )， 以在其他系统或组件响应接
收到的消息之前对该消息进行鉴权。在至少一些实施例和情况中， 还可以针对至少一些从 属服务来执行这样的消息鉴权。此外， 在一些实施例中， 类似地， 可以使用一个或更多个相 关服务的秘密访问密钥来对其他类型的消息进行数字签名， 并基于该数字签名对消息进行 鉴权。例如， 这些消息包括由接收服务鉴权的从访问管理器系统和 / 或帐户管理器系统至 客户服务或从属服务的消息、 在客户验证管理器组件的协助下鉴权的客户服务和从属服务 之间的消息 ( 除非该服务能够访问其他服务的秘密访问密钥 ) 等等。
可以认识到， 所示的计算系统仅是示意性的， 不应意欲限制本发明的范围。 访问管 理器计算系统 400 可以与未示出的其他设备连接， 包括通过如因特网或 Web 之类的一个或 更多个网络。更一般地， 各种计算系统中的每一个可以包括能够以上述方式进行交互的硬 件和软件的任何组合， 包括计算机、 网络设备、 因特网设备、 PDA(“个人数字助理” )， 无线电 话、 寻呼机、 电子记事簿、 基于电视的系统和包括互相通信能力的其他各种消费品。此外， 在一些实施例中， 可以将图 4 所示的访问管理器系统组件所提供的功能组合在更少的组件 中， 或分布在附加的组件中。 类似地， 在一些实施例中， 可以不提供一些所示的组件的功能， 且 / 或可以提供其他附加功能。
本领域技术人员也可以认识到， 虽然在使用时将各种项目示为被存储在存储器或 存储装置中， 但是， 出于存储器管理和数据完整性的目的， 可以在存储器和其他存储设备之 间传递这些项目或其部分。 备选地， 在其他实施例中， 一些或全部软件组件可以在另一个设 备的存储器中执行， 并经由计算机间通信， 与所示的计算系统或设备进行通信。 也可以在计 算机可读介质 ( 如硬盘、 存储器、 网络或由合适的驱动器读取的便携式物件 ) 上存储一些或 全部访问管理器系统组件或数据结构 ( 例如指令或结构化数据 )。也可以将访问管理器组 件和数据结构作为在多种计算机可读传送介质 ( 包括基于无线的和基于有线的 / 线缆的介 质 ) 上产生的数据信号 ( 例如作为载波的一部分 ) 来传送。相应地， 可以使用其他计算机 系统配置来实施本发明。
图 5 是客户注册管理器过程 500 的示例实施例的流程图。例如， 可以通过执行图 4 的客户注册管理器组件 421 来提供该过程， 以与服务的运营者和其他代表进行交互， 以定 制签入和要向服务的用户提供的其他功能。
该过程从步骤 505 开始， 在该步骤中， 从服务的运营者或其他代表接收到作为客 户向访问管理器注册该服务的指示。在步骤 505 之后， 在步骤 510 中， 该过程如以交互的方 式， 通过显示询问信息的页面 ( 例如， 如图 2A 所示 ) 或代之以作为程序化访问的 API 的一 部分， 来接收关于服务的信息。在步骤 510 接收信息之后， 如基于该服务和 / 或运营者是 否被确定为足够值得信任 ( 例如使用步骤 510 中获得的信息 ) 和 / 或基于其他准则， 该过 程确定是否接受该客户。如果不接受该客户， 则该过程前进至步骤 520， 以发送注册拒绝消 息， 然后继续至步骤 590。否则， 在步骤 530， 如基于针对该服务和 / 或运营者来评估的信任 度， 并可选地基于如从服务动作产生的访问管理器的任何责任 ( 例如， 基于服务的类型、 服 务的用户数、 该客户能够使用的品牌联合和 / 或其他定制的类型， 如是否允许客户指定和 使用可执行代码等 )、 访问管理器与该客户之间的任何过去的经历等等， 该过程确定授予该 客户的许可等级。 此外， 在一些实施例中， 可以对客户收取更多费用以接收更高的许可等级 ( 例如作为高级服务的一部分 ) 并从而获得附加功能。所增加的收费可以至少部分基于该 客户将访问管理器暴露给责任的能力和 / 或可能性， 如通过将机密或敏感用户信息暴露给未授权用户、 通过允许未授权用户进行财务往来或代表用户执行操作等等。在至少一些实 施例中， 在以后的时间可以再检查并改变客户的许可等级。在步骤 530 中确定了许可等级 之后， 根据所授予的许可， 该过程确定是否允许该客户配置任何品牌， 如果是， 则确定该客 户是否拥有任何这样的品牌。如果是这样， 则该过程前进至步骤 540， 在该步骤中合适地配 置品牌。
否则， 或在步骤 540 之后， 该过程前进至步骤 545， 在该步骤中， 根据所确定的许可 等级， 显示该客户可用的品牌联合定制的类型， 如针对第一个品牌和 / 或针对全部品牌 ( 如 果在步骤 540 中配置了品牌 )。在一些实施例中， 显示可以是 Web 页面， 并可以包括与图 2B 和 / 或 2C 类似的用户界面。 在显示了可用的品牌联合定制的类型之后， 在步骤 550， 该过程 可选地接收品牌联合定制的一个或更多个指示， 并将其存储以待后用。 在一些实施例中， 如 果可以对多个页面或其他信息组进行品牌联合， 则可以单独地配置每个页面。在步骤 555， 根据所确定的许可等级， 显示该客户可用的信息收集的预定义类型， 在步骤 560 中， 可选地 接收信息收集定制的一个或更多个指示， 并将其存储以待后用。在步骤 565， 根据所确定的 许可等级， 显示该客户可用的权威机构委托的预定义类型， 可选地接收权威机构委托定制 的一个或更多个指示， 并将其存储以待后用。在步骤 568， 如果配置了多个品牌并对其各自 进行定制， 则该过程返回步骤 545 以启动下一个品牌的配置， 如果没有配置品牌， 则 ( 如果 合适 ) 该过程前进至步骤 570 以执行附加处理 ( 例如， 在合适的数据存储装置中存储各种 信息、 产生并向客户提供唯一标识符和秘密访问密钥等等 )。然后， 该过程前进至步骤 590 以确定是否继续。如果是， 则该过程返回步骤 505， 如果否， 则该过程在步骤 599 结束。
在备选实施例中， 可以以其他方式来执行所示的过程。 例如， 虽然该过程示出了可 以对多种类型的定制配置每个品牌， 但是在一些实施例中， 品牌可能只能具有各自配置的 品牌联合定制。 在其他实施例中， 可以以不同的顺序来指定定制， 如果访问管理器的客户没 有用于配置特定类型的定制的许可， 则可以跳过与该类型的定制相关的步骤。 例如， 如果客 户没有用于从用户收集信息的许可， 则该过程可以跳过步骤 550 至 565。虽然这里没有示 出， 但是在一些实施例中， 该过程可以另外使用各种其他安全信息和 / 或机制， 以验证客户 代表的身份。
图 6 是用户交互管理器过程 600 的示例实施例的流程图。例如， 可以通过执行图 4 的用户交互管理器组件 422 来提供该过程， 以代表客户服务与用户交互， 以提供该客户服 务所指定的定制的签入过程。
在步骤 605， 该过程代表客户服务接收与用户相关的请求的指示， 如针对用户要签 入该服务。在所示的实施例中， 该请求包括与该客户相关联的客户标识符和以专用于该客 户的方式产生的请求的数字签名。然后， 客户验证管理过程 ( 如图 9B 所示 ) 检查该请求所 附的数字签名， 如果在步骤 610 确定该签名无效， 则该过程继续至步骤 680 以发送失败通 知， 然后继续至步骤 690。如果该签名有效， 则该过程代之以继续至步骤 615 以确定该请求 的类型。如果该请求是针对除了签入之外的事务， 则在步骤 685 中合适地执行所请求的操 作。如果该请求是签入请求， 则在步骤 620 中检索与所接收的客户标识符相关联的客户先 前配置的定制， 在步骤 625， 使用所定制的品牌联合的内容产生签入页面并向用户发送。然 后， 在步骤 630， 该过程确定用户是否具有该访问管理器的帐户， 如果没有， 则在步骤 640， 该过程获得关于用户的信息并向访问管理器注册该用户。 如果该用户已经拥有访问管理器提供者的帐户， 则在步骤 635， 从用户接收签入信息， 在步骤 645， 确定该签入信息是否有效 ( 例如匹配所存储的该用户的签入信息 )。如果签入信息无效， 则该过程继续至步骤 680 以 向用户发送失败通知。
如果该签入信息有效， 或在步骤 640 之后， 则在步骤 650， 产生要提供给服务 ( 或在 其他实施例中， 如针对指定的时间段或根据其他所指示的准则， 提供给用户以使用一个或 更多个服务 ) 的证书或用户有效签入的其他指示。然后， 在步骤 655， 如基于先前的定制或 当前情况， 该过程确定是否检索要提供给服务的关于用户的附加信息 ( 例如用户名、 唯一 标识符、 真实姓名等等 )， 如果是， 则继续至步骤 660 以合适地检索附加信息。 在一些实施例 中， 授予客户的许可等级可以限制客户服务获得该附加信息的能力。在步骤 660 之后， 或者 如果没有检索到附加信息， 则在步骤 665， 如基于先前的定制或当前情况， 该过程确定是否 要收集关于用户的任何信息， 如果是， 则继续至步骤 670 以合适地收集关于用户的信息。在 步骤 670 之后， 或者如果没有收集到信息， 则如经由使用 HTTP 重定向功能的用户， 向客户发 送证书且可选地发送其他数据 ( 例如所检索到的和 / 或所收集的信息 )。在步骤 675、 680 或 685 之后， 在步骤 690， 该过程确定是否继续。如果是， 则该过程返回步骤 605， 如果否， 则 在步骤 699 结束。
图 7 是证书管理器过程 700 的示例实施例的流程图。 例如， 可以通过执行图 4 的证 书管理器组件 424 来提供该过程， 以产生代表用户的证书并执行其他与证书相关的活动。
该过程开始于步骤 705， 在该步骤中， 接收与证书相关的请求， 如从外部服务或另 一个访问管理器组件——这取决于该请求， 该请求也可以包含附加参数， 包括已有的证书 ( 基于此而执行该请求 )。在接收到请求之后， 该过程前进至步骤 710， 在该步骤中， 确定 接收到的请求是否是要为服务产生新的证书来代表用户， 如来自用户交互管理器组件的请 求。 如果是， 则在步骤 715， 合适地创建证书 ( 如通过将唯一随机数映射到用户， 或检索关于 用户的信息以包括作为证书的一部分 )， 该过程继续至步骤 770 以存储该证书并可选地将 其提供给请求方。如果该请求不是要产生证书， 则在步骤 720， 该过程确定该请求是否是要 更新已有的证书以扩展其有效期， 如来自起初被授予了该证书的服务的请求。 如果是， 则在 步骤 722， 该过程确定该请求方是否具有更新该证书的许可 ( 例如， 基于授予该请求方的许 可等级和 / 或该证书所代表的用户在例如签入至服务期间指定的信息 )。 如果许可存在， 则 在步骤 724， 在该过程继续至步骤 770 之前更新该证书。 如果没有足够的许可来更新该用户 证书， 则在步骤 729 指示错误消息， 该过程前进至步骤 795。
如果在步骤 720 确定该请求不是要更新该证书， 则该过程前进至步骤 730 以确定 该请求是否是要复制已有的证书， 如来自次要从属服务的请求是否是要获得授予该次要服 务所从属的主要客户服务的用户证书。如果是， 则该过程继续至步骤 732， 如基于从主要服 务委托给该次要服务的权威机构， 确定证书复制是否被授权。此外， 在一些实施例中， 复制 代表用户的证书可以包括请求用户提供信息或可选地同意或确认该复制， 在这样的实施例 中， 确定该复制是否被授权还可以至少部分基于用户的动作。如果在步骤 732 确定这样的 许可存在， 则在步骤 734 复制该证书， 该过程继续至步骤 770， 如果不存在， 则在步骤 739 发 送发生错误的指示， 该过程前进至步骤 795。
如果在步骤 730 确定该请求不是要复制证书， 则该过程前进至步骤 740 以确定该 请求是否是要验证证书是否有效。如果是， 则在步骤 745， 该过程确定该证书当前是否对请求方有效， 可选地， 确定是否对所指示的动作有效， 并向请求方发送该证书的有效性的指 示。如果该请求不是要确定证书是否有效， 则在步骤 750， 该过程确定该请求是否是要确定 该证书何时到期。如果是， 则在步骤 755， 该过程确定到期时间并将其指示给请求方， 如果 否， 则该过程继续至步骤 760 以合适地响应其他类型的请求。 在步骤 729、 739、 745、 755、 760 或 770 之后， 在步骤 795， 该过程确定是否继续。如果是， 则该过程返回步骤 705， 如果否， 则 在 799 结束。
图 8 是客户状态管理器过程 800 的示例实施例的流程图。例如， 可以通过执行图 4 的客户状态管理器组件 425 来提供该过程， 以向客户提供各种类型的信息。
该过程开始于步骤 805， 在该步骤中， 从客户接收请求。在步骤 810， 如通过与客户 验证管理器组件进行交互和 / 或基于授予该客户的许可等级， 该过程确定该请求是否被授 权。如果否， 则该过程前进至步骤 895， 否则， 在步骤 815-860 中， 确定该客户是否已请求修 改各种类型的信息， 如果是， 则合适地执行修改。在所示的实施例中， 客户可以修改的信息 的种类包括品牌联合定制 ( 在步骤 815 和 820)、 信息收集定制 ( 在步骤 825 和 830)、 权威 机构委托定制 ( 在步骤 835 和 840)、 品牌 ( 在步骤 845 和 850) 以及客户帐户信息 ( 在步骤 855 和 860)。如果所接收的请求不是要修改信息， 则在步骤 865， 该过程确定该请求是否是 要监控用户。如果是， 则在步骤 870， 检索先前跟踪的用户信息并将其提供给客户， 如果否， 则该过程继续至步骤 875 以合适地执行其他所请求的功能。 在步骤 820、 830、 840、 850、 860、 870 和 875 之后， 或者如果在步骤 810 中确定该请求未被授权， 则该过程继续至步骤 895 以 确定是否继续。如果是， 则该过程返回步骤 805， 如果否， 则在步骤 899 结束。
图 9A 和 9B 是对接收的消息进行鉴权的过程的示例实施例的流程图， 其中， 图 9B 示出了验证管理器过程 925 的示例实施例， 图 9A 示出了对应的客户端验证过程 900 的示例 实施例。例如， 可以通过执行图 4 的客户验证管理器组件 426 来提供该验证管理器过程， 以 提供与从客户服务和其他服务输入的消息相关的各种附加安全措施。 例如， 可以通过与图 4 的签名产生器组件 478 结合的客户服务的计算系统来提供该客户端验证过程， 以对向访问 管理器发出的消息使用附加安全措施。
图 9A 的客户端过程 900 开始于步骤 905， 在该步骤中， 接收产生从客户服务发出 的、 包括各种信息的消息的指示， 其中， 收集各种信息用于出于安全目的产生客户专用的数 字签名以伴随该消息。 在一些实施例中， 用于产生该签名的信息包括消息的至少一些内容， 和消息中不包括的其他信息， 如秘密访问密钥。此外， 在一些实施例中， 可以在用于产生签 名的信息中添加其他信息， 如当前时间戳 ( 例如， 如果截取到消息， 则用于防止该消息以后 被再次使用 )。要发送的消息可以具有各种形式， 包括使用 URL 或其他 URI(“统一资源标 识符” ) 来发送的 HTTP 请求， 在该 HTTP 请求中， 包括了消息内容作为一个或更多个询问字 符串参数值的一部分， 以及其中包括了数字签名作为另一个询问字符串参数的值。在步骤 910， 该过程基于所收集的信息， 如通过使用先前选择的数字签名算法并使用先前选择类型 的消息信息 ( 例如， 按特定顺序的特定消息参数值 )， 来产生数字签名。在步骤 915， 在发送 出消息之前， 向该消息添加签名， 然后， 直到要发送下一个签名消息之前， 该过程在步骤 920 结束。
图 9B 的验证管理器过程 925 开始于步骤 927， 在该步骤中， 接收对输入消息的验证 的请求， 如从访问管理器系统或其一个组件接收到的与从客户服务或从属服务接收到的消息相关的请求。 在步骤 930， 如基于自该消息所附的时间戳起过去的时间是否超过预定的时 间段， 该过程首先确定该消息是否足够新。 如果时间戳太早， 则在步骤 970， 该过程发送签名 无效的指示， 在步骤 975， 可选地执行合适的附加处理 ( 例如， 如果看到无效消息的模式， 则 产生通知 )。然后， 该过程前进至步骤 995。
如果该时间戳足够新， 则该过程前进至步骤 935， 检索所存储的客户 ( 从该客户接 收到消息 ) 的秘密访问密钥 ( 如基于消息中包括的、 与该秘密访问密钥相关联的被分配给 该客户的标识符 )。在其他实施例中， 可以以其他方式， 如基于 IP 地址 ( 从该 IP 地址接收 到该请求 ) 来标识客户或其他从属服务。在步骤 935 检索到秘密访问密钥和关于该客户的 任何附加信息之后， 在步骤 940 和 945， 以与之前关于图 9A 的步骤 905 和 910 所描述的相同 的方式， 如使用该消息 ( 不包括数字签名 ) 中包括的信息和检索到的秘密访问密钥， 该过程 产生该消息的数字签名。然后， 在步骤 950， 相对该消息中包括的签名， 检查新产生的签名。 如果在步骤 955 确定两个数字签名相同， 则验证了该消息， 并在步骤 960 发送对应的确认。 如果该消息未被验证， 则认为其是伪造的， 并在步骤 965 发送对应的指示。在步骤 960、 965 或 975 之后， 该过程前进至步骤 995， 在该步骤中确定是否继续。 如果是， 则该过程返回步骤 927， 如果否， 则在步骤 999 结束。
虽然这里没有示出， 但是在一些实施例中， 服务可以使用类似的技术来验证来自 访问管理器的消息。 此外， 各种实施例可能具有超出图 9A 和 9B 所示的基于签名的验证的附 加安全特征和机制， 如在服务的代表初始注册服务时， 收集关于该服务代表的身份的信息。
因此， 可以使用各种技术来向服务提供可定制的签入和其他功能， 并使用各种技 术来增强交互的安全性。此外， 在一些实施例中， 可以使用多种附加信息和技术。例如， 访 问管理器的客户中的客户可以包括服务 ( 如电子商务 Web 站点 )， 并可以与访问管理器的提 供者不相关。访问管理器授予客户的许可等级也可以变化， 如向著名的受尊重的站点授予 比不知名的站点更高的许可等级。此外， 低等级的品牌联合许可可以仅允许访问管理器的 客户指定要使用的图像和文本， 而具有更高等级许可的访问管理器的客户可能能够添加图 像、 图像映射 ( 当用户选择图像的任何部分或指定部分时提供功能 )、 指定类型的用户可选 择功能 ( 例如具有下拉式按钮的标题 )、 文本、 链接、 背景音乐、 JavaScript 代码、 Flash 动 画、 Shockwave 电影、 Java applet、 定制的 CSS(“层叠样式表” ) 样式等等。在一些实施例 中， 在实时或接近实时的过程中自动进行许可的授予， 而在其他实施例中， 该过程可能花费 更长时间 ( 例如允许对服务手动重新检查 )。 此外， 在一些实施例中， 如周期性地， 可以重新 检查和修改授予客户的许可等级。 例如， 如果出现了与客户相关的问题或影响， 则可以降低 许可等级。相反， 如果没有出现这样的问题， 则可以提高许可等级， 如授予一些或全部新客 户低许可等级， 如果与客户的连续的体验保证了该许可等级， 则可以逐渐提高许可等级。 例 如， 可以基于分析或检查客户或代表客户的流量和 / 或使用模式来提高许可。在一些实施 例中， 外部因素可以触发所授予的许可等级的检查， 该外部因素如关于客户的新闻或客户 的变化 ( 例如合并或买断客户、 破产等等 )。
可以使用各种类型的服务作为从属服务， 包括 ( 但不限于 ) 支付处理器、 信用卡验 证服务、 消费者调查服务、 广告服务、 执行服务等等， 在一些实施例中， 访问管理器的提供者 可以提供其服务中的一些作为从属服务。在一些情况下， 可以向从属服务提供对客户或用 户的信息子集的访问， 以便于提供其服务——例如， 消费者调查服务可能想知道何时向消费者运送特定产品和联系人信息， 以便执行对关于产品和服务的消费者的后续行动。
在各种实施例中， 从服务向访问管理器发送的消息或其他请求可以采取多种形 式。在一些实施例中， 请求可以是具有消息参数或作为询问字符串传递的其他内容的 HTTP 消息， 优选地， 通过安全的手段 ( 例如安全 HTTP) 或以离线的方式 ( 例如经由实际邮件、 电话等 ) 来发送至少一些信息 ( 例如秘密方法密钥、 机密的用户签入信息和其他用户信 息等 )。类似地， 用户的签入信息或其他标识信息可以具有各种形式， 如用户名和密码、 各 种生物统计学信息、 基于 PKI 的信息等。在一些实施例中， 可以将证书作为 Web 浏览器的 cookie 来交换， 或备选地以 WS-Federation Passive Profile 指定的格式 ( 例如 WS-Trust RequestSecurityTokenResponse XML 元素 ) 或基于其他签入规范标准 ( 例如基于 Liberty Alliance Project、 基于 Microsoft 的 Passport 服务等等 ) 来交换。 类似地， 在一些实施例 中， 可以以各种方式来执行签入过程， 如经由 WS-Federation Passive Requestor Profile 中指定的过程。
如前所述， 在一些实施例中， 至少一些客户服务可以请求对针对服务的用户的备 选数据池的建立和使用， 以跟踪与用户的多种类型的交互。 例如， 备选数据池可以存储关于 用户的信息， 如购买、 所查看的产品或服务， 登录次数、 所做的信息修改和非该客户服务专 用的用户的历史活动或其他活动的可能的信息， 在一些实施例中， 可以允许客户配置在该 备选数据池中存储哪些数据。在一些实施例中， 备选数据池对客户的可用性可以取决于授 予该客户的许可等级。
在一些实施例中， 如周期性地， 或如果秘密访问密钥被损坏， 可以修改或重新产生 秘密访问密钥。此外， 通过将关于如何使用该秘密访问密钥的信息维持在仅对合适的接收 者可用， 并此外可选地对不同客户使用不同的过程， 可以获得附加的安全性。 在一些实施例 中， 所指示的过程可以包括参数列表 ( 消息要包括其值 )、 消息参数的顺序、 要使用的编码 的类型， 且可以以各种方式 ( 例如服务运营者在手动地将该过程并入该服务时所使用的文 档、 给出各种输入以执行该过程的可执行代码等等 ) 向客户指示过程。可以以各种方式来 产生数字签名， 如通过使用消息鉴权码 ( 例如， 具有 MD5(“消息摘要算法 5” ) 的 HMAC(“密 钥散列消息鉴权码” ))。
本领域技术人员也可以认识到， 在一些实施例中， 可以以备选的方式来提供由上 述过程所提供的功能， 如可以将该功能在更多的过程中分割， 或合并为更少的过程。类似 地， 在一些实施例中， 所示的过程可以提供比所述的更多或更少的功能 ( 如当其他所示的 过程代之以分别缺少或包括这样的功能时， 或当提供的功能的量改变时 )。此外， 虽然可能 将各种操作示为以特定的方式 ( 例如串行或并行 ) 和 / 或按特定的顺序来执行， 但是本领 域技术人员可以认识到， 在其他实施例中， 可以按其他顺序、 以其他方式来执行这些操作。 本领域技术人员也可以认识到， 可以以不同的方式来构造上述数据结构， 如通过将单个数 据结构分割至多个数据结构， 或通过将多个数据结构合并为单个数据结构。 类似地， 在一些 实施例中， 所述的数据结构可以存储比所述的更多或更少的信息 ( 如当其他所示的数据结 构代之以分别缺少或包括这样的信息时， 或当存储的信息的量或类型改变时 )。
从上述内容可以认识到， 虽然这里出于示意的目的描述了具体实施例， 但是， 在不 背离本发明的精神和范围的前提下， 可以做出各种修改。 相应地， 除了所附的权利要求及其 中所引用的元素， 都不能限制本发明。 此外， 虽然以下以特定权利要求的形式呈现了本发明的特定方面， 但是发明者能够想到采用任何可用的权利要求的形式的本发明的各个方面。 例如， 虽然当前将本发明的仅一些方面引用为在计算机可读介质上实现， 但是也可以类似 地这样实现其他方面。