IBM Cognos BI 身份验证和单点登录（5）

look_w

场景
场景 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 来保护通信。