IBM Business Analytics 最佳实践: IBM Cognos BI 身份验证和单点登录

简介文档目的

本文提供在安全系统与 IBM cognos BI 之间实现无缝身份验证的指南。具体地讲，文中将包含以下重要信息：

• 涉及的技术概念和背景
• IBM Cognos BI 中的身份验证和单点登录 (SSO) 的设计
• 与受支持和不受支持的环境有关的设置要求
• 必须收集来排除 IBM Cognos BI 问题的一些信息
  

适用性

本文的目标读者是为包含 IBM Cognos BI 的系统设计身份验证的安全架构师和管理员。

例外和除外责任

本文不会介绍实现一次迁移的具体设置或步骤，出于举例目的的步骤除外。有关设置一种具体集成的指南或逐步操作说明，请参阅 ( IBM developerWorks 业务分析专区) 的 “最佳实践” 区域中的 “安全” 一节，可能那里已经介绍了您想要执行的集成。如果没有找到相关的信息，请联系 IBM 业务分析最佳实践团队或 IBM Cognos 产品管理团队。

假设

假设读者熟悉 “IBM Cognos BI 安装和配置指南” 和 “IBM Cognos BI 管理和安全指南” 的内容。两篇文档都随产品一起提供，您也可以从 IBM Cognos BI 信息中心在线获取这些文档。另外，我们假设读者对适用于 Web 应用程序的安全概念有一定的了解。

回页首

概述

IBM Cognos BI 作为 IBM 的业务分析产品组合的一部分，常常与其他软件解决方案相集成。一个最常见的需求是向用户提供无缝的身份验证体验，这常常被称为 单点登录到 Cognos 。

一般来讲，这适用于（但不限于）IBM WebSphere Commerce、IBM Tivoli WebSEAL、IBM WebSphere Portal、IBM Tivoli Common Reporting 或 IBM WebSphere 等 IBM 产品。此外，还有与第三方身份验证代理的集成，比如 eTrust、CA SiteMinder 和 Oracle Oblix，以及 Web 服务器和/或应用服务器，比如 Microsoft 的 IIS、Apache 和 SAP NetWeaver。

向 IBM Cognos BI 提供 SSO 功能涉及到多种挑战，

• 知识挑战
  • IBM Cognos BI 中的身份验证
  • IBM Cognos BI 单点登录概念
    
• 技术挑战
  • 设置
  • 配置
  • 测试
  • 问题排除
    
• 支持状态
  

以下各节将通过向系统管理员和安全架构师深入介绍 IBM Cognos BI 所利用的设计概念和技术来解决这些挑战。提供的指南使管理员能够处理 SSO 需求，策划集成身份验证功能与 IBM Cognos BI 的解决方案。

回页首

IBM Cognos BI 中的身份验证

本章节将全面介绍 IBM Cognos BI 中的身份验证流程所涉及的概念和组件。

服务、请求和会话

IBM Cognos BI 是一个构建于 面向服务架构 (SOA) 之上的 Web 应用程序。所有功能都由一组独立的多实例 Web 服务提供，这些服务通过网络使用 SOAP 协议与客户彼此通信。一个特殊服务（Presentation Service）代理了基于纯 HTML 的客户端（比如浏览器）发出的请求。

客户端（可能是浏览器，或其他某个开发的或基于 IBM Cognos BI 软件开发工具包 (SDK) 的客户端）使用 HTTP 协议将请求发送给一个有效的 IBM Cognos BI 入口点 。

通常，这个入口点是一个部署到 Web 服务器的 IBM Cognos BI 网关 (GW)，但它也可以是一个应用服务器（比如 IBM WebSphere）托管的 IBM Cognos BI Dispatcher (DISP) Java servlet 或 Servlet 网关 (SGW)。每个请求都会显式或隐式地要求某个服务处理它，在没有请求任何显式的目标服务时，假设 Presentation Service 是目标服务。因此，发送给 IBM Cognos BI 入口点的每个请求必须路由到目标实例的一个支持这种特定类型请求的实例。

路由是由一个 Dispatcher 处理的，无论请求是直接发送还是通过网关间接发送给 Dispatcher。每个网关一次仅将收到的请求转发给一个 Dispatcher。

该 Dispatcher 检查每条传入请求中的 sessionID，该信息将指示该请求是一个已建立的 HTTP 会话的一部分。如果没有找到 sessionID，那么它会假设启动了一个新会话并创建一个新 sessionID。接下来将向请求分配一个 requestID，并将 sessionID 和 requestID 都添加到请求中。这样就可以识别一个会话中的请求，确保依据安全最佳实践为每个请求分配了惟一的 requestID。

由于 SOA 中的服务在逻辑上是独立的，所以身份验证是在 HTTP 会话级别上而不是在服务级别上处理的。每个服务在接受和处理一个请求之前都会检查是否存在一个已经过验证的会话，以防止非故意的访问。这可以确保发出请求的客户端被识别并链接到一个身份。

从 IBM Cognos BI version 10 开始，身份验证功能由内部 CAM_AsyncAAService集中提供，该服务只能通过 Content Manager Service (CMS) 进行间接连接。因此，所有 IBM Cognos BI 服务都将采用 CMS 来验证会话身份验证，或者触发对未验证的服务的身份验证。CMS 被实现为一个 Java servlet，是 IBM Cognos Content Manager (CM) 的服务接口，而后者是能够独占地访问 IBM Cognos BI 的应用程序存储库（称为 Content Store (CS)）的中央组件。

Dispatcher 处理请求时，它会首先检查收到的请求所属的当前会话的身份验证状态。如果不存在会话，则会隐式地创建一个新会话 ID，而该请求将会自动成为新会话的第一个请求。如果会话还未验证，Dispatcher 会采用 CAM_AsyncAAService 来运行身份验证流程，并将请求传递给它。CAM_AsyncAAService 服务是处理 身份验证和授权 (AA) 的 Cognos Access Manager (CAM) 子组件的一个服务接口。其他未通过 CAM_AsyncAAService 服务公开的 CAM 组件将处理加密等任务（比如 CAM-CRP）。然后，CAM 的 AA 子组件会采用 身份验证提供程序 (AP)（在一个独立的进程中运行）来附加到外部 身份验证来源 ，以便执行会话身份验证流程。此流程的详细信息将在后面的 身份验证流程 一节中介绍，现在还有其他一些概念需要介绍。

插图 1 给出了请求流图解和涉及的服务和组件。

插图 1：IBM Cognos BI 会话身份验证涉及的组件图解

如果身份验证成功，那么会话的身份验证信息将会持久保存在一个内部 Content Manager 对象中，并将此对象的一个 base64 编码的、带签名的引用附加到 HTTP 会话上。

所有服务都可以确认会话的请求的验证状态，方法是调用 CAM_AsyncAAService 并提供对该会话的持有身份验证信息的内部 Content Manager 对象的引用。在发现由于对引用的对象的确认失败而导致会话未通过验证时，将会再次触发身份验证流程。

会话的身份验证在一个可配置的空闲时期过后过期，这个时期可在 IBM Cognos Configuration 中指定。配置的超时意味着，在这段特定的时期内，会话的身份验证对象不会被发送到 CAM_AsyncAAService 的确认请求刷新。在超过期限后，将会删除会话的内部 Content Manager 对象，让保存到 HTTP 会话的引用失效。

身份验证提供程序和命名空间

IBM Cognos BI 身份验证的工作原理是，通过一个称为 身份验证提供程序 的软件将实际的身份验证工作委托给外部身份验证来源。

每个身份验证提供程序附加到一个特性类型的身份验证来源，比如一个兼容轻型目录访问协议 (LDAP) 的服务或一个 Microsoft Active Directory (AD) 域控制器。利用身份验证来源所提供的 API，身份验证提供程序将会实现必要的功能来处理身份验证流程，然后从附加的身份验证来源读取安全对象。一定要注意的是，身份验证提供程序仅从身份验证来源读取信息，绝不会向它们写入信息。

IBM Cognos BI 知道的安全对象包括 用户、组 和 角色 。身份验证来源要求至少支持并存储这 3 种类型的安全对象。如果一个身份验证来源使用其他或更多安全对象来表示用户、组或角色，那么身份验证提供程序必须将它们映射到 IBM Cognos BI 已知的 3 种类型之一。

如果一个身份验证提供程序基于提供给它的凭据，成功地向身份验证来源执行了验证，那么此验证结果也满足了 IBM Cognos BI 的要求。

许多身份验证提供程序还将通过使用一些基于 HTTP 会话的令牌来提供对单点登录 (SSO) 的支持，从而允许在非 IBM Cognos 安全层与 IBM Cognos BI 之间实现无缝的身份验证。

因为身份验证提供程序依赖于身份验证来源的 API 来实现附加到它的功能并处理身份验证，所以在对身份验证提供程序的支持方面，可能存在与平台相关的限制。不是所有身份验证来源都可用于 IBM Cognos BI 支持的所有平台，因此这些平台上也不一定支持它们的 API。请参阅相关 IBM Cognos BI 产品版本的 “支持的软件环境” 页面中的 身份验证提供程序 一节 ( http://www.ibm.com/support/docview.wss?uid=swg27014782 )。

除了下一节将介绍的一种特殊类型的提供程序，每个身份验证提供程序都由 IBM Cognos Configuration 中创建的一个 命名空间配置 实例来配置。在命名空间配置中，可以配置特定于该提供程序实例的属性。最重要的一个属性是 NamespaceID ，该字符串在内部惟一地表示该身份验证提供程序实例。启动 IBM Cognos BI CAM 组件时，会在配置中扫描命名空间配置，并根据指定的设置来初始化各个提供程序。完成初始化之后，除了之前提到的一个特殊类型之外，所有身份验证提供程序实例都将通过一个 IBM Cognos BI Namespace 公开从外部身份验证来源读取的对象。命名空间是映射到与 IBM Cognos BI 相关的安全对象的外部身份验证来源的数据的表示。对于一个 IBM Cognos BI 系统，可以同时配置多个命名空间，允许在异构身份验证来源中管理的用户访问 IBM Cognos BI，甚至可能允许在单个会话中向多个身份验证来源执行验证。

对于每个 IBM Cognos BI 系统，一个称为 Cognos Namespace 的特殊的内置命名空间只有一个实例，该实例自动被初始化，没有命名空间配置对象。它没有附加到一个实际的身份验证来源，也不包含任何用户对象，它只包含组和角色对象。Cognos Namespace 用于为具有附加到外部身份验证来源的命名空间的安全对象和应用程序定义的授权对象提供一个逻辑映射层。出于此用途，可以在 Cognos Namespace 中创建组和角色，并从其他所有配置的命名空间分配成员。

IBM Cognos BI 的安全最佳实践仅基于来自 Cognos Namespace 的组和角色上的对象安全（身份验证）。这提供了灵活性和可移植性，因为所有授权都只能从身份验证来源间接链接到外部对象。

从 IBM Cognos BI version 8 开始，所有现成的身份验证提供程序都支持 Test 功能，您可以右键单击 IBM Cognos Configuration 的资源管理器树中的命名空间配置元素来获得该功能。这将使用配置的设置来初始化提供程序，但它可能无法用到提供程序支持的所有功能。它只会捕获明显的配置错误和连接问题。

IBM Cognos BI 开箱即用地提提供了针对以下实体的身份验证提供程序：

• 兼容 LDAP v3 的服务器
• Microsoft Active Directory
• IBM Cognos Series 7
• Microsoft NT LAN Manager (NTLM)（自 IBM Cognos BI version 10 开始已禁用）
• SAP
• CA Siteminder
• IBM System Z Resource Control Facility (RACF)
  

之前已经提到过，不是所有平台上的所有提供程序都受 IBM Cognos BI 支持。

自定义 Java 身份验证提供程序 (Custom Java Authentication Provider, CJAP)

除了开箱即用地提供的身份验证提供程序之外，IBM Cognos BI 还提供了一个软件开发工具包 (SDK) 来使用 Java 编写 自定义身份验证提供程序 (CJAP)。CJAP 实现了一个定义明确的 Java 接口，提供了读取和搜索来自身份验证来源的安全对象，基于各种凭据类型执行身份验证，可能还提供 SSO 支持功能。通过使用 SDK，可发挥出附加到几乎任何类型的身份验证来源和支持基于任何给定令牌的 SSO 的巨大潜力。

还有一种称为 Trusted Signon Provider (TSP) 的特殊类型的 CJAP。TSP 在本质上是一个轻型 CJAP，因为它仅实现一个特定的功能部分。TSP 充当着一个完整的身份验证提供程序之前的代理，用作一个受（IBM Cognos BI）信任的相关方。它不能单独存在，因为它没有附加到任何身份验证来源，不会在运行时在 IBM Cognos Administration 中显示为命名空间。它仅基于 IBM Cognos Configuration 出于连接目的而指定的配置设置，在内部定义一个命名空间对象。TSP 所做的工作就是使用一个发送到 IBM Cognos BI 的 HTTP 请求中的令牌来执行身份验证，应用必要的操作从该令牌推断用户身份，并在添加了一个可供辅助身份验证提供程序使用的额外令牌之后，将原始请求传递给这个辅助提供程序。它有效地将自定义令牌转换为受配置的服务提供程序支持的令牌。然后，辅助提供程序将处理该令牌，就像该令牌是从一个受信任方传递给它，跳过该提供程序中的初始验证步骤。它将直接前进到对传递的用户身份的确认步骤。

一个 TSP 示例是 IBM Cognos BI 以开箱即用方式提供的 Computer Associates (CA) SiteMinder 身份验证提供程序。SiteMinder TSP 所做的工作是：使用名为 SMSESSION 的专用加密 SiteMinder cookie，采用 Computer Associates 所提供的 SiteMinder API 来解密该 cookie 的内容，然后从中推断用户身份。此用户身份（从技术上讲是一个字符串）首先放入标准的 HTTP 标头 REMOTE_USER 中，然后将请求传递到辅助身份验证提供程序。当然，这个辅助提供程序必须支持基于 REMOTE_USER HTTP 标头的 SSO。一些通过 IBM Cognos BI 提供开箱即用的验证功能的身份验证提供程序都满足此要求。SiteMinder Namespace 中没有用户，这些用户只能通过为此身份验证配置的辅助身份验证提供程序来进行访问。

身份验证对话

尽管很容易想到一个发送用于身份验证的请求包含所有需要的 登录数据 （要验证的命名空间和该命名空间的有效凭据），但事实上并不是所有使用情形都是这样的。对于身份验证提供程序，发送给它的每个请求都被单独对待，但在某些情形下，身份验证流程不是一个单步操作。相反，身份验证流程可能需要多个步骤，这些步骤构成一次类似于关系数据库事务的逻辑 对话 。该对话包含在客户端、IBM Cognos 入口点、CAM_AsyncAAService 和/或处理身份验证提供程序之间交换的多个请求和响应，要么成功，要么失败。

这个对话概念允许向身份验证请求的发送方返回限定的响应。这些响应要么要求提供继续执行身份验证的后续步骤所需的额外信息，要么告知所发生的阻碍身份验证流程继续进行的错误。响应向发送请求的客户端触发的具体操作，将依赖于客户端的类型和响应类型。这些对话概念已在 自定义身份验证提供程序开发指南，第 2 章，身份验证请求：流场景 中提及的 3 个场景中介绍。

如果身份验证请求未包含立即完成身份验证所需的足够的登录数据，IBM Cognos BI 身份验证提供程序将使用一种回调机制，使身份验证提供程序能够向用户或系统请求额外的信息。身份验证提供程序返回一个所谓的 异常 ，这类似于 Java 异常，因为调用方（在此情况下是身份验证请求的发送方）负责处理该异常。调用方负责解释异常并做出反应，要么发送另一个包含更多信息，使身份验证流程能继续进行的请求，要么告示用户可能发生的错误。

IBM Cognos BI 身份验证提供程序可返回 3 种类型的异常。这些异常出现在跟踪级日志中，是 Presentation Service 为基于 HTML 的客户端呈现的面向用户的对话框的基础。在以下对异常的描述中，在日志文件中找到的实际标签和错误代码被放在括号中。

• UserRecoverable 异常 ( camAuthUserRecoverable, error -36 )
  告知发送方， 最终用户/客户端 需要提供数据，这些数据应附加到一个新请求中。返回给发送方的异常包含有关请求的数据的具体信息。对于基于 HTML 的客户端，这意味着发送方需要提供一个用户界面，提示用户缺少的信息，要求用户在添加新信息后重新发送请求。一个典型的例子是，采用 Presentation Service 呈现一个提示页面，使用一个 HTML 表单收集所需的数据。同样有效但不太容易看到的一个例子是，一个 Web 服务客户端将解析响应，呈现一个自定义身份验证页面，并在对异常的响应中提供输入的凭据。
• SystemRecoverable 异常 ( camAuthSystemRecoverable, error -37 )
  告诉 IBM Cognos 入口点 ，需要更多数据，它必须 没有 来自最终用户/客户端的进一步交互的情况下获取这些数据。这些异常用于实现 SSO。所有有效的 IBM Cognos 入口点组件都会处理这些异常，从 本地 （在 IBM Cognos 入口点上）环境中读取通用的服务器变量和受保护的标准变量，比如 REMOTE_USER（网关和 Dispatcher）和 USER_PRINCIPAL（仅限 Dispatcher）。附加到以 HTML 格式编码和签名的原始请求的额外数据（形成一个新请求），然后自动代表客户端发送回身份验证提供程序 - 实际的客户端并未参与，所以请求不会出现在任何客户端 HTTP 轨迹中。
• Unrecoverable 异常 ( camAuthUnRecoverable, error -38 )
  表示一个无法通过任何进一步操作纠正的错误。实际上，这指示了提供程序的某个内部问题，致使身份验证无法完成，这个问题是：不得针对此身份验证发送更多请求。身份验证无法处理时，发送方将通知最终用户/客户端或记录一个故障。
  

总体上讲，这个流程表明在身份验证最终成功或失败之前，一次身份验证对话可能需要在身份验证提供程序与 IBM Cognos 入口点、客户端或最终用户之间执行多轮请求和响应。这种来回通信（还涉及到 CAM_AsyncAAService 和 CAM）也被称为 身份验证之舞 (authentication dance) 。

登录数据

上一节介绍了通过一个对话来收集足够的登录数据，以处理身份验证请求的概念。本节将介绍 IBM Cognos BI 提供的所有完整的身份验证提供程序接受的登录数据的实际类型。

发送给身份验证提供程序的请求中有 4 种可能的登录数据类型

• 受信任凭据 (TC)
  这种类型的凭据由 IBM Cognos BI 身份验证提供程序在之前的一次经过验证的会话中为用户创建。在该会话中，用户要么显式要求保存他的凭据供离线使用，要么通过保存一个计划表 (schedule) 来隐式地触发身份验证程序这么做。这时，为了验证这个之前的会话而提供的凭据是加密的，并被作为针对该用户的受信任凭据对象的一部分而存储在内容库 Content Store) 中。每个用户只有一个受信任凭据对象，它可持有来自任何已定义的命名空间和 IBM Cognos BI 系统中的关联身份验证提供程序的 TC。
  例如，一个计划表将存储一个引用，这个引用被称为受信任凭据对象的凭据路径。从技术上讲，这些凭据可能是包含用户名和密码的二进制令牌或字符串。只有凭据路径在请求中传递 - TC 绝不会离开内容库。
  收到一组 TC 后，身份验证提供程序仅调用一个函数来隐式地验证它们的起源或一致性，这个函数封装了从内容库中检索实际凭据值并解密它的功能。为了实际验证这些凭据，提供程序对身份验证来源进行了身份验证。
  TC 可能过期或失效。例如，如果将密码存储在 Content Manager 中后，可能在身份验证来源中进行了更改，那么此时必须更新 TC。TC 的更新可由创建它们的用户在 IBM Cognos Connection 中显式执行，或者从 IBM Cognos BI version 10.1 开始，它们可自动更新。更新过程将更新针对用户在实际会话中登录的所有命名空间的所有 TC。
• 凭据
  凭据也被称为 SDK 凭据，由 IBM Cognos SDK 程序在向 IBM Cognos BI 执行身份验证时发送。从技术上讲，它们是字符串，很可能是用户名和可选的密码。凭据将在请求以明文形式传递，除非在 SDK 程序与 IBM Cognos BI Dispatcher 之间使用了安全套接字层 (SSL)。身份验证提供程序将通过尝试向身份验证来源进行验证，针对该来源对这些凭据进行检验。
• HTML <form> 字段 - 用户名和密码
  如果运行 基本身份验证 而不是 SSO 或基于凭据的身份验证，那么系统会提示用户输入其用户名和密码。这意味着基本身份验证仅适用于基于交互式 HTML 的客户端。用户提供其凭据后，Presentation Service 生成的 HTML 页面会在两个预定义的 HTML <form> 字段中提供它们。这些凭据可在发送给 IBM Cognos BI 入口点的请求中看到（明文）。如果入口点是一个 IBM Cognos Gateway，那么在将请求传递给 CAM_AsyncAAService 之前，应该对密码参数进行加密。如果入口点是一个 IBM Cognos Dispatcher，则不会提供密码加密功能。在敏感的环境中，推荐对 HTTP 通道使用 SSL 加密，以减轻攻击者从线路上探取密码的风险。
• SSO 令牌
  身份验证提供程序也可支持 SSO 令牌。这些令牌可能是简单的 HTTP 标头、CGI 环境变量、受保护的服务器变量或 cookie。从理论上讲，甚至 HTML <form> 元素或 HTML 请求的其他任何元素都可能是 SSO 令牌。稍后，我们会在 单点登录到 IBM Cognos BI 一节中介绍这些概念。
  

持久保存会话中的身份验证信息

在处理请求时，身份验证提供程序将使用所提供的登录数据，向附加到它的身份验证来源进行验证。如果验证成功，会话将被视为已经向 IBM Cognos BI 对所提供的用户身份进行验证，提供程序需要持久保存此状态。为此，身份验证提供程序为向其验证会话的命名空间发出一个签证 (visa)。

签证维护用户的安全上下文，也就是登录数据（为执行身份验证而传递给 IBM Cognos BI 的凭据或令牌）和用户的身份（用户所属的组和角色）。签证将用于得出用于其他请求身份验证的 IBM Cognos BI 服务的凭据，或者创建将存储在一个计划表中的受信任凭据。签证还将添加到一个由 CAM 管理的内存型表中，这个表持有所有有效的签证。

因为在一个会话中，用户可向多个命名空间进行验证，所以会话可以有多个签证，每个对应一个命名空间。会话的所有 visa 收集都在一个所谓的护照 (Passport) 中进行管理。在获取会话中的第一个签证后，将会创建此会话的护照，并为其分配一个随机生成的标识符 (PassportID)，该标识符用作护照的主键。只要会话注销或过期，就会立即销毁护照。

签证和护照仅保存在内存中，由 CAM 组件管理，绝不会发送给其他任何服务或组件。对 PassportID 的引用以及其他非敏感会话信息会经过签名和 base64 编码，然后，在一个名为 cam_passport 的 HTTP 会话 cookie 中传递给客户端。

通过使用 cam_passport cookie，会将对所有后续请求的身份验证信息保存在同一个客户端会话中。该 cookie 被发送到 CAM_AsyncAAService，供 DispatcherService 进行确认，如果成功，那么请求将被处理。其他任何结果都将触发重新验证。

通过配置，可以将 cookie 标记为安全，以便仅通过 SSL 加密连接发送它。此外，还可以配置 cookie 域和 cookie 路径。默认情况下，在没有设置显式的域或路径时，只会将 cookie 发给发出服务器和路径。自 IBM Cognos BI version 10.1.1.0 (IBM Cognos 10 Refresh Pack 1) 开始，cam_passport cookie 支持 HTTPOnly 标记，这将阻止它被脚本读取。

前面已经提到过，如果在一个可配置的时间段内没有发生护照确认来重置空闲计时器，那么会话将会超时。默认超时值为 3600 秒（60 分钟），会话过期时，护照将被删除，存储在 cam_passport cookie 中的引用将会失效。

身份验证流程

IBM Cognos BI 客户端（比如浏览器）、基于 SDK 的应用程序（比如 BI Modeller）和其他集成了 IBM Cognos BI 安全性的产品，将发送调用特定服务的请求。之前在服务、请求和会话节中已经介绍过，这些请求最终将到达一个 IBM Cognos Dispatcher Service。身份验证通常由该 Dispatcher Service 在收到任何请求时隐式触发。当它遇到一个未经验证的 IBM Cognos BI 会话时（由 cam_passport cookie 的缺失可以看出，对一个新会话的首次请求就属于这种情况），将会触发身份验证流程。会话已经过验证（由 cam_passport cookie 的存在可以看出）后，来自 cookie 的护照引用是通过调用身份验证流程来确认的。如果发现会话过期，则会再次触发完整的身份验证。只有与一个会话关联的护照仍然有效时，Dispatcher Service 才会继续处理请求，并最终将它分配给请求的服务的一个实例。

但是，在某些情况下，身份验证功能会由一个 IBM Cognos 服务显式调用。

• 访问配置来向一个外部命名空间（Cognos Namespace 以外的命名空间）执行身份验证的数据来源，或者访问配置为使用单点登录的数据来源，但由于授权或缺乏定义的原因而没有可用的单点登录机制。在这些情况下，身份验证将由执行报告的服务显式调用，但在大多数情况下，用户都不会注意到这一点，除非要求提示用户输入凭据。只要护照中还没有针对外部命名空间的签证，或者以前向外部命名空间的身份验证由 SSO 执行，但该 SSO 可能不需要适合数据库验证的凭据，只需要使用一些 SSO 令牌，就会出现这种情况。
• 通过 Cognos Connection 将计划表保存在一个已由 SSO 执行身份验证的会话中，就会得到一个非凭据的 SSO 令牌。SSO 令牌通常不包含密码，但根据身份验证提供程序，这可能使凭据不能被存储为受信任的凭据。在执行身份验证时，通过 Presentation Service 调用来收集一个凭据（通常为用户名和密码），该凭据通常足以存储为受信任的凭据。
• 用户可以单击 IBM Cognos Connection 中的 Log On 链接来启动对另一个命名空间的身份验证。
• IBM Cognos SDK 客户端或另一个 IBM Cognos BI 服务调用 Logon/LogonAs 方法。例如，计划功能将让一个称为 Monitor Service 的服务触发身份验证来建立一个会话，以便在后台代表特定用户执行某种操作。
  

无论对请求的验证被隐式调用还是显式调用，Dispatcher Service 实例都会将当前请求的一个副本推入一个堆栈，并在 CAM_AsyncAAService 接管操作时将请求转发给该 CAM 组件。身份验证流程完成后，正常情况下会从堆栈检索原始请求并处理请求。在 CAM 组件收到一个身份验证请求时，它首先会分析 SOAP 请求的 <bus:CAM> 部分中的 <action> 元素所指示的请求操作。此操作可能是 logon、logonAs 或 validate之一。

validate 操作

与其他两个操作相比，validate 操作是一个轻型操作。简单来讲它就是对由一个给定护照引用所标识的现有护照进行确认。如果引用的护照仍然有效，CAM 将向调用方发出一个正面响应，然后，后者会继续执行处理。如果应用的护照过期或者不存在，则会返回一个负面结果，请求的发送方必须对这个结果进行处理，通常是调用身份验证流程。

logon 操作

此操作将调用整个登录流程，以便首先分析身份验证的一般配置。它是一个一般性操作，不需要满足任何前提条件，调用此操作也不需要任何具体信息。此方法用于支持 匿名身份验证 。

如果系统被配置为允许匿名访问，那么会话将变为使用预定义的匿名用户执行验证，因为 IBM Cognos BI 中没有真正的匿名会话。可以使用一个内部身份验证提供程序实现此功能，该功能既不可见，又不能配置。使用一些硬编码的虚拟用户凭据意味着不需要使用显式凭据。

匿名身份验证具有优先权，也就是说，即使至少有一个配置了指定身份验证的命名空间，也将针对登录操作对匿名用户进行身份验证。与此同时，如果在会话已被验证为匿名的后调用 logon 操作，身份验证流程将继续进行，就像在禁用了匿名访问时将对 logon 操作的处理一样。

如果禁用了匿名访问，身份验证流程会继续执行 logonAs 操作步骤，就像直接调用该操作一样。

logonAs 操作

一个发送给 CAM 的的将调用 logonAs 操作的请求，并会跳过 logon 操作所提供的前兆信息。这会排除匿名身份验证，而且需要专门对一个有效的命名空间执行身份验证。

CAM 的第一步是确定有多少有效的身份验证提供程序可用，从而确定有多少命名空间可用于身份验证。在 CAM 组件启动时，它会调用每个身份验证提供程序来初始化和创建一个活动实例。从 IBM Cognos 10 开始，这些实例在其自己的称为 CAMLPSrv的物理进程中运行。对于身份验证提供程序的每个实例，将有一个 CAMLPSrv 进程。例如，在配置了三个命名空间但一个未能初始化的系统中，将有两个有效的身份验证提供程序实例和两个 CAMLPSrv 进程。

如果有多个有效的命名空间，但它们都未指定为用于身份验证，那么 CAM 将会抛出一个 UserRecoverable 异常来启动一次身份验证对话，它会请求客户端对该异常做出反应。预期的响应是重新发送原始响应，添加一个指示器来表明该命名空间用于身份验证。这通过指定要向其执行验证的命名空间的 NamespaceID（从命名空间配置中）来完成，进而隐式地确定要使用的身份验证提供程序。NamespaceID 可以在 SOAP 请求的 <bus:CAM> 结构的一个元素中指定，或者被用作一个名为 CAMNamespace 的 HTML <form> 参数。对于重新发送的请求，CAM 操作必须切换为 logonAs，因为现在有一个指示器表明要将哪个命名空间用于身份验证。对于 HTML 客户端，比如浏览器，这通过嵌入在 Presentation Service 所生成的提示页面中的脚本代码来完成。对于其他任何类型的客户端，这必须编程方式来处理（通过在下一个请求的 SOAP 标头中设置相应的操作）。执行这一步是为了确保排除匿名身份验证流程。有关如何为不同的客户端处理命名空间选择的详细信息，请参阅 场景 一节。

如果只有一个可用的命名空间或已通过指定 NamespaceID 来显式选择了一个命名空间，那么请求会被传递到相应的身份验证提供程序。然后，提供程序会根据它的需求来处理身份验证请求。

下面介绍了通用的身份验证流。它适用于 IBM Cognos BI 提供的所有现成的身份验证提供程序（ Cognos 提供程序 ），但 CA SiteMinder 提供程序和 SharedSecret 提供程序除外，二者都是 TSP。之前在 自定义 Java 身份验证提供程序 (CJAP) 一节中已经提到，TSP 不会实现身份验证模式，而是仅代管请求。

身份验证提供程序首先将会检查请求中是否有足够的登录数据来完成身份验证。根据提供程序所支持的登录数据类型，这将包括用于计划的受信任凭据或 SDK 客户端所发送的凭据。哪些类型的登录数据具有优先权取决于提供程序，但所有 Cognos 提供程序都会按以下顺序检查登录数据类型：

• 受信任的凭据
• SDK 凭据
• SSO 令牌
• HTML <form> 变量
  

在实现一个完整的身份验证提供程序的 CJAP 中，可能不支持某些类型的登录数据。因为 SDK API 不会强制编程人员支持所有类型的登录数据，所以需要与 CJAP 的作者进行核对。

在请求中包含受信任的凭据或 SDK 凭据时，尽管可能已经配置了 SSO，但 Cognos 提供程序可能不会认可 SSO。只有在每种凭据类型都不可用时，Cognos 提供程序才会检查其配置，以便查看是否已启用 SSO。

如果 SSO 已启用，提供程序将会返回一个 SystemRecoverable 异常，用它来启动 “身份验证之舞”，以便获取 SSO 令牌的受信任的值。需要多少次往返通信（SystemRecoverable 响应），才能提供足够的信息来尝试使用 SSO，这完全取决于提供程序。例如，LDAP 提供程序将仅使用一个 SystemRecoverable 异常来检索一个服务器变量，但 Microsoft Active Directory 提供程序将经历多次往返通信来交换 Kerberos 令牌。

在提供程序收到足够的数据后，它会继续尝试 SSO。SSO 的详细信息将在本文后面的 单点登录到 IBM Cognos BI 一节中介绍。如果 SSO 成功，身份验证对话将会结束，并在一个响应中向客户端返回 cam_passport cookie 和成功状态。

如果未配置 SSO，Cognos 提供程序将会分析请求中是否存在 HTML <form> 变量，如果存在，则会尝试根据这些变量来执行验证。

如果基于可用登录数据的身份验证成功，那么提供程序将会发出一个签证，并将其传递给 CAM，后者将创建或更新会话的护照。对于 Presentation Service 转发请求的 HTML 客户端，CAM 还将发出或更新 cam_passport cookie。对于其他客户端，会在 SOAP 响应中返回护照引用。

如果没有任何登录数据可用，提供程序将使用一个 UserRecoverable 异常作为响应，表明登录数据缺失或无效。请求的发送方将会负责处理此异常，并被要求在附加了一种支持类型的登录数据后重新发送请求。

其他错误，比如与身份验证来源的连接问题和身份验证来源返回的错误，将在一个 Unrecoverable 异常中报告给请求的发送方。请求的发送方负责处理此异常。

场景

场景 1- 浏览器客户端在一个新浏览器会话中，通过访问一个部署到某个 Web 服务器的 IBM Cognos CGI 网关来访问 IBM Cognos Connection 默认页面。配置了多个命名空间，禁止匿名访问，而且未设置 SSO。

• 访问 IBM Cognos Connection 意味着调用 Presentation Service，后者负责呈现基于 HTML 的 GUI。Dispatcher Service 会注意到该会话尚未经过验证，它会向一个堆栈推送一个请求副本。
• 接下来，Dispatcher Service 向请求附加一个 CAM 操作 logon ，并将请求发送到 CAM_AsyncAAService。CAM 发现未允许匿名访问，而且没有为身份验证选择任何命名空间。因此，它将抛出一个 UserRecoverable 异常。异常响应中包含一个<promptInfo> 元素，其中包含一个类似 “Please select a Namespace for authentication” 这样的标题，以及在这种情况下可供选择的所有可能值，所有命名空间名称，以及所有初始化的命名空间的 NamespaceID。
• Dispatcher Service 是请求的发送方，所以它需要处理 UserRecoverable 异常。它直到客户端是一个浏览器（基于最初调用了 Presentation Service 的事实），将采用 Presentation Service 的一个本地实例，根据 <promptInfo> 元素中收到的数据来呈现 HTML 提示页面。如果没有 Presentation Service 的本地实例可供使用，那么该异常将无法处理，并以原始 XML 格式传递给客户端。浏览器客户端通常会显示该 XML，该内容此刻表示存在一个配置错误，因为作为入口点， Dispatchers 必须运行一个 Presentation Service 实例。
• 用户按生成的提示页上的名称选择一个命名空间，然后一个隐藏的 HTML 表单（使用 HTTP POST）提交另一个请求，这个请求已添加了两个参数。第一个参数CAMNamespace 包含所选的命名空间的 NamespaceID，第二个参数h_CAM_action 被设置为 logonAs 。
• 这一次，请求将分配给 CAM 所选的命名空间背后的实际的身份验证提供程序。该提供程序将分析请求，但未能找到任何支持的登录数据。因为未设置 SSO，所以惟一的选择是返回另一个 UserRecoverable 异常，要求提供任何登录数据。因为请求中没有受信任的凭据和 SDK 凭据，而且 SSO 已禁用，所以 Cognos 提供程序将要求在下一次尝试中提供包含用户名和密码的 <form> 变量。因此，作为该异常响应的一部分，返回了一个包含建议的 HTML 表单和标签的 <promptInfo> 元素。
• Dispatcher Service 将再次处理此异常，而且因为它知道请求通过 Presentation Service 传输，所以将采用 Presentation Service 的本地实例呈现另一个 HTML 提示页面，使用来自该异常的 <promptInfo> 元素的信息创建了一个 HTML 表单。在提示页面上，用户可键入其用户名和密码。用户提交表单时，用户名和密码分别被映射到 CAMUserName 和 CAMPassword 参数，更新的请求由 HTTP POST 通过 Dispatcher Service 发送给 CAM_AsyncAAService，后者将该请求传递给以前选择的身份验证提供程序。
• 这一次，提供程序找到了包含凭据的 FORM 变量，因此有足够的登录数据来尝试向外部验证来源执行实际的身份验证。
• 如果身份验证成功，Dispatcher Service 从堆栈中检索原始请求并添加更新的会话信息（在包含提供程序发布的新签证），然后继续执行处理。此场景意味着基于 Dispatcher 路由概念，将请求转发到 Presentation Service 的一个实例（该实例为客户端呈现 HTML 响应）。如果身份验证因为凭据无效而失败，那么提供程序将返回另一个 UserRecoverable 异常，并要求提供有效的凭据，重复上面的用户被提示输入用户名和密码的位置往后的步骤。
• 如果发生了意料之外的事件，比如与提供程序的连接失败，则会返回一个 Unrecoverable 异常，这将导致 Dispatcher Service 要求 Presentation Service 呈现一个错误页面，进而结束身份验证流程。
  

这是最典型的场景之一。它演示了对话概念，表明一次身份验证可包含一到多个异常，这些异常尽管包含错误代码，但是成功的身份验证的实际部分。这在排除身份验证问题时非常重要。

场景 2- 浏览器客户端在一个新浏览器会话中连接到已部署在 IBM Web Server (IHS) 上的 IBM Cognos CGI Gateway，以便访问 IBM Cognos Connection。一个命名空间配置了 SSO。匿名访问被禁用。

• 访问 IBM Cognos Connection 意味着调用 Presentation Service，后者负责呈现基于 HTML 的 GUI。Dispatcher Service 将注意到该会话尚未经过验证，它会向一个堆栈推送一个请求副本。
• 接下来，Dispatcher Service 附加了一个 CAM 操作 logon ，并将请求发送给 CAM_AsyncAAService。CAM 发现未允许匿名访问，而且没有为身份验证选择任何命名空间。但是，因为只有一个活动的命名空间，所以请求传递给了惟一的已经初始化的提供程序。
• 该提供程序配置了 SSO，因此它将识别所需的 SSO 令牌。根据令牌的类型（稍后将在单点登录到 IBM Cognos BI一节中介绍），提供程序将继续直接执行下一步，或者像我们将在这个示例中假设的一样，返回一个 SystemRecoverable 异常，要求 IBM Cognos 入口点提供一个令牌值。返回该异常的原因是，即使 SSO 令牌已包含在请求中，但提供程序出于安全原因不会 “按原样” 获取该令牌。为了减轻嗅探风险，提供程序将仅接受信任方发送的 SSO 令牌，比如其他 Cognos 系统组件。
• Dispatcher Service 注意到了这个 SystemRecoverable 类型的异常。基于目前的信息，该 Dispatcher 知道它不是入口点，请求是从一个网关转发给它的。因此它不应处理该 SystemRecoverable 异常，只有入口点应处理。但是，如果浏览器客户端已经直接访问该 Dispatcher，那么它将成为入口点，因此将会处理该异常。但是，在本场景中，它向响应分配一个 HTTP 响应代码 599，并将它传递回入口点，在本例中，该入口点是部署到 IHS 的 IBM Cognos CGI Gateway。该网关将会捕获该异常，从它的本地环境推断请求的令牌并发送另一个请求。此过程自动完成，无需客户端干预。因此，客户端看不到第二个请求，它不会出现在客户端与 Web 服务器之间的通信的 HTTP 级轨迹中。发送的请求是原始请求的一个副本，其中在一个特殊编码的、经过数字签名的 HTML 表单参数 CAM_SecurityBlob 中附加了检索的令牌值。
• 通过 Dispatcher Service 传递的第二个请求到达 CAM_AsyncAAService，并被再次传递到身份验证提供程序。该提供程序解包 CAM_SecurityBlob FORM 变量，根据检索的值来尝试 SSO。
• 如果身份验证成功，那么 Dispatcher Service 会从堆栈中检索原始请求，并添加更新的会话信息（在包含提供程序发布的新签证），然后继续执行处理。在此场景中，这意味着会基于 Dispatcher 路由概念，将请求转发到 Presentation Service 的一个实例（该实例为客户端呈现 HTML 响应）。
• 如果身份验证由于无效的凭据而失败，那么提供程序将会返回一个 UserRecoverable 异常，要求提供有效的凭据。此刻，因为 SSO 已失败，所以会返回从 FORM 变量获取的登录数据，该异常仅要求提供用户名和密码。因为 Dispatcher Service 知道客户端是一个浏览器，原因在于最初调用了 Presentation Service，所以 Dispatcher Service 将采用 Presentation Service 的本地实例来呈现一个登录页面，身份验证会切换到一种类似于场景 1 中所描述的交互式身份验证。
• 如果发生了意料之外的事件，比如与提供程序的连接失败，则会返回一个 Unrecoverable 异常，这将导致 Dispatcher Service 要求 Presentation Service 呈现一个错误页面，从而结束身份验证流程。
  

对于第二个场景，要注意的主要一点是 SystemRecoverable 异常仅在入口点处理，不会返回到客户端。只需跟踪 IBM Cognos BI 中的身份验证进展，或者捕获 Web 服务器与 IBM Cognos BI 应用程序层之间的 HTTP 流量，这些请求就会变得可见。

非浏览器/基于 SDK 的客户端

刚才提供的两种场景都仅涉及到浏览器客户端，因为它们提供了用户交互能力。胖客户端应用程序（比如 IBM Cognos BI Modeler）会采用 IBM Cognos BI SDK 的一个内部版本，该版本需要显式地编写交互式的、用户驱动的身份验证。因此，这些基于 SDK 的客户端通常会使用一种两步方法来实现向 IBM Cognos BI 后端的身份验证。首先，它们采用一个嵌入式 Internet Explorer 浏览器控件来运行身份验证。这提供了可供浏览器客户端使用的功能，比如自定义的登录页面和第三方身份验证代理支持，但在会话经过身份验证后，胖客户端也被允许检索 cam_passport cookie 的值。然后，客户端与 IBM Cognos BI Dispatcher URI 之间的后续通信是通过 SDK 功能来完成的，这在技术上体现在将 cam_passport cookie 值嵌入在 SOAP 请求，来回发送 SOAP 消息，并被用作身份验证方式。

其他 IBM Cognos 产品（比如 IBM Cognos TM1 和 IBM Cognos Planning）还允许向 IBM Cognos BI 中集成安全性。因此它们充当着客户端。从技术上讲，这些产品采用了一些软件组件来首先建立一个经过验证的会话，这些组件模拟或在行为上类似一个浏览器客户端。为此，它们调用了特殊的 Presentation Service 模板，比如 bridge.xts ，该模板允许将 cam_passport cookie 传递到外部应用程序（请参阅 IBM Cognos 软件开发工具包开发人员指南 ，了解有关的详细信息）。因为它们调用了 Presentation Service，所以标准 IBM Cognos BI 身份验证的大多数（如果不是所有）功能（自定义的登录页面、SSO 和对反向（身份验证）代理的支持）也可用于它们。从建立的会话检索 cam_passport cookie 后，对 IBM Cognos BI 的后续访问同样基于 SDK，这意味着 SOAP 请求被直接发送到 IBM Cognos BI Dispatcher URI。

纯 SDK 客户端（它们不会利用模拟 HTML 客户端的方法）必须依赖于直接处理 SOAP 消息。这些客户端可以调用 API 公开的函数来运行身份验证，护照将被放入 SOAP 请求和响应中，以便在网络上进行传输。由于这方面安全担忧不断增加，所以建议至少通过 SSL 来保护通信。

回页首

单点登录到 IBM Cognos BI概念

获取对 IBM Cognos BI 的访问而不显式登录，这通常被称为 单点登录 (SSO) 到 IBM Cognos BI 。SSO 的一种更加一般性的定义是：它被描述为 基于单次登录而获取对多个独立但相关系统的访问的过程 。对于 IBM Cognos BI，这意味着用户在一个 HTTP 会话中访问 IBM Cognos BI 之前，必须已经验证了一个分配给该会话的身份。此身份验证必须通过将凭据提供给一个 Cognos 外部的安全系统来完成。这个安全系统可提供适合实现对其他系统的 SSO 的身份和/或某种凭据信息，通常以 SSO 令牌 的形式提供。符合此条件的典型安全系统就是身份验证代理，比如 IBM Tivoli WebSEAL、Oracle Oblix、Computer Associates SiteMinder，或者其他任何可验证一个 HTTP 会话并将该会话持久保存在一个令牌中的软件或硬件解决方案。

基于此，IBM Cognos BI 中的 SSO 支持的主要概念是， IBM Cognos BI 使用发送给它的单个请求中的 SSO 令牌 。令牌如何进入请求中并不重要，IBM Cognos BI 产品不关心这一点。请求到达 IBM Cognos BI 入口点之前发生的操作，一次多系统 SSO 之前经历了多少个跃点，以及涉及到多少个安全系统，这些都无关紧要。只有在请求到达 IBM Cognos BI 入口点时，SSO 令牌的处理才会开始。这在第三方安全系统与 IBM Cognos BI 之间定义了一个明显的边界，在需要多个软件供应商提供帮助时，这一边界特别重要。

此设置仅考虑单个请求，允许采用 HTTP 30x 返回代码或脚本的第三方产品将客户重定向到一个不同的 URL，运行某种登录逻辑，并返回到最初请求的资源 URL。对于 IBM Cognos BI，这种前期对话必须（且通常）是透明的，因为请求由 IBM Cognos BI 独立地处理。事实上，许多描述为 单点登录到 Cognos 的 无缝身份验证 场景有多个跃点组成，每个跃点涉及到某种形式的身份验证或受信任的登录。

一个典型的场景是，用户登录到其机器，在该机器上由操作系统 (OS) 安全机制执行验证。接下来，用户打开一个浏览器并访问一个 Web 服务器上的受保护资源。对该资源的访问由 Web 服务器安全机制来控制。理想情况下，这是从操作系统到 Web 服务器安全层的某种 SSO。如果不是，用户将被提示向 Web 服务器的安全层进行身份验证。如果这个受保护的资源恰好是一个 IBM Cognos BI Gateway，那么另一个 SSO 跃点将为从 Web 服务器安全层到 IBM Cognos BI。在此场景中，整个 SSO 过程有两个跃点 - 从操作系统到 Web 服务器，然后从 Web 服务器到 IBM Cognos BI。这会假设向 IBM Cognos BI 的 SSO 基于 Web 服务器安全层提供的一些信息，但如果有一个令牌可用，那么它实际上可能基于操作系统的安全性。

为了成功地实现向 IBM Cognos BI 的 SSO，重要的是 SSO 令牌和来自该 SSO 令牌的信息（具体地讲，凭据和身份）可供任何 IBM Cognos BI 身份验证提供程序使用。前面已经提到过，IBM Cognos BI 支持两种类型的身份验证提供程序：完整提供程序和受信任安全性提供程序 (TSP)，前者附加到某个身份验证来源并对会话执行验证，后者被用作一个代理，但无法自行对会话执行验证。从这里可以看到，对于 SSO，完整提供程序对特定身份验证模式和令牌类型的支持，决定了可用的配置选项。

IBM Cognos BI 现成的完整提供程序仅支持两种 SSO 身份验证模式。

• 基于凭据的身份验证 ：提供程序接收 SSO 令牌格式的凭据，该凭据原封不动地提供给它配置的后端系统。这被称为 直通 模式。事实上，需要假设提供程序的后端身份验证来源要么是发出 SSO 令牌的同一个安全系统，要么至少是一个可使用正在使用的 SSO 令牌的系统。示例包括用于 Active Directory 提供程序的 Kerberos 令牌，用于 SAP 提供程序的 SAP cookie，以及用于 SiteMinder 提供程序的 CA SiteMinder cookie。
• 基于身份信息的受信任的单点登录（身份映射） ：在此上下文中，受信任的单点登录意味着提供程序将单独基于所提供的身份对会话进行验证，而不需要使用显式的凭据。如果身份由一个受信任的来源提供和担保，那么身份验证提供程序将会信任该身份。Cognos 提供程序惟一受信任的来源是 IBM Cognos BI Gateway 和 Dispatcher 入口点。对于受信任的单点登录，不会发生向任何安全系统的重新验证，而只会以在配置的后端身份验证来源中执行查找的形式来对身份进行简单确认。如果查找成功，这足以完成身份验证。此模式不太安全，因为它具有忘记身份信息或非故意地授予访问权的风险，因为同一个身份存在于两个系统中。例如，用户 “Bob” 由 Windows 进行验证，该身份也被提供给附加到 Tivoli LDAP 的 IBM Cognos BI LDAP 提供程序。如果身份 “Bob” 存在于 Tivoli LDAP 中，IBM Cognos BI 会对它进行验证。此刻无法保证这些身份是否指向同一个实际用户，因为在此示例中，两个安全系统（Windows 和 Tivoli LDAP）不一定是相关的。即使无法通过身份映射来保证分配的身份，但从另一方面讲，在这些身份显然是分配给同一个用户的时候，它允许更灵活地集成技术上无关联的系统（在本例中为独立的 LDAP 和 Windows 域）。LDAP 提供程序通过其外部身份映射特性来支持身份映射，Active Directory 提供程序在配置了身份映射 SSO 模式时也支持身份映射。
  

SSO 身份验证模式中使用的信息在 SSO 令牌中传递。从技术上讲，可为这两种模式使用 3 种类型的令牌。

• Cookie – Cookie 是在 HTTP 请求中名为 “ Cookies: ” 的标准 HTTP 标头中发送的字符串。cookie 的主要用途是承载凭据，但从理论上讲，它们也可以持有身份。
• HTTP 标头 ：任何 HTTP 标头都是一个在 HTTP 请求中发送的明显的文本字符串。HTTP 协议定义了标准标头，但客户端或服务器也可添加自己定义的标头。
• 服务器变量 ：服务器变量是一个字符串变量，它仅存在于 Web 服务器或 Java 应用服务器的本地环境中，不会作为 HTTP 请求的一部分传输。一个仅适用于 Web 服务器的特殊的服务器变量子集是，提供给 CGI Web 服务器扩展的一组变量。这个集合具有不同的 Web 服务器，但它的变量通常被称为 CGI 环境变量 。只能通过在实际的 Web 服务器上下文中执行的代码来访问这些变量。这是 CGI 或其他服务器扩展模块的操作方式。然后，该代码可以使用专用技术自行提交检索的值。服务器变量通常用于提供身份。
  

上面的示例可能表明，取决于 Cognos 提供程序支持的令牌和身份验证模式，SSO 支持可能仅限于少数选项。尽管 Cognos 提供程序仅支持一组定义的令牌和模式，但 IBM Cognos BI SDK 提供了一个应用编程接口 (API)，支持创建一个自定义身份验证提供程序 (CJAP) 来为现有提供程序提供补充，并将支持扩展到几乎所有类型的 SSO 令牌。

只在要求支持一个特定的身份验证来源时，才有必要创建一个完整提供程序 CJAP。这个任务很复杂，涉及到多个主题、多项工作和技能的大量知识（后端身份验证来源的工作原理、HTTP 协议和高级 Java 编程，等等）。但对于 SSO（这里的重点），人们通常只希望填补某个安全系统所提供的令牌与 IBM Cognos BI 身份验证提供程序所已支持的身份验证来源之间的空白。这可以通过创建一个受信任的登录提供程序 (TSP) 来实现，这个任务远没有创建完整提供程序那么复杂，通常只需使用创建完整提供程序 CJAP 的小部分时间即可完成。

尽管只有完整 IBM Cognos BI 身份验证提供程序可以验证一个针对 IBM Cognos BI 的会话，但 TSP 可以使用所有 3 种类型的 SSO 令牌。TSP 在设计上充当着一个代理 - 它接收和处理请求，并将请求传递给一个完整的身份验证提供程序。处理可能包括使用上面介绍的任何令牌类型，还由可能添加任何类型的令牌。IBM Cognos BI SDK 中针对身份验证提供程序的 API 定义了所需的方法。例如，TSP 可使用一个令牌并生成另一个不同的令牌，无论需要的类型和身份验证模式是什么。它还可以提供更详细的信息，例如，提示用户提供了更多信息来实现双因素身份验证，其中用户需要提供他们 知道 的某些信息（比如密码或 pin 码），以及他们 拥有 的信息（比如密钥卡）。这正是 TSP 非常强大、成为启用 SSO 的例行方式的原因。

从上面可以看到，IBM Cognos BI 支持几乎所有 SSO 集成，但根据使用的令牌，一些集成可能需要自定义编程。

一定要注意的是，目前不支持在 SSO 期间传递 身份验证 信息。授权完全是 IBM Cognos BI 中的专用功能，如果不使用 IBM Cognos BI SDK 来以编程方式管理身份验证，则不能与其他解决方案集成。从理论上讲，可以包含所需的 SDK 调用，在处理身份验证的过程中管理授权，但这只能在 CJAP 中完成，因为 Cognos 提供程序不支持扩展。CJAP 通常需要特定于某个安装版本，不受 IBM Cognos BI 支持的自定义编码。混合使用身份验证和授权，不是一种最佳实践。对在用户经过验证后自动向其授予权限等需求的处理，应该在一个 身份验证监听器 中执行。身份验证监听器接口允许注册自定义功能，这些功能基于事件（比如成功验证或会话过期）而触发。请参阅 IBM Cognos 自定义身份验证提供程序开发人员指南 ，了解身份验证监听器的详细信息。

自 IBM Cognos BI version 10.1 开始通过一种设置来支持 单一注销 ，该设置允许在客户端显式注销时将它重定向到一个指定的 URL。但重定向并不适用于会话过期。有关配置的详细信息，请参阅 IBM Cognos 管理和安全指南 中名为 自定义 IBM Cognos Connection 登录页面 的一节。

有关随产品提供的 Cognos 提供程序和它们的配置的更多细节，请参阅 IBM Cognos 安装和配置指南 中名为 配置 IBM Cognos 组件来使用身份验证提供程序 一节。

技术实现

一个完整的 IBM Cognos BI 身份验证提供程序通常涉及到以下高级 SSO 步骤，

• 使用 ：隐式或显式地检验令牌内容。通过解码令牌来隐式检验它们/通过提供程序本身内的代码或采用第三方 API 来解密它们。如果令牌被正确解密，则会启动身份验证流程。显式检验可通过解析令牌的内容或检验签名来执行。无论如何，执行这一步后都会从令牌获取一些凭据。
• 确认 ：将凭据提供给配置的身份验证来源进行确认，从而获得一个身份，或者通过配置的身份验证来源确认从令牌推断的身份。
• 身份验证 ：如果前一步成功完成，则使用 IBM Cognos BI 对会话进行验证。
  

对于 TSP，总体步骤稍有不同，

• 使用 ：像上面的完成身份验证提供程序一样，隐式或显式地检验令牌内容。
• 转换 ：从令牌中推断凭据/身份信息，可能还对它应用转换。根据设计，TSP 会将身份验证请求传递给一个辅助的完整身份验证提供程序。因此，TSP 可能需要一个新令牌，而且令牌的类型受辅助完整提供程序直接支持。
• 传递 ：填充要传递的令牌并将身份验证流程转交给辅助完整身份验证提供程序。
  

IBM Cognos BI for SAP、IBM Cognos Series 7、LDAP, Microsoft Active Directory、Microsoft NTLM 和 RACF 所提供的完整身份验证提供程序支持所描述的 rundown，将在本文后面详细讨论。CA SiteMinder 提供程序（一个 TSP）我们也会详细讨论。

两种提供程序类型拥有使用令牌的相同步骤。之前我们介绍了 3 种令牌类型：Cookie、HTTP 标头和服务器变量。尽管不同提供程序对特定令牌类型的支持不同，而且使用所支持的令牌类型的具体步骤也不同，但所有 SSO 令牌的一个共同且重要的方面是信任度。SSO 的目的是获取现有信息并在后续身份验证过程中信任它，因此有必要理解一个特定令牌类型的信任度。如果一种令牌类型很容易伪造或修改，那么 SSO 解决方案的安全级别就会降低。

IBM Cognos 采用了一些独创的技术来确保传递给它的令牌的信任度。在进一步探讨这些技术之前，首先需要介绍一些有关支持的令牌类型的技术细节。

SSO 令牌类型深入探讨Cookie

Cookie 是最便捷的令牌，因为它们的处理基于标准化的方法和实践。像 HTTP 请求中的所有内容一样，根据 HTTP 协议的设置，它们以明文形式传输，但该标准中包含许多处理 cookie 的安全特性。可配置的过期时间、在客户端限制向服务器发送 cookie 的控制功能，或者执行 SSL 加密的 HTTP 通道等等，这些仅仅是安全特性的部分示例。几乎所有 HTTP 客户端和服务器产品都在采用这些标准，以保护 cookie 免遭篡改、注入、劫持和伪造。因为 cookie 是通过 HTTP 进行传输的，浏览器客户端将它们存储在本地文件系统中，所以 cookie 通常经过了加密和编码，以便进一步加强它们的安全。在最新的加密模式中，使用了一种称为签名的特性来确保传输的内容的完整性，该特性允许接收者确定 cookie 的内容在从服务器传输的过程中是否经过了修改。所有这些使 cookie 成为了用于 SSO 的最值得信赖的令牌类型，而且许多商用解决方案支持将它们用于该用途。

IBM Cognos BI 身份验证提供程序直接从请求读取 cookie，而且对于 TSP，甚至能够将 cookie 添加到请求中。一些 Cognos 提供程序支持 cookie，利用第三方 API 来解密其内容并从中推断需要的信息。

HTTP 标头

HTTP 标头是一个字符串，它包含在 HTTP 请求的标头部分中。HTTP 标准中有多个预定义的标头，请求的发送者可定义和添加自己的任意标头。HTTP 标头可由客户端或服务器添加到 HTTP 请求中。通常，客户端将一组标头发送到服务器来控制请求处理的各个方面，或者提供有关想要的服务器响应的语法、格式或编码的信息。客户端发送给服务器的 HTTP 标头被称为 请求标头 ，而服务器发送到客户端的 HTTP 标头被称为 响应标头 。

HTTP 标头可包含身份信息或凭据。它们可由服务器和客户端访问，也可以由路由器、代理和防火墙等处理传输中的 HTTP 请求的各方进行访问。因此，HTTP 标头被视为信任度最低的令牌类型，因为它很容易从技术上伪造、注入或篡改。无法区分伪造的值与原始值。标头通常没有签名和加密，尽管这在技术上是可行的。因为它们相对容易篡改，所以 HTTP 标头通常是实现 SSO 的最后办法，SSO 通常是通过身份映射来实现的。

服务器变量

服务器变量有时被称为 CGI 环境变量 ，是 HTTP 服务器上惟一存在的变量。尽管这通常指的是 Web 服务器，但并不完全如此。Java 应用服务器包含一个 HTTP 服务器组件，因为 Java Platform Enterprise Edition (J2EE) 中使用的 SOAP 协议通常使用 HTTP 作为传输协议。

每个 Web 服务器或 Java 应用服务器都支持一组不同的服务器变量，这些变量可分为 3 个主要类别。

• 简单变量仅由服务器设置。此类型的服务器变量的一个例子是 AUTH_TYPE，它指示服务器支持哪种身份验证方法。
• 受保护的标准变量，这些变量仅在成功向服务器执行验证后由服务器填充。标准变量包括 REMOTE_USER 和 USER_PRINCIPAL。
• 所谓的 “元变量”，它们是根据请求标头来填充的。客户端可以在请求中向服务器发送 HTTP 请求标头。在服务器的上下文中，这些请求标头将自动反映为特殊的服务器变量（元变量）。这可以通过以下方式完成：将每个请求标头转换为大写，将弧线的所有 “-”（删除线）替换为 “_”（下划线），并在标头名称前面添加字符串 “HTTP_”。例如，如果客户端在请求中将 HTTP 标头 “My-User” 发送给服务器，服务器将自动创建一个元变量 “HTTP_MY_USER”。这个元变量仅存在于服务器上，而且您可能已经想到，它的值将是请求标头的值 “My-User”。实际上，这意味着服务器代码可通过两种方式获得请求标头，一种是作为直接从请求抓取的原始 HTTP 标头，另一种是作为来自服务器变量的元变量。
  

根据具体的服务器，一些或所有这些变量构成了服务器上下文中为程序和可执行文件提供的一种环境。Web 服务器通常将所有上述类别的变量提供给它的扩展，而 Java 应用服务器仅知道受保护的标准变量和元变量。由于与 Web 服务器的架构差异，没有用于 Java 应用服务器的简单变量。

前面已经提到过，服务器变量仅可通过在服务器上下文中执行的代码来访问。它们不会在 HTTP 请求中自动发送。能够访问服务器变量的代码，必须实现其自己的方式来将检索的信息传递给其他组件，无论是本地还是远程组件。我们很快将再次介绍此主题，但首先需要理解为部署到 Web 服务器的代码提供了何种环境。

Web 服务器通常提供两种接口来编写可执行程序，这些程序可部署到服务器来扩展服务器的功能。这些可执行程序称为 服务器扩展 。第一个接口是称为 通用网关接口 (Common Gateway Interface, CGI) 的标准，实现此接口的可执行程序被称为 CGI 。CGI 可以在许多不同的编程语言中实现，受几乎每个 Web 服务器支持。CGI 标准由多个 RFC 定义，这使得这些该标准功能丰富但不是很高效。大多数 Web 服务器提供的第二个接口特定于该 Web 服务器的实现。Microsoft 的 Internet Information Server (IIS) 提供了 Internet 服务器应用编程接口 (Internet Server Application Programming Interface, ISAPI) ，并且 Apache Web 服务器支持一个称为 MOD 的接口。这些接口克服了 CGI 接口在性能和与实际的 Web 服务器设计的集成方面的限制。

实现通用网关接口的可执行程序，基于 CGI 标准而隐式地定义了可用于 CGI 的变量集。这个变量集有时被称为 CGI 环境 。CGI 标准中还有一个定义的 API 调用，用于从 CGI 环境读取变量，该调用名为 GetEnv() 。它向调用方提供请求的服务器变量的值。使用这种标准化的方法，CGI 程序可读取每个简单服务器变量、受保护的服务器变量，甚至是元变量，这些事实上是收到的请求中的 HTTP 标头的表示形式。

与 CGI 环境和为 CGI 程序提供的对该环境的访问权相比，特定于 Web 服务器的接口所提供的环境仅依赖于 Web 服务器的供应商。通常，标准 CGI 环境变量有一组专用变量作为补充，后者仅适用于一个特定的服务器。访问服务器变量的能力，由专用接口中的一个函数调用提供，通常名为 GetEnv()（或某个类似名称），暗示与标准 CGI 编程中的各个函数调用相同的功能。但是，与 CGI 程序的标准函数不同的是，这些专用实现通常仅是在模仿 CGI 标准实现。这些实现可能仅提供一个服务器变量子集，或者扩展或限制对特定服务器变量类别的支持。举例而言，考虑 ISAPI 接口的 Microsoft IIS 实现。它的 GetEnv() 调用以不同方式对待元变量，使用不同的替换规则来克服所谓的 CGI 标准定义空白。在实际应用程序中，在考虑不同的 Web 服务器时，这会导致不一致的结果。

另一个常见的区别是，在专用接口中，受保护的服务器变量无法由 GetEnv() 调用访问，只能由特定的函数调用访问。例如，有一个特定调用来在 ISAPI 接口和针对 Apache MOD 的接口中检索 REMOTE_USER 变量的值。这是为了提高安全性，应恰当地保护对这个重要的变量类别的访问。

总体上讲，Web 服务器扩展由简单变量、受保护变量和元变量提供。但是，根据具体的接口（CGI 还是专用接口），对它们的访问可能需要不同的代码。尽管 CGI 程序是可移植的，并且适用于任何支持 CGI 标准的 Web 服务器，但这并不适用于使用专用接口的服务器扩展。

有关 Apache 和 Microsoft IIS Web 服务器的服务器变量的更多信息，请参阅本文底部的 “参考资料” 一节。

前面已经提到过，Java 应用服务器也可以实现 HTTP 服务器，但可能仅具有有限的特性。这就引发了如何为 Java 应用服务器实现服务器扩展及其环境的问题。

无需详细了解应用程序符合部署到 Java 应用服务器中，明白可执行代码可通过两种形式部署到 Java 应用服务器中就足够了： Servlet 或 Java Bean 。Java 应用服务器在一个所谓的 容器 中运行可执行程序，而且 Servlet 和 Java Bean 都有特定的容器。这些容器为可执行程序提供了一个已在 J2EE 标准中定义的环境。现在，本文仅重点介绍了 Servlet。

由于与 Web 服务器之间的架构差异，环境的概念在 Java 应用服务器中有所不同。与 CGI 环境相比，Servlet 容器环境更类似于特定于 Web 服务器的接口（比如 ISAPI 和 MOD）所提供的环境。它没有提供任何类型的服务器变量。而 Servlet 容器通过使用 Servlet 规范中定义的调用，提供了对大多数简单服务器变量中包含的信息的访问能力。此外，它们还支持访问从客户端收到的设计请求，这使得 Servlet 能够直接访问请求标头，而无需读取元变量。最后，由于服务器变量的缺乏，需要一种机制来提供 SSO 中使用的两个受保护服务器变量（REMOTE_USER 和 USER_PRINCIPAL）。这种机制通过专用的标准函数调用来提供。

举例而言，考虑一个 Servlet，它希望获取有关在请求中向服务器发送的授权数据的模式的信息。在 Web 服务器上，此信息保存在一个简单服务器变量 AUTH_TYPE 中。因为 Servlet 容器没有提供服务器变量，所以该信息必须通过 Servlet 规范中定义的调用来获取。但是，如果 Servlet 在寻找 REFERER 信息（一个可选的 HTTP 标头），那么它可以直接从请求中读取该信息。

要评估与服务器变量关联的信任水平，必须知道访问服务器变量的外部应用程序如何处理这些变量。之前已经指出，服务器变量不会离开服务器。它们不会附加到 HTTP 请求，它们只能在服务器本地访问。这意味着，如果某个软件希望使用服务器变量中包含的信息来实现 SSO，则必须通过在服务器上部署一个软件来处理此信息，否则必须将该信息传递到服务器外部。因为对于如何将服务器变量传递到服务器之外，没有既定的标准，所以每个软件解决方案都实现了自己的方法。服务器变量的信任度是固定的，但如果外部应用程序被强制将从服务器变量检索的信息传递到服务器外部，那么解决方案的信任度就取决于应用程序的信任度。

要总结一下服务器变量，可以说：

• 元变量类型的服务器变量是不安全的，不应用于实现 SSO。这是因为元变量是请求标头的表示形式，所以任何人都可以在一个附加到有效请求的伪造 HTTP 标头中发送一个元变量的值。
• 受保护的服务器变量在设计上非常值得信任，而且非常适合用在 SSO 解决方案中。只有在用户得到了服务器的安全层的验证时，这些变量才会填充。取决于从它们读取的信息是否传递到远程软件应用程序，受保护的服务器变量应被作为一种最佳实践。
• 简单服务器变量也值得信任，但它们的安全性比受保护的服务器变量更弱，因为拥有 Web 服务器本身的本地访问能力的恶意用户可能伪造它。此外，从它们检索的信息可以传输到其他软件组件，这也影响了解决方案的总体信任度。
  

Cognos 对 SSO 令牌的处理

上一节从技术上介绍了 SSO 令牌。其中提到，IBM Cognos BI 使用了一种独创方法来处理 SSO 令牌的使用，这种方法基于 Cognos 架构。本节将介绍该方法。

IBM Cognos BI 产品文档和 自定义 Java 身份验证提供程序开发人员指南 都描述了如何利用外部令牌来实现 SSO。这些资料仅简要地提及了 cookie，然后介绍了所谓的 环境变量 。进一步讲， 简单环境变量 和 受信任环境变量 之间存在着区别。

简单环境变量被描述为存储 “来自入口点的” 信息的变量。对于变量的起源，我们没有提供更多的细节，比如说，它们是最初由托管入口点的服务器提供，还是由它转发给身份验证提供程序的。相比较而言，受信任的环境变量被描述为 “由 Cognos 入口点网关” 签名的变量，这暗示受信任的环境变量提供的信息是值得信任的，因为 IBM Cognos BI Gateway 对该变量进行了签名，以便保护它在从网关传输到 IBM Cognos BI 身份验证提供程序的过程中免遭篡改。由于简单环境变量没有签名，所以可以说简单环境变量不一定值得信任。尽管文档中没有明确提及，但受信任的环境变量也包含 “来自入口点的” 信息，而且更重要的是，它们由每个支持的入口点提供。

IBM Cognos BI 身份验证提供程序使用了一个 API，该 API 定义了一些 API，可供身份验证提供程序用于读取简单变量或受信任的环境变量，或者在需要时读取 cookie。IBM Cognos 自定义身份验证提供程序开发人员指南 描述了这个 API 的 Java 版本，对细节感兴趣的人可以看一看。需要进一步解释的是环境变量的处理，以及 IBM Cognos 入口点对检索它们的作用。

在本文前面的内容中，我们看到了对于 IBM Cognos BI，有两个有效的入口点。第一个入口点（也是首选的入口点）是一个部署到 Web 服务器的 IBM Cognos Gateway。一个 Servlet 网关或 Dispatcher（都部署到 Java 应用服务器）也可用作入口点。

部署到 Web 服务器的 IBM Cognos Gateway 存在于 3 种不同实现之中：CGI、ISAPI 和 MOD。这些实现利用了之前在 SSO 令牌类型深入探讨 中介绍的 Web 服务器扩展接口，它们代表着典型的 3 层架构的 Web 层中的 IBM Cognos BI 架构。连接 Web 层的 IBM Cognos BI 很重要，因为处理 Web 应用程序身份验证的工作通常在 Web 层中完成，因此 Web 服务器发挥着重要作用。许多实现 Web 应用程序安全性的商务产品（比如通过其 WebSEAL 组件、CA SiteMinder 或 Central Authentication Service (CAS) 等产品来实现安全性的 IBM Tivoli Access Manager）被部署到 Web 层，有时甚至直接与 Web 服务器连接。此外，作为一项内置特性，Web 服务器提供了一个身份验证层。实现对 IBM Cognos BI 的 SSO 的首要用途包括某个在 Web 层上运行的身份验证系统，通常cookie 或服务器变量（比如 REMOTE_USER）向 Web 服务器提供某种 SSO 令牌。正因为如此，将 IBM Cognos Gateway 部署到 Web 服务器才被实际当作 SSO 配置的最佳实践的原因（但严格来讲，IBM Cognos Gateway 不是 IBM Cognos BI 系统的架构中一个必不可少的组件），因为 IBM Cognos Gateway 允许访问 Web 服务器上的服务器变量，该变量通常是 SSO 集成所需要的。

但是，IBM Cognos BI 还支持部署到应用层的入口点：Servlet 网关和 Dispatcher。它们在 Cognos 身份验证流程上提供了类似的功能，允许访问 Java 应用服务器上的服务器变量。应用层入口点可用于身份验证仅在应用层上发生的 SSO 场景，例如在请求被 Web 层中的代理转发时，或者 SSO 令牌仅可用在 Java 应用服务器上时。

每种入口点类型的共同之处在于它们处理 SSO 令牌的方式。此刻，基于之前在 技术实现 一节中介绍的背景和本节目前未知介绍的概念，是时候将技术视图与 Cognos 的 SSO 令牌视图挂钩了。

一个 IBM Cognos 入口点将收到一个 HTTP 请求，该请求随后被传递给身份验证提供程序。该请求中包含请求标头和 cookie。尽管 cookie 提供了一种传输 SSO 令牌的受信任方式，但正如之前解释的，HTTP 标头在默认情况下并不值得信任。现在回想一下，Cognos 明确地区分了简单环境变量或受信任的环境变量。从这一点可以得出结论，Cognos 提供程序在请求检索一个简单环境变量时，它的意思是从请求 “按原样” 读取一个 HTTP 标头。从该标头获取的信息是值得信任的，因为请求标头无法伪造。这可能使文档中 “来自入口点” 的措辞看起来存在歧义，因为请求标头起源于一个客户端。它的含义是指入口点收到的值。

我们现在将关注点转到受信任的环境变量上。在这个 Cognos 上下文中，“受信任” 的含义是，如果访问一个受信任的环境变量时，一个身份验证提供程序（可能在物理上与入口点分开）提供的值与入口点本地的值完全相同。如果涉及到远程软件组件，存在于托管入口点的服务器上的某个变量值必须在远程组件之间安全地传输。安全传输的需求，有关服务器变量的技术细节，之前在 身份验证考虑因素 一节中介绍了身份验证对话概念、入口点考虑因素，以及这些方面的结合使用，这些内容引出了实现这一信任度的 IBM Cognos BI 方法的两个主要概念。

• Cognos 入口点部署在 Web 服务器或应用服务器上。这允许通过 Cognos 代码访问该服务器上的服务器变量。Cognos Gateway 进而可向其他 IBM Cogos BI 组件提供服务器变量。
• 将检索的服务器变量安全地传输到 CAM 的一个远程实例的挑战，可通过结合两种技术来解决。入口点代码对从服务器环境检索的服务器变量值执行数字签名，以便 Cognos 身份验证提供程序可检验它收到的信息是否未经修改或损坏，而且这些信息事实上来自一个有效的 Cognos 入口点。要将服务器变量值从入口点传输到 CAM 并传输到身份验证提供程序上，可以采用身份验证对话的概念。
  

我们将详细地查看这个过程。Cognos 身份验证提供程序通过某种 API 调用请求一个受信任的环境变量。此调用触发 CAM 对收到的身份验证请求中的一个 HTML <form>参数 CAM_SecurityBlob 进行分析。在此参数中，一个 Cognos 入口点将提供对 SystemRecoverable 异常的响应。如果未找到此参数，检索受信任环境变量的调用就会返回一个指示器，表明一个 SystemRecoverable 异常需要 “提示系统提供信息”。身份验证提供程序代码对此的反应是，抛出一个 SystemRecoverable 异常，将请求的服务器变量的名称附加到异常的提示信息中。通过采用专用的 HTTP 请求代码 599，最初通过身份验证对话将请求转发给 CAM 的 Cognos 入口点将被告知它需要处理该异常。这一处理将意味着入口点将分析响应中一个名为 SecurityBlob 的特定的 SOAP 元素。此元素包含身份验证提供程序请求的服务器变量名称的 base64 编码的二进制表示，该服务器变量之前已在 SystemRecoverable 异常的提示信息中指定。入口点代码现在采用 Web 服务器或应用服务器的 API 函数来检索指定的服务器变量，也就是说，是从本地服务器环境读取。

接下来入口点对检索的数据执行 base64 编码并对它执行数字签名。因为上下文仍在处理一次身份验证对话中的 CAM 异常，所以入口点现在将这个已经编码和签名的值附加到 HTML <form> 参数 CAM_SecurityBlob 中，然后，将原始请求重新发送给身份验证服务器。

身份验证提供程序代码单独查看每个请求，所以现在在一个新请求到达时，将执行对以前的请求执行的相同代码。身份验证提供程序同样将请求受信任的环境变量。但是，这一次将参数 CAM_SecurityBlob 已存在，而且将检验附加的 SecurityBlob 参数的签名。如果签名验证失败，请求就会被视为已修改，它的信任度将无法保证。此刻 SSO 身份验证将会失败。如果签名检验成功，从请求的服务器变量解码出的参数内容将返回给身份验证提供程序。如果该变量被证明是空的或不存在，那么此刻 SSO 身份验证将会失败。身份验证提供程序代码现在可返回执行基本身份验证或抛出错误并退出。但是，如果从入口点收到的值是正确的，那么身份验证提供程序可以继续处理请求，进入下一个阶段。

前面几段描述了一次身份验证对话的技术细节。数字签名可确保信息的信任度。这是 IBM Cognos 提供受信任的环境变量的方式，这些变量在技术上与服务器变量相对应。

小结

下面总结了以下 IBM Cognos BI 对 SSO 令牌的支持，

• 每个 IBM Cognos BI 入口点可向 IBM Cognos BI 身份验证提供程序提供 cookie、HTTP 标头和服务器变量，用它们来实现 SSO。
• 根据入口点类型，可用服务器变量集合可能有所不同。Web 服务器部署的网关可提供所有 SSO 令牌类型。Servlet 网关和 Dispatcher 仅应用于 cookie 或受保护的服务器变量，因为 Java 应用服务器上没有简单服务器变量，只有元变量。
• 服务器变量可由 IBM Cognos BI 在一个安全且受信任的实现中在内部检索和传输。
• 由于它们的设计，元变量不应由任何 SSO 配置使用。元变量的设计意图是，显式将请求标头提供给服务器环境，使传递给服务器的信息会特意在服务器的环境中表示。
• 受保护的服务器变量（比如 REMOTE_USER 和 USER_PRINCIPAL）是 SSO 令牌的首要选择。SSO 集成的安全性依赖于管理员配置的 SSO 令牌类型。如果没有提供对安全令牌（cookie、REMOTE_USER）的支持，则应考虑通过 IBM Cognos 发出一个增强请求。
  

我们可得出的一个结论是，使用 Web 服务器部署的网关时，要知道它可以被绕开。这意味着，在直接访问 Servlet 网关或 Dispatcher 时，必须特别关注注意配置的 SSO 令牌类型。具体地讲，如果使用元变量，那么能够以 IBM Cognos 意外的方式（比如防火墙和 IT 过滤）来保护对应用层的直接访问，以便降低该风险。IBM Cognos BI 没有限制客户端访问 Dispatcher，没有以此作为预防某人发送伪造的 HTTP 标头而不是想要的元变量的方式。需要指出的是，这不是 IBM Cognos BI 产品中的缺陷，而是 HTTP 标头和元变量的实际设计的结果。使用元变量来实现 SSO 集成会暴露潜在的安全问题，一个例子是配置基于 HTTP_IV_USER 元变量来集成 SSO 与 IBM Tivoli WebSEAL。对于这种设置，必须防止 WebSEAL 被绕开，或者应该重新设计 SSO 来使用 LTPA cookie 实现单点登录到 IBM WebSphere 部署的 Servlet 网关。

IBM Cognos BI 处理 SSO 令牌的方法的另一个直接影响是，借助提示系统提供受信任的环境变量的能力，之前的 概念 一节中提及的受信任登录身份验证模式会变得更加直观。使用不受信任的 SSO 令牌会承担更大风险，因为在受信任的登录期间没有重新验证过程。如果 Cognos 身份验证提供程序将会使用简单环境变量，很容易欺骗系统信任一个伪造的身份。因此，所有 Cognos 提供程序都显式请求受信任的环境变量来执行 SSO，以减轻服务器变量值在从入口点传输到身份验证提供程序的过程中被篡改的风险。但是，这无法保证得到安全的 SSO 解决方案。

考虑 IBM Cognos BI LDAP 身份验证提供程序，它采用受信任的登录模式来实现 SSO。如果提供程序配置为在其外部身份映射字符串中使用元变量，Cognos 将信任一些可能伪造的信息，因为尽管服务器变量已 “按原样” 从入口点安全地传递到身份验证提供程序，但元变量仍然反映的是一个请求标头，该标头在到达入口点之前就可能已被伪造。正因如此，最佳的做法是仅使用受保护的服务器变量（比如 REMOTE_USER 或 USER_PRINCIPAL）或 cookie 作为受信任的登录模式中涉及的 SSO 令牌。下一节将详细讨论，受信任的登录 SSO 模式是 IBM Cognos BI 中的主要模式，因为所有 Cognos 身份验证提供程序都在使用它，除了 Kerberos 模式（默认）下的 Active Directory 提供程序和 SAP 提供程序。

为了支持受信任登录 SSO 模式对 IBM Cognos BI 的重要性，引入了 受信任登录提供程序 (TSP)，它进一步扩大了 SSO 设置的范围。与入口点一样，TSP 被视为 “系统的一部分”，表明在提供受信任的环境变量方面它可充当一个受信任的来源。事实上，在 TSP 内，可以将一个受信任的环境变量附加到请求，随后将该请求传递给辅助身份验证提供程序。从技术上讲，这将添加一个已签名和编码的 HTML <form> 参数 CAM_SecurityBlob，就像入口点所做的一样。辅助提供程序（它请求一个受信任的环境变量）收到一个有效的结果，而未实际触发 SystemRecoverable 异常，因为需要的 CAM_SecurityBlob 参数已经存在。此外，因为请求是从 TSP 传递到完整提供程序的，所以请求设置不会在网络上传输。这正是 TSP 一开始就被指定为受信任的提供程序的原因。它们的主要用途是，将任意 SSO 令牌转换为 REMOTE_USER，这在使用该信息的辅助身份验证提供程序看来，就好像该值是从实际入口点上受保护的服务器变量上读取的。信任度是相同的。但是，TSP 的潜力大得多。TSP 并不仅限于受信任的变量，它们可将 SDK 凭据添加到请求或甚至 cookie 中。尽管使用 cookie 似乎有点过时，但可能有些 cookie 需要某种特殊处理，或者需要添加另一个提示来将用户或系统信息收集到进程中（例如，用于实现双因素身份验证）。因此，TSP 的存在并不会自动表明它就是简单的受信任登录，它可执行其他更复杂的处理。

回页首

身份验证提供程序的 SSO 支持

本节将详细介绍现成的 IBM Cognos BI 身份验证提供程序所提供的 SSO 支持。

LDAP 身份验证提供程序

IBM Cognos BI LDAP 身份验证提供程序通过受信任的登录，以基于受信任的环境变量的身份映射的形式来支持 SSO。未提供对 cookie 的支持，但可配置要使用的受信任环境变量。

在 LDAP 命名空间配置中，有一个属性叫做 External Identity Mapping 。此属性接受一个字符串，根据 RFC 2254 的定义，该字符串必须在语法上表示一个绝对的区分名 (Distinguished Name, DN) 或一个兼容 LDAP V3 的有效搜索过滤器。该属性支持两个 IBM Cognos BI 配置宏，

• ${environment(<variable_name>)}
  这个宏将替换为指定的环境变量的值。但是，这个宏可能出现多次，它们必须请求同一个变量（参见下面的示例）。不支持请求多个环境变量。
• ${replace(<s_source>,<s_pattern>,<s_replaceby>)} 将 <s_source> 中出现的所有 <s_pattern> 替换为 <s_replaceby>。这个宏不支持嵌套，但一个字符串中可存在多个实例。一个参数字符串中出现的任何 \ （反斜杠）或 “（双引号）必须使用 \（反斜杠）进行转义。
  

如果通过将 Use External Identity 属性设置为 true 而启用了 SSO，LDAP 提供程序的 SSO 身份验证流程也将有效：

• 请求传递给 LDAP 提供程序后，将分析它对一个 SystemRecoverable 异常的响应。如果找到身份验证信息，则会跳过下一步。
• 如果没有足够的登录数据，提供程序将会检查配置，如果已启用 SSO，那么它会从配置中提取 External Identity Mapping 字符串。如果 ${environment()} 宏已存在，那么它会检索请求的环境变量名称，并隐式抛出一个 SystemRecoverable 异常，所采用的方法是：调用该函数，以受信任方式检索该变量。
• 收到包含一个 SystemRecoverable 异常的结果的请求时，将考虑检索的值。如果该值是空的，表明该环境变量无法检索或未设置。则会导致 SSO 失败，提供程序抛出 UserRecoverable 异常来要求提供凭据，从而继续求助于正常的交互式身份验证。如果环境变量值已成功检索，External Identity Mapping 字符串将使用所有定义的宏来转换。转换的结果必须是一个绝对 DN 或有效的 LDAP 搜索过滤器。
• 现在提供程序将使用配置的绑定凭据绑定到 LDAP（或者如果绑定凭据为空，则为匿名访问）并发出一个查找查询来识别用户 DN。对于一个 LDAP 过滤器，一个使用配置的基础区分名 (BaseDN) 执行的 LDAP 搜索，将发出使用子树范围串联的 External Identity Mapping 字符串与一些额外的过滤器条件。对于绝对 DN，将发送一次直接查找查询。请注意，LDAP 提供程序不支持以下 LDAP 推介 (referral)，因此搜索仅限于 LDAP 服务器所绑定到的内容。
• 如果查找查询的结果只有一个条目，那么提供程序会假设从外部收到的身份已成功映射到 LDAP 服务器中的一个身份，并继续执行操作。如果没有结果或存在多个结果，那么 SSO 将会失败，提供程序会抛出 UserRecoverable 异常来要求提供凭据，从而继续求助于正常的交互式身份验证。
• 执行成功的查找查询后，提供程序会使用它的命名空间配置从 LDAP 查询所有已配置的属性，最终为该命名空间发放一个签证。SSO 已成功完成。
  

一定要了解的是，这个 SSO 仅基于映射字符串。例如，可以从 Active Directory 传入一个用户名，然后，该用户名被映射到一个具有相同名称的 LDAP 用户。这是否是同一个实际用户并不清楚，也不清楚是否传入了对该用户身份的任何重新验证请求。尽管存在缺陷，但映射字符串提供了很高的灵活性，它们可通过在 LDAP 中复制用户，支持 IBM Cognos BI 中一些无法直接支持特定身份验证来源的 SSO 场景。

实现基于 LDAP 提供程序的 SSO 的难处通常在于设计 External Identity Mapping 字符串。宏的使用和 LDAP 过滤器语法的知识必不可少。

示例：

• (sAMAccountName=${replace(${environment("REMOTE_USER")}, " EUROPE\\","")})
  允许来自 Active Directory 域 EUROPE 且经过 Microsoft IIS Web 服务器验证的用户使用 LDAP 身份验证提供程序单点登录到 IBM Cognos BI，该提供程序使用 LDAP 访问 EUROPE 域控制器。IIS 将在 REMOTE_USER 中填入 domain\user （即：EUROPE\montagg）。这个宏从 REMOTE_USER 中删除域部分（包括反斜杠），仅留下用户名（即：montagg）。该用户名映射到 Active Directory 中一个用户条目的 sAMAccountName 属性。
• (|(uid=${environment("REMOTE_USER")})(cn=${environment("REMOTE_USER")}))
  允许通过将 REMOTE_USER 中传递的用户名映射到所访问的 LDAP 服务器中一个用户条目的 uid 或 cn 属性，以便通过 LDAP 身份验证提供程序从任何安全层单点登录到 IBM Cognos BI。此单点登录方法要生效，惟一的要求是，填充 REMOTE_USER 的安全后端放入一个与该用户在 LDAP 中的一个属性值匹配的字符串。这会将外部提供的身份映射到某个 LDAP 用户。一个示例是从 Web 服务器验证的用户执行单点登录，无论 Web 服务器实际上是如何验证他们的。
• (&(uid=${environment("REMOTE_USER")})(departmentNo=17))
  允许通过将 REMOTE_USER 中传递的用户名映射到所访问的 LDAP 服务器中 uid属性，以便通过 LDAP 身份验证提供程序从任何安全层单点登录到 IBM Cognos BI。但是，此访问仅限于在 departmentNo 属性中拥有值 17 的 LDAP 用户。此示例演示了串联过滤器的使用。
  

需要提醒的是，最佳实践是仅将 REMOTE_USER 或 USER_PRINCIPAL 用于提供变量名称。其他任何变量都可能是伪造的，具体情况取决于 IBM Cognos BI 入口点的暴露情况。

有关配置 LDAP 命名空间的更多信息，请参阅 IBM Cognos BI 安装和配置指南 中的配置 IBM Cognos 组件以使用 LDAP 一节。

Active Directory 身份验证提供程序

Active Directory 提供程序支持两种不同的 SSO 模式。

第一种模式是基于 Microsoft Kerberos 的 SSO，它利用 Microsoft API 在 Microsoft Internet Explorer 客户端、Microsoft IIS Web 服务器、IBM Cognos BI 和 Microsoft Active Directory (AD) 之间实现 Kerberos 握手。

仅在 Microsoft IIS 充当一个 Web 服务器来托管 IBM Cognos BI Gateway 时，才支持使用这种模式。Active Directory 身份验证提供程序仅在 IBM Cognos BI Content Manager 组件安装在 Microsoft Windows 上时才可用。不过，可以将 IBM Cognos BI 应用层分开，并将它部署到任何支持的平台。但是，IBM Cognos Gateway 和 Content Manager 必须被部署到 同一个版本 的 Windows（32 位、64 位或二者的组合），这种 SSO 模式才会生效。

第二种 SSO 方法使用身份映射来实现，这非常类似于 LDAP 提供程序所实现的方法。LDAP 提供程序绑定到单个 LDAP 服务器并发出一次用户查找搜索。但是，Microsoft 的 Active Directory 基础架构可包含多个 AD 服务器，用于多个、分层结构的域树，这些树组织在一个所谓的 域林 中。因为 IBM Cognos BI Active Directory 提供程序直接利用 Microsoft 的 API，所以它可以支持这种复杂的多服务器基础架构，进而在由于缺乏对 LDAP 推介的支持而使 LDAP 提供程序受到限制时，支持访问多个服务器来查找一个用户。但是，AD 提供程序没有提供任何针对查找搜索的配置选项，而是使用了 Microsoft 所定义的标准。这个概念与 LDAP 提供程序相同，但用于传递用户身份字符串的变量固定为 REMOTE_USER，所以查找搜索会对比该字符串与 AD 用户的 sAMAccountName 属性，不只是单个用户，提供程序可以搜索单个域、一个域树或整个域林。

默认情况下，如果 singleSignonOption 高级参数未在 IBM Cognos Configuration 中显式指定，AD 提供程序会假设对 SSO 采用了 Kerberos 模式。仅在 singleSignonOption 参数设置为 identityMapping 时，该提供程序才会禁止使用 Kerberos，而改为使用身份映射模式。更改需要重新启动 IBM Cognos BI，但不会影响目前使用以前的设置定义的任何授权，只会影响身份验证。

对于 Kerberos 模式的 SSO，在用户通过 Kerberos 向 Microsoft IIS 服务器验证后，针对 Microsoft Active Directory IBM Cognos BI 身份验证提供程序将采用 Microsoft 的安全支持提供程序接口 API (SSPI)，将用户的身份委托给该提供程序。从技术上讲，发生此过程至少需要 3 个 SystemRecoverable 异常，用以来回传输 Kerberos 令牌内容。因此，使用的 SSO 令牌为 Kerberos 令牌。委托成功后，提供程序将模仿该用户，尝试向 AD 执行验证。如果成功，那么提供程序将会获得一个安全令牌，有了这个令牌，已向 AD 验证的会话就能够检索用户的更多信息，以及它们的组成员关系。需要指出的地方是，在此模式下，用于 Microsoft Active Directory 的 IBM Cognos BI 身份验证提供程序仅是消息的传递者。Kerberos 令牌绝不会由提供程序自身修改或处理。如果出现错误，那么这些错误将是返回错误的 Microsoft SSPI API 调用所导致的。

委托过程可能使得设置 Kerberos SSO 模式变得很困难，因为必须满足 Microsoft 基础架构中的许多前提条件。但是，所有这些前提条件都不是 IBM Cognos 特别需要的，让此 SSO 生效所涉及的绝大多数问题都可以通过处理所记录的 Microsoft Windows 前提条件和设置 IIS 来解决。“参考资料” 一节包含有关通过设置 IIS 将它用在 IBM Cognos BI 环境中的一些信息的链接。

在身份映射模式下，提供程序将使用标准环境变量 REMOTE_USER（如果有必要，则会抛出一个 SystemRecoverable 来获取它），该变量应具有 4 种可能的格式，

• 用户名 (sAMAccountName)
  用户的 Windows 登录名，存储在 AD 中一个名为 sAMAccountName 的属性中。您需要了解的是，sAMAccountName 仅在单个域中是惟一的，不适用于多域环境。一个用户名示例是 montagg 。
• 添加域作为前缀的用户名 (domain\sAMAccountName)
  用户的 Windows 登录名，存储在 AD 中一个名为 sAMAccountName 的属性中，以用户初始使用的 Windows 域名称作为前缀并使用一个反斜杠分开。通过添加域作为前缀，可保证名称在林中得到惟一标识。一个示例是 US\montagg 。
• 区分名
  用户在该域的 AD 结构中的绝对区分名。例如，一个 DB 可能为 cn=Guy Montag,cn=Users,dc=US,dc=CORP 。
• 用户主体名 (user principal name, UPN)
  用户主题名 (UPN) 是为 Windows 概要文件中的用户定义的。一个示例 UPN 是montagg@US.CORP 。
  

最佳实践是使用以域名为前缀的用户名。原因在于，在 Microsoft Windows 中，用户 ID 仅在单个域中是惟一的。没有域前缀，就可能在一个不同域中找到一个类似的用户，这会阻碍身份验证。其他 3 种格式将被转换为 domain\sAMAccountName 格式，但提供程序需要额外调用 Microsoft API，如果转换失败，则有可能导致出现错误。对于 REMOTE_USER 中提供的未限定的（即：没有域前缀）的用户名，域被假定为提供程序配置为附加到的域。

检索的 REMOTE_USER 值原封不动地被传递到 Microsoft API，以便向 AD 运行身份验证。如果向 AD 的身份验证成功，那么用户会向 IBM Cognos BI 进行验证，并发放针对该命名空间的签证。

再次强调，身份映射仅基于字符串值，REMOTE_USER 中传递的用户名可能起源于任何安全层。如果 AD 中有一个用户具有与所传递的字符串匹配的 sAMAccount 属性值，那么 SSO 将会成功。

请参阅 IBM Cognos BI 安装和配置指南 中的 配置 IBM Cognos 组件以使用 Active Directory 提供程序 一节，了解配置 Active Directory 提供程序的详细信息。

SAP 身份验证提供程序

用于 SAP 的 IBM Cognos BI 身份验证提供程序利用 SAP 所提供的业务应用程序接口 (Business Application Interface, API)。它仅支持基于 SAP MYSAPSSO cookie 的 SSO。这个 cookie 只能由其他 SAP 软件产品创建，比如 SAP NetWeaver。

如果提供程序找到 MYSAPSSO cookie，该 cookie 将 “按原样” 传递给 BAPI，然后，后者会尝试向 SAP 执行验证。如果 SAP 认可该 cookie 而且获得的 SSO 票证有效，则会将用户视为已通过验证，NAPI 将继续检索用户信息和安全组成员关系。

Series 7 身份验证提供程序

IBM Cognos BI Series 7 身份验证提供程序可用于支持 IBM Cognos 遗留产品。该提供程序支持基于以下因素的 SSO，

• 受信任的环境变量
• 未加密的明文 cookie
• 一个称为 AS_TICKET 的专用 IBM Cognos Series 7 cookie
• 一个使用 IBM Cognos Series 7 SDK 开发的受信任登录插件。这些插件可使用 token 并在 REMOTE_USER 中提供一个值，然后，该值用于尝试受信任的登录。
  

借助 IBM Cognos Series 7 Access Manager 管理工具，可为每个用户定义所谓的OSSignon 。这个字符串保存为用户的一个属性。

对于 SSO，一个使用类似于 LDAP 提供程序的宏表达式的可配置字符串属性，将定义要使用两个受支持的 SSO 令牌中的哪一个。可检索一个可配置的受信任环境变量或一个未加密的明文 cookie。在解析该字符串值后，会将它与存储在 Series 7 命名空间中的所有定义的 OSSignon 对象对比。如果找到一个匹配值，则会对相应的用户执行验证。

因为受信任的环境变量的名称可在上面提到的配置属性中指定，所以提供程序并不会固定使用 REMOTE_USER。但是，出于之前的 Cognos 对 SSO 令牌的处理 一节中讨论的原因，最佳实践是坚持使用受保护的服务器变量。尽管 REMOTE_USER 也支持明文 cookie，但它仍提供了最佳的安全性，因为很容易伪造明文 cookie 或将其注入会话中。

由于它的专用性质和作为遗留产品的状态，Series 7 安全性正被逐步淘汰，在受影响的产品中被改善的对与其他提供程序的集成支持所取代。因此，对于新应用程序，最佳实践是尽可能地利用 AD 或 LDAP 提供程序。

RACF 身份验证提供程序

资源访问控制工具 (Resource Access Control Facility, RACF) 是 IBM System z 的一个安全软件层。IBM Cognos BI 针对此安全系统的提供程序在技术上比预先配置的 LDAP 提供程序稍微复杂一点。对 RACF 的支持是通过要求将 IBM Tivoli Directory Services (TDS) 安装在 RACF 上来实现的，这会是的 RACF 可以通过 LDAP 进行使用。因此，对 RACF 的 SSO 支持是 LDAP 提供程序所提供功能的子集，具体地讲，它仅限于基于 REMOTE_USER 环境变量的身份映射。

NTLM 身份验证提供程序

NTLM 自 IBM Cognos BI version 10 开始已弃用，通常仅用于测试系统。不过该提供程序仍存在，仅通过身份映射来支持基于 REMOTE_USER 环境变量的 SSO。

CA SiteMinder 身份验证提供程序

IBM Cognos BI CA SiteMinder 身份验证提供程序实际上是一个 TSP。它使用名为 SMSESSION 的专用 CA SiteMinder cookie，将传递到 CA SiteMinder API 进行检验。成功检验该 cookie 后，该 API 将向提供程序返回 SiteMinder UserDirectory 的名称或指定的 UserDirectory 中的 LDAP DN。结合这两部分信息，就可以为 CA SiteMinder 惟一地标识一个用户。UserDirectory 是 SiteMinder 中的保存用户的存储库的概念。从技术上讲，它可能是一个 LDAP、一个 AD 或一个数据库。每个 UserDirectory 由 SiteMinder 中配置的一个名称标识。DN 采用 X.509 表示法并指定该 UserDirectory 中的用户。

根据配置，此信息被映射到一个辅助 IBM Cognos 身份验证提供程序（通常为 LDAP 或 AD），而且用户的 DN 在 REMOTE_USER 中传递到这个辅助提供程序。因此，它是一种受信任的登录，基于从 cookie 获取的映射的身份。

回页首

实现向 IBM Cognos BI 的单点登录评估各个选项

要实现单点登录到 IBM Cognos BI，成熟的方法是首先识别请求从客户端传输到 IBM Cognos BI 入口点的过程中每个跃点上可用的 SSO 令牌类型。这可以确定是否可以直接使用一个现成的身份验证提供程序。如果不可以使用，那么下一步将是进行以下评估：通过相对较少编程工作编写一个 TSP，是否足以将现有 SSO 令牌转换为一个现成提供程序支持的其他某种令牌类型。如果连该评估的结果也是消极的，那么最后一个办法是实现一个重大的 Java 编程项目来创建一个完整的 CJAP。以下要点提供了一些指南，用于确定可用于使用现成提供程序获得 SSO 的选项。

• 如果仅有一个任意 HTTP 标头可用，则会排除除 LDAP 外的所有 IBM Cognos BI 提供程序，从技术上讲，这可以使用一个元变量来实现 SSO。出于安全原因，不鼓励这么做。作为最后手段，可以编写一个 TSP，通过某种方式实现对任意 HTTP 标头的支持，但由于技能和复杂性需求，这是最不受欢迎的选项。
• 如果某个 Web 服务器或应用服务器在请求传输过程中提供了受保护的服务器变量 REMOTE_USER，这允许使用 LDAP、AD 和 RACF 提供程序作为潜在的候选方案。从技术上讲，该产品中仍包含 Series 7 和 NTLM 提供程序，但这些提供程序正被逐步淘汰，因此不是新安装的理想候选方案。对于提供了变量的应用服务器，使用 Servlet 网关是最佳的选择。对于提供了变量的 Web 服务器，如果可能的话，可以部署一个 ISAPI 或 MOD 网关。如果无法这么做，那么可以使用一个 CGI 网关，但需要知道的是，由于 CGI 的设计，这可能对性能带来负面影响。
• 如果 cookie 是 SSO 令牌的惟一选择，需要一个 TSP，因为 Series 7 命名空间（在技术上讲确实支持 cookie）正被逐步淘汰，不应用于新设置。使用 TSP 的 cookie 的简单示例，可非常快速地从 IBM Cognos BI 身份验证提供程序 SDK 所提供的示例中得到。这将足以在 REMOTE_USER 中提供大多数提供程序都支持用于 SSO 的 cookie 的值。
  

强烈建议仅在其他所有选项都行不通时才考虑 CJAP。除了 IBM Cognos BI SDK 的额外的许可费用之外，设计和创建全功能 CJAP 的工作量也可能很大，并且需要高级的 Java 编程技能。另一方面，创建 TSP（也需要 IBM Cognos BI SDK 许可）通常对有能力的 Java 编程人员很简单，而且应该花费不了多少时间。考虑 CJAP 之前，始终应全面分析是否实现了 TSP。

最终的问题是，实现无缝的身份验证体验需要花费多少工作，而不是 是否 可以实现这种体验。时间限制和预算等实际限制可能会排除一些可用选项，但一般而言，实现无缝身份验证体验的最困难之处来自缺乏对可用选项的背景知识的了解。

最佳实践方法

在评估选项后，配置一个 IBM Cognos BI 测试环境并在 IBM Cognos Configuration 中配置想要的身份验证提供程序。使用 测试 功能检验提供程序是否能够访问身份验证来源。值得注意的是，没有针对 TSP 或 CJAP 的测试特性。

在配置和测试了身份验证提供程序后，在 Cognos Configuration 中禁用匿名访问，并尝试使用交互式模式向 IBM Cognos BI 执行验证。在浏览器中打开 IBM Cognos Connection URL，如果获得提示，请选择一个用于身份验证的命名空间，并在登录屏幕上明确提供凭据。这一步应该成功，以便为下一步做好准备。

因为 IBM Cognos BI 处理仅在请求发送到入口点之后才开始，所以最好在没有实际的身份验证解决方案的情况下模拟这些请求，以便正确设置和配置 IBM Cognos BI。此方法对排除问题也很有用，它使用户只需关注 IBM Cognos BI 功能或提供 SSO 令牌的安全系统。它还有助于向 IBM Cognos Support 提供测试案例，这些案例不一定能详细地再现任何环境，尤其是在涉及到第三方软件或自定义解决方案时。

可用于创建简化的环境或模拟提供了 SSO 令牌的安全系统的工具包括 Fiddler2 或 Firebug。Web 服务器配置项（比如用于 Apache Web 服务器的 SetEnvironment 语句）可能很有用。请参阅附录 B查看详细示例。一种有效的方法是，使用这些示例中描述的一种方法或其他任何适用技术创建实际的 SSO 令牌，在发送给 IBM Cognos BI 的请求中传递该令牌的一个固定值。

如果无法模拟所假定的安全系统，那么最低限度上必须有一种方式捕获客户端、身份验证层和 IBM Cognos BI 之间的 HTTP 流量。这将有助于限制是否应该传递令牌。IBM Cognos BI 提供了充分的跟踪和日志记录特性，用以确定传递的令牌是否已收到、被成功使用，以及实际的身份验证是否有效。请参阅附录 A了解更多细节。

回页首

支持状态

尽管 IBM Cognos BI 产品已尽力集成身份验证和实现单点登录，但仍应想到需要与多家供应商合作来解决 SSO 问题。

本节尝试提供一些指南，帮助确立

• 已知有效的方法
• 经过测试的方法
• IBM Cognos 支持或服务部门提供的支持
  

IBM Cognos 在 IBM Cognos Software Environments 页面 上提供了一致性和支持的软件环境的详细列表。除了支持的环境列表，还提供了有关针对特定环境的各种支持级别的信息。请特别留意支持状态的定义。从这里，可以获得已知有效或预计有效的方法的信息。与此同时，还有一个叫做 Cognos Unsupported Environment Policy的对应页面。此策略适用于未在 IBM Cognos Software Environments 页面上显式列出的所有环境。

考虑到上述因素后，您可能会发现，在排除第三方产品的故障方面可能存在依稀灰色区域。IBM Software Environments 页面中列出了第三方产品的事实，并不表明 IBM Cognos Support 将排除该产品的故障。常见的做法是，对于所列出的环境，IBM Cognos 支持和服务部门将通过各种方式积极提供充分的信息，帮助成功实现上述集成。具体地讲，集成需要的第三方产品将记录在案，所需的这些产品应该已经创建。与此同时，还必须准备好查阅第三方产品的文档和/或咨询支持组织。

这里提及了一些经常发生的示例：

• 集成 IBM Cognos BI 产品与 IBM Tivoli Access Manager WebSEAL
  尽管 WebSEAL 是另一个 IBM 产品的一部分，但官方未提供对在 IBM Cognos BI 中与它集成的支持。
• Computer Associates SiteMinder
  这是一个专门用于 CA SiteMinder 的 IBM Cognos BI 身份验证提供程序。此提供程序基于 CA SiteMinder cookie SMSESSION 进行集成。但是，该提供程序仅支持 6.5 及以下的 SiteMinder 版本。对于高于 6.5 的 CA SiteMinder 版本，没有官方支持。SSO 集成可利用 IBM Cognos Technotes 和文档中记录的 “轻量型 SiteMinder” 方法来实现。但是，出于之前介绍的原因，最佳做法是使用 REMOTE_USER 代替 SM_USER。
• Microsoft Kerberos
  用于 Active Directory 的 IBM Cognos BI 身份验证提供程序所实现的基于 Kerberos 的 SSO，需要通过 Microsoft 软件组件实现多个必要功能。前提条件通常被发现未得到满足，具体地讲，Microsoft 的 Internet Information Server (IIS) 的配置不足或缺乏需要的委托设置。IBM Cognos 记录了这些前提条件，并在各种 Technotes 和文档中分享了有关如何满足它们的信息。
  

回页首

附录 A – 必须收集的故障排除信息

必须收集以下这些信息，才能高效地排除故障。您会发现，没有针对第三方软件配置项目或类似项目的具体信息。原因在于，AAA 轨迹支持看到传递给 Cognos 的信息，这已足以排除 SSO 的 Cognos 一端的故障。

• 所处情况的简要描述
  • SSO 的定义/需求。从哪个安全层单点登录到 IBM Cognos BI？这是否关乎无缝的身份验证体验或设计传递用户身份？
  • 预期的用户体验是什么？哪些用户在访问，他们应看到哪些信息？他们在何处执行身份验证（如果要执行身份验证）？
  • 用户操作的清晰描述。如果可能，包含视频或屏幕截图的支持描述。
    
• 技术信息
  • 客户端和服务器所涉及的软件和硬件
  • 哪些客户端在访问哪些服务器？
  • 版本号
  • 平台（操作系统级别）
  • IP 地址和主机名
    
• IBM Cognos BI 配置信息
  • IBM Cognos BI 组件安装在何处和它们如何分布？
  • 来自运行 Content Manager 或/或网关的 Cognos 安装的 cogstartup.xml 文件（位于基础安装目录下的 configuration 目录中）。对于多个 Content Managers 或网关，提供其中一个。
  • 来自基础安装目录的 cmplst.txt 文件。
    
  
  

AAA 轨迹

IBM Cognos BI 提供了一个基于 XML 的日志记录工具，叫做 Indication Processing Facility (IPF)，基本上讲，它是一个围绕 Apache Foundation 所提供的已知 log4j 框架的包装器。要跟踪身份验证流程，有一个有关可用日志配置的模板，激活该模板时，它会创建足够的输出，利用这些输出来排除身份验证和 SSO 故障。

要启用 AAA 轨迹，可以执行 http://www.ibm.com/support/docview.wss?uid=swg21343375 上的 technote 中列出的步骤。

创建 AAA 轨迹后，可以提供要支持的日志文件，或者尝试读取它，查看是否存在任何明显的错误。日志文件拥有清晰的结构，查找单词 “authenticate” 将找到对身份验证函数（ CallStart 操作）的调用和它们的结果（ CallEnd 操作）。

HTTP 轨迹

如果可能的话，HTTP 轨迹有助于加速问题的分析。HTTP 轨迹可通过 Fiddler2 等工具获取。HTTP 轨迹将显示客户端操作，让我们知道 cookie 是否按预期传递和任何重定向是否有效等信息。

回页首

附录 B – 模拟安全系统以提供 SSO 令牌

在配置一些第三方软件与 IBM Cognos 之间的 SSO 时，如果客户遇到麻烦，他们通常会联系 IBM Cognos Support。尽管 IBM 支持策略通常提供了充分的指南，但在一些边缘情况下，客户会被要求删除某个不受支持的第三方软件组件，而事实证明这么做行不通。对于这些情况和涉及到第三方软件的情况，进一步了解这些问题的一种排除故障最佳做法是，使用受支持的软件产品模拟第三方软件。要采用模拟实际的不受支持产品的方法，以下示例可以作为起点。一个问题的根源，常常独立于实际产品，而与一次特定的 HTTP 请求故障相关。这些示例 “按原样” 提供，仅用于为不熟悉 SSO 设置的人提供一个起点。这些示例并不全面，而且相同结果也可使用不同技术获得。

示例 1：使用 Apache Web 服务器提供 REMOTE_USER 来传递 SSO 令牌

此示例允许模拟一个基于 Web 服务器的安全系统，根据设计，这会导致在 REMOTE_USER 中填入某个值，通常为用户名或其他某种形式的 ID。在使用 Apache Web 服务器时，有一个简单的配置指令 SetEnvironment ，它允许在访问 Web 服务器上的某个资源时设置一个任意的环境变量，包括 REMOTE_USER。这在模拟仅使用 IBM Cognos BI CGI Gateway 时很有用。对于包括 MOD Gateway 和 REMOTE_USER 的模拟，必须实际启用和配置 Apache 的身份验证特性。这是因为 MOD 是 Web 服务器扩展，它仅使用 CGI 环境的一个子集，其中不包括受保护的 REMOTE_USER 变量。但是，SetEnvironment 指令适用于所有非标准变量，甚至是 MOD Gateway。

使用 SetEnvrionment：

• 停止 Apache。
• 编辑 httpd.conf 以在 Apache 中添加一个针对 CGI 或 MOD 网关的配置。请访问http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/topic/com.ibm.swg.im.cognos.cp_inst_cr_winux.10.1.0.doc/cp_inst_cr_winux_id11149ConfigureApachegateway.html#ConfigureApachegateway 了解有关的更多信息。
• 按以下方式添加一个 <Location> 指令，<Location /{cognos_alias}>  SetEnvironment REMOTE_USER “montagg”</Location>只要向此未知请求一个资源，此指令就会向 REMOTE_USER 中填入值 “montagg”。结果是，REMOTE_USER 标头将添加到发送给客户端的响应中，但更重要的是，该变量会在服务器环境中设置，这意味着 IBM Cognos BI 的身份验证对话将通过 SystemRecoverable 异常进程抓取它。这允许通过使用 Apache 中的 CGI Gateway 来测试大多数 Cognos 身份验证提供程序。需要将该别名修改为用于访问 IBM Cognos 的实际的虚拟目录。
• 保存 httpd.conf 并重新启动 Apache。
• 启用您最喜爱的 HTTP 监视工具。
• 启用 Cognos AAA 轨迹。
• 运行测试。
  

为 MOD Gateway + REMOTE_USER 使用 Apache 身份验证

请访问 http://httpd.apache.org/docs/2.2/howto/auth.html ，了解本技术中使用的一些背景知识：

• 停止 Apache。
• 编辑 httpd.conf，
  • 在 Apache 中添加针对 CGI 或 MOD 网关的配置。请访问http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/topic/com.ibm.swg.im.cognos.cp_inst_cr_winux.10.1.0.doc/cp_inst_cr_winux_id11149ConfigureApachegateway.html#ConfigureApachegateway 了解更多信息。
  • 启用模块 mod_auth_basic 和 mod_authn_file 。
  • 使用 Apache 命令行工具 htpasswd 创建一个用户文件，其中至少包含一个用户。
  • 将以下内容添加到之前创建的 <ScriptAlias> 元素中，AuthType basicAuthName “Apache authentication required”AuthBasicProvider fileAuthUserFile <absolute path to the User file and filename>Require valid user这会通过使用非常基本的设置来启用 Apache 的身份验证系统。用户在一个文件中定义，登录提示符将由浏览器呈现。这实际上表明，成功经过 Apache 验证的用户将在 REMOTE_USER 中传递。需要将该别名修改为用于访问 IBM Cognos 的实际的虚拟目录。
    
• 保存 httpd.conf 并重新启动 Apache。
• 启用您最喜爱的 HTTP 监视工具。
• 启用 Cognos AAA 轨迹。
• 运行测试。
  

示例 2：使用 Apache Web 服务器在每个请求上发送 cookie 更新

此示例提供了一种使用 Apache 2.2 Web 服务器和 IBM Cognos BI 排除 cookie 处理问题的途径。

大多数身份验证产品的身份验证都基于 cookie。如果任何 IBM Cognos BI 组件无法正确地支持外部产品的基于 cookie 的会话处理，那么 SSO 和身份验证通常会出现问题。问题在于，如果一个外部会话 cookie 常常更新，那么一个 IBM Cognos BI 组件可能无法正确处理更新，或者可能使用一个缓存的值代替。一个典型的症状是，在浏览器客户端运行时，其他类型的客户端可能表现出异常行为。示例包括重量型客户端，比如 IBM Cognos BI Modeller（以前称为 Framework Manager）、IBM Cognos TM1 Architect 或 IBM Cognos Analysis for Excel 和使用 IBM Cognos Mobile 的移动客户端。

对于这些场景，模拟基于 cookie 的会话处理（包括外部安全层的频繁 cookie 更新）可能是一种缩小问题范围的轻松而又简便的方式。

基本理念是使用 Apache 的 mod_header 。此模块允许我们处理传经 Apache Web 服务器的请求的请求标头和响应标头。使用此功能添加一个会在每次往返通信时更新的 cookie 时，设置一种模拟更新其会话的外部安全层的简单方式。

要实现此过程：

• 停止 Apache。
• 编辑 httpd.conf，
  • 在 Apache 中添加针对 CGI 或 MOD 网关的配置。请访问http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/topic/com.ibm.swg.im.cognos.cp_inst_cr_winux.10.1.0.doc/cp_inst_cr_winux_id11149ConfigureApachegateway.html#ConfigureApachegateway 了解有关的更多信息。
  • 通过添加以下行 LoadModule headers_module modules/mod_headers.so，启用 mod_header。
  • 按以下方式添加一个 <Location> 指令，<Location /{cognos_alias}>  Header always append Set-Cookie “%t; path=/;”</Location>此指令的用途是，添加一个名为 “t” 的 cookie，它的值是一个以毫秒为单位的时间戳，基本上讲，该值意味着它总是最新的。需要将该别名修改为用于访问 IBM Cognos 的实际的虚拟目录。
    
• 保存 httpd.conf 并重新启动 Apache。
• 启用 Cognos AAA 轨迹。
• 启用您最喜爱的 HTTP 监视工具。
• 运行测试。
  

现在可以看到每个请求中都传递了一个名为 “t” 的 cookie。如果 cookie 值没有发生改变，那么可能客户端不会处理 cookie 更新。同样地，这只是使用某个标准软件模拟一种行为来帮助解决问题的简单示例。Apache 的 mod_header 功能很方便用于此用途，您可以在参考资料一节中找到有关 mod_header 的更多信息的链接。