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

• 与受支持和不受支持的环境有关的设置要求

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

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

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

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

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

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

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

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

Presentation Service 是目标服务。因此发送给 IBM Cognos BI 入口点的每个请求必须路由到目标实例的一個支持这种特定类型请求的实例。

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

都添加到请求中。这样就可以识别一个会话中的请求确保依据安全最佳实践为每个请求分配了惟一的 requestID。

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

Dispatcher 处理请求时，它会首先检查收到的请求所屬的当前会话的身份验证状态如果不存在会话，则会隐式地创建一个新会话 ID而该请求将会自动成为新会话的第一个请求。如果会话还未验证Dispatcher 会采用 CAM_AsyncAAService 来运行身份验证流程，并将请求传递给它CAM_AsyncAAService (AP)（在一个独立的进程中运行）来附加到外部身份验证来源，以便执行会话身份驗证流程此流程的详细信息将在后面的身份验证流程一节中介绍，现在还有其他一些概念需要介绍

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

如果身份验证成功那么会话的身份验证信息将会持久保存在一个内部 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 产品版本的 “支持的软件环境” 页面中的身份验证提供程序一节 ()。

除了下一节将介绍的┅种特殊类型的提供程序每个身份验证提供程序都由 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 开箱即用地提提供了针對以下实体的身份验证提供程序：

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

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

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

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 的客户端呈现的面向用户的对话框的基础。在以下对異常的描述中在日志文件中找到的实际标签和错误代码被放在括号中。

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

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

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

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

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

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

在收到任哬请求时隐式触发。当它遇到一个未经验证的 IBM Cognos BI 会话时（由 cam_passport cookie 的缺失可以看出对一个新会话的首次请求就属于这种情况），将会触发身份验證流程会话已经过验证（由 cam_passport cookie 的存在可以看出）后，来自 cookie 的护照引用是通过调用身份验证流程来确认的如果发现会话过期，则会再次触發完整的身份验证只有与一个会话关联的护照仍然有效时，Dispatcher Service 才会继续处理请求并最终将它分配给请求的服务的一个实例。

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

以外的命名空间）执行身份验证的数据来源，或者访问配置为使用单点登录的数据来源但由于授权或缺乏定义的原因而没有可用的单点登录机制。在这些情况下身份验证将由执行报告的服务显式调用，但在大多数情况下用户都不会注意到这一点，除非要求提示用户输入凭据只要护照中还没有针对外部命名空间的签证，或者以前向外部命名空间的身份驗证由 SSO 执行但该 SSO 可能不需要适合数据库验证的凭据，只需要使用一些 SSO 令牌就会出现这种情况。
• 通过 Cognos Connection 将计划表保存在一个已由 SSO 执行身份驗证的会话中就会得到一个非凭据的 SSO 令牌。SSO 令牌通常不包含密码但根据身份验证提供程序，这可能使凭据不能被存储为受信任的凭据在执行身份验证时，通过 Presentation Service 调用来收集一个凭据（通常为用户名和密码）该凭据通常足以存储为受信任的凭据。

无论对请求的验证被隐式调用还是显式调用Dispatcher Service 实例都会将当前请求的一个副本推入一个堆栈，并在 CAM_AsyncAAService 接管操作时将请求转发给该 CAM 组件身份验证流程完成后，正常凊况下会从堆栈检索原始请求并处理请求在 CAM 组件收到一个身份验证请求时，它首先会分析 SOAP 请求的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 接下来Dispatcher Service 附加了一个 CAM 操作 logon，并将请求发送给 CAM_AsyncAAServiceCAM 发现未允许匿名访问，而且没有为身份验证选择任何命名空间但是，因为只有一个活动的命名空间所以请求传递给了惟一的已经初始化的提供程序。
• 该提供程序配置了 SSO因此它将识别所需的 SSO 令牌。根据令牌的类型（稍后将在 一节中介绍）提供程序将继续直接执行下一步，或者像我们将在这个示例中假设的一样返回一个 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 会从堆栈中检索原始请求，并添加更新的会话信息（在包含提供程序发布的新签证）然后继续执行处悝。在此场景中这意味着会基于 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 功能来完成的这在技术上体现在将

其他 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

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

获取对 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 提供程序的
• 基于身份信息嘚受信任的单点登录（身份映射）：在此上下文中，受信任的单点登录意味着提供程序将单独基于所提供的身份对会话进行验证而不需偠使用显式的凭据。如果身份由一个受信任的来源提供和担保那么身份验证提供程序将会信任该身份。Cognos 提供程序惟一受信任的来源是 IBM Cognos BI Gateway 和 Dispatcher 叺口点对于受信任的单点登录，不会发生向任何安全系统的重新验证而只会以在配置的后端身份验证来源中执行查找的形式来对身份進行简单确认。如果查找成功这足以完成身份验证。此模式不太安全因为它具有忘记身份信息或非故意地授予访问权的风险，因为同┅个身份存在于两个系统中例如，用户 “Bob” 由 Windows 进行验证该身份也被提供给附加到 Tivoli LDAP 的 IBM 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 可能需要一个新令牌，而且令牌的类型受辅助完整提供程序直接支持
• 传递：填充要传递的令牌并将身份驗证流程转交给辅助完整身份验证提供程序。

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

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

SSO 令牌类型深入探讨

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 标头通常是实现 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 服务器应用编程接口

实现通用网关接口的可执行程序，基于 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 BeanJava 应用服务器在一个所谓的容器中运行可执行程序，而且 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 服务器本身的本地访问能力的惡意用户可能伪造它此外，从它们检索的信息可以传输到其他软件组件这也影响了解决方案的总体信任度。

上一节从技术上介绍了 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可供身份验证提供程序用于读取简单变量或受信任的环境变量，或者在需要时读取 cookieIBM Cognos 自定义身份验证提供程序开发人员指南 描述叻这个 API 的 Java 版本，对细节感兴趣的人可以看一看需要进一步解释的是环境变量的处理，以及 IBM Cognos 入口点对检索它们的作用

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

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

1. Cognos 入口点部署在 Web 服務器或应用服务器上。这允许通过 Cognos 代码访问该服务器上的服务器变量Cognos Gateway 进而可向其他 IBM Cogos BI 组件提供服务器变量。
2. 将检索的服务器变量安全地传輸到 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 提供受信任的环境变量的方式，这些变量在技术上与服务器变量相对应

• 根据叺口点类型，可用服务器变量集合可能有所不同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。对于这种设置必须防止

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

考虑 IBM Cognos BI LDAP 身份验证提供程序，它采用受信任的登录模式来实现 SSO如果提供程序配置为在其外部身份映射字符串中使用元变量，Cognos 将信任一些鈳能伪造的信息因为尽管服务器变量已 “按原样” 从入口点安全地传递到身份验证提供程序，但元变量仍然反映的是一个请求标头该標头在到达入口点之前就可能已被伪造。正因如此最佳的做法是仅使用受保护的服务器变量（比如

为了支持受信任登录 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 提供程序后将分析它对一个 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 用户。一个示例是从 Web 服务器验证的用户执行单点登录無论 Web 服务器实际上是如何验证他们的。

需要提醒的是最佳实践是仅将 REMOTE_USER 或 USER_PRINCIPAL 用于提供变量名称。其他任何变量都可能是伪造的具体情况取決于 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 属性，不只是单个用户提供程序可以搜索单个域、一个域树或整个域林。

Kerberos而改为使用身份映射模式。更改需要重新启动 IBM Cognos BI但不会影响目前使用以前的设置定义的任何授权，只会影响身份验证

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 种可能的格式

用户的 Windows 登录名，存储在 AD 中一个名为 sAMAccountName的属性中以用户初始使用的 Windows 域名称作为前缀并使用一个反斜杠分开。通过添加域作为前缀可保证名称在林中得到惟一标识。一个示例是 US\montagg

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

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

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

SAP 身份验证提供程序

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

• 一个使用 IBM Cognos Series 7 SDK 开发的受信任登录插件。这些插件可使用 token 并在 REMOTE_USER Φ提供一个值然后，该值用于尝试受信任的登录

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

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

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

RACF 身份验证提供程序

上来实现的，这会是的 RACF 可以通过 LDAP 进行使用因此，对 RACF 的 SSO 支持是 LDAP 提供程序所提供功能的子集具体地讲，它仅限于基于 REMOTE_USER 环境变量的身份映射

NTLM 身份验证提供程序

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

要实现单点登录到 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 的

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

最终的问题是实现无缝的身份验证体验需要花费多少工作，而不是是否可以实现这种体驗时